Abstract: Techniques are described for enabling customers of a service provider network to modify and extend the functionality of application programming interfaces (APIs) provided to customers by various services of the provider network. Services of a service provider network provide interfaces that enable customers and other users to define custom API actions representing functionality to be performed by the services upon receipt of corresponding API requests. In this manner, the functionality exposed by provider network services to customers via APIs becomes extensible and customizable to fit customers' particular use cases and without the provider network needing to contemplate and explicitly implement all possible customer-specific API action variations.

Abstract: Techniques for managing fault domains using cells are described. An area of a provider network may be divided into multiple cells, with each cell representing a different fault domain of the area of the provider network. A customer can provide domain definitions for their service or application and a cell management service can use the domain definitions to place the infrastructure and compute resources underlying the customer's application or service in appropriate cells within an area of the provider network. In some embodiments, the domain definitions may be account-based, where the domain definition may be to place resources in different fault domains depending on the account they are associated with. Alternatively, the customer may tag resources with an identifier such that resources tagged with a first identifier may be placed in a first cell while resources tagged with a second identifier may be placed in a second cell.

Abstract: Techniques for configurable compute instance resets are described. A user can issue a request to securely reset one or more compute instances implemented within a service provider system. Each compute instance is reset to a previous point in time, such that any activity of the compute instance or effects thereof occurring since that point in time are completely eliminated. Each compute instance reset can include removing an existing volume of the compute instance, obtaining a volume, attaching the obtained volume to the compute instance, and rebooting the compute instance. Configuration data of the compute instance, such as an instance identifier or network addresses, can be maintained after the reset.

Abstract: A customer having a deployment of resources in a resource provider environment can utilize a mechanism such as an application programming interface (API) to obtain fault, risk, and/or distribution information for the deployment. A risk score can be generated, by the customer or a component of the resource provider environment, that gives the customer a measure of the risk of the current deployment, whereby the customer can request one or more changes to the customer deployment. In some embodiments the customer can provide one or more risk criteria, such as a maximum risk score or minimum fault tolerance, that the resource provider environment can attempt to satisfy over the duration of the customer deployment, automatically making adjustments to the deployment as appropriate. The risk score can include information about the customer workload as well as the physical deployment in order to provide more accurate data.

Abstract: Techniques are described for enabling users of a service provider network to create and configure “application profiles” that include parameters related to execution of user workloads at provider substrate extensions. Once an application profile is created, users can request the deployment of user workloads to provider substrate extensions by requesting instance launches based on a defined application profile. The service provider network can then automate the launch and placement of the user's workload at one or more provider substrate extensions using edge-optimized compute instances (e.g., compute instances tailored for execution within provider substrate extension environments).

Abstract: Methods and apparatus for reconfiguring hosts in provider network environments in which hosts are evaluated to determine if steps of a full rebuild can be skipped. The hosts may implement slots of different types for virtual machines (VMs). Upon detecting that slots of a particular type are needed, a host that implements slots of another type may be selected for reconfiguration. The host may be evaluated to determine if one or more steps of a full rebuild can be skipped. The host may then be reconfigured to implement slots of the target type according to results of the evaluation. In at least some reconfigurations, at least one step of a full rebuild procedure is not performed for the respective host. Results of previous reconfigurations may be fed back into the evaluation process and used as one of the criteria for determining if steps can be skipped.

Abstract: Techniques for managing the migration of virtual machine instances are described herein. A migration of a virtual machine from a source host to a destination host is determined to be predicted to fail. The migration is cancelled by stopping the virtual machine at the destination host as a result of said determination.

Abstract: Techniques for DNS-based endpoint discovery involving provider substrate extension resources are described. A client seeking to access a resource may utilize a DNS resolver located within a provider substrate extension of a provider network. The DNS resolver may be dynamically configured by a coordinator service located within the provider network to resolve a domain to an endpoint that may provide the lowest latency of access for clients close to the provider substrate extension.

Abstract: Techniques are described for enabling users of a cloud provider network to discover “availability groups” provided by a cloud provider network and to request the launch of computing resources into selected availability groups. Some cloud provider networks are expanding the definition of traditional “availability zones” to include new types of availability zones representing various types of provider substrate extension edge locations—including, for example, cloud-provider managed substrate extensions associated with separate control planes, 5G-enabled provider substrate extensions connected to communications service provider networks, and the like. Availability groups can be used to represent various defined collections these new types of provider substrate extensions, where each availability group may be defined such that includes a set of provider substrate extensions with a similar set of characteristics and capabilities.

Abstract: A system and method for managing a computer-implemented online game provides dynamically variable rewards to incentivize player interaction with sponsored content presented within the game. The particular reward offered to incentivize player interaction with particular sponsored content (e.g., a particular advertisement) can be dynamically variable based on the attributes of the player, thus providing user-specific custom rewards for interaction with sponsored content. Properties of incentive rewards that may be dynamically variable can include a custom type of in-game asset or resource, and/or a custom amount of a particular in-game asset or resource.

Abstract: Techniques for automated failover of remote control planes are described. A method of automated failover of remote control planes include determining failover event associated with a first control plane has occurred, the first control plane associated with a first area of a provider network, identifying a second control plane associated with a second area of the provider network, and failing over the first area of the provider network from the first control plane to the second control plane, wherein the child area updates one or more references to endpoints of the first control plane to be references to endpoints of the second control plane.

Abstract: Techniques for capacity bursting using a remote control plane are described. A method of capacity bursting using a remote control plane includes determining that a first control plane associated with a first area of a provider network has insufficient capacity to manage a plurality of resources in the first area, sending a request for a second control plane in a second area of the provider network to manage at least a first portion of the plurality of resources in the first area, the second control plane identified based at least on a backup hierarchy, and updating management of at least the first portion of the resources in the first area from the first control plane to the second control plane, wherein one or more references to endpoints of the first control plane are updated to be references to endpoints of the second control plane for at least the first portion of the resources managed by the second control plane.

Abstract: Techniques are described for enabling users of a service provider to manage placement preferences used to launch virtualized computing resources into a fleet of dedicated physical servers. Users can use one or more service provider interfaces to provide input indicating various placement preferences associated with a fleet of physical servers dedicated for use by a user of the service provider. These placement preferences can be used to determine at which physical server virtualized computing resources—for example, virtual machine (VM) instances, containers, and the like—are launched in response to launch requests. Among other benefits, the ability to configure customized placement preferences enables users to better satisfy various performance, reliability, software licensing, and other considerations users may have with respect to how their resources are placed within physical server fleets.

Abstract: Techniques for providing customer feedback related to virtual machine instance maintenance events are described herein. A customer is provided with an event message specifying a virtual machine maintenance operation and a proposed time to perform that virtual machine maintenance operation. A response that specifies the time that the customer wishes to perform the virtual machine maintenance operation is received and the virtual machine maintenance operation is scheduled based at least in part on that specified time.

Abstract: A component of a computing service obtains respective indications of placement policies that contain host selection rules for application execution environments such as guest virtual machines. With respect to a request for a particular application execution environment, a group of applicable placement policies is identified. A candidate pool of hosts is selected using the group of placement policies, and members of the pool are ranked to identify a particular host on which the requested application execution environment is instantiated.

Abstract: A system comprising a computing node comprising a processor and a non-transitory memory and an application stored in the non-transitory memory. When executed by the processor, the application causes the processor to receive an input requesting that a first compute instance of a first compute instance type be instantiated as a second compute instance of a second compute instance type, where a mix of compute resources associated with the second compute instance type is different from a mix of compute resources associated with the first compute instance type; create the second compute instance of the second compute instance type based on the first compute instance; deactivate the first compute instance; and instantiate the second compute instance.

Abstract: Techniques for capacity management in provider networks using dynamic host device instance type reconfigurations are described. A fleet reconfiguration service performs runtime reconfiguration of slots of host electronic devices that are available to execute compute instances, while the electronic devices may execute other compute instances, to dynamically change the type and/or numbers of slots of the electronic devices available for compute instance execution.

Abstract: A first virtualization control mode to be used for configuring one or more compute instances is determined. Based at least partly on the mode, preparatory configuration operations for launching a compute instance are initiated. The operations include transferring at least a portion of a machine image to a storage device accessible from a host, and initialization of a virtual network interface. A compute instance is instantiated using the machine image at the host. The compute instance is a thread of an intermediary process launched by an administrative agent at the host in response to a launch request.

Abstract: Methods and apparatus for dynamically allocating host resources (e.g., CPUs, GPUs, etc.) to virtual machines (VMs) on host devices in a provider network. The host devices may be provisioned with quantities of each resource type. Customers may request different combinations and quantities of resources for their VMs. Upon receiving a placement request for a VM, a host device is located that can provide a requested combination and quantity of resources for the VM. The host can then be directed to attach at least the requested combination and quantity of host resources to the VM. Future demand for VMs with particular combinations and quantities of resources can be predicted, and logical slots can be predefined in the control plane in anticipation of that demand. If a customer's VM is provided with more resources than requested, the customer may release or sell the extra resources.

Abstract: A method for networking provides a network service for a network. The network service can include the server system maintaining a database that can include information about connections between nodes. The network service can include the server system receiving a potential connection message from a first node to be delivered to a third node. The potential connection message can include a suggestion that the third node connect to a second node. The network service can include the server system delivering the potential connection message to the third node, only if the server system verifies in the database that the first node is connected with the third node and the second node. The network service can include the server system receiving feedback from the third node regarding the second node. The network service can include the server system connecting the second node to the third node, only if the feedback from the third node regarding the second node is positive.