Amazon Technologies, Inc.

Michael Phillip Quinn

Diwakar Gupta

Bradley Joseph Gussin

Jacob Adam Gabrielson

Ishwardutt Parulkar

Georgios Elissaios

Nishant Kanaiyalal Mehta

Jean-Paul Bauer

Devlin Roarke Dunsmore

Leslie Andrew Prock

Weizhong Hua

Pratik Pradeep Ramdharne

Casey Thomas Huggins

Jarrod Scott Cameron

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.

Capacity management in provider networks using dynamic host device instance model reconfigurations

Techniques for managing resource utilization across heterogeneous physical hosts are described. Resource utilization of a first plurality of physical hosts in a provider network may be monitored, each physical host comprising a plurality of resources. A future resource utilization can be determined, the future resource utilization including quantities of a plurality of resource types. The future resource utilization can be matched to a plurality of physical host types, each physical host type associated with a different plurality of resources. A second plurality of physical hosts corresponding to the plurality of physical host types can be deployed to the provider network.

Placement to optimize heterogeneous physical host utilization

Techniques for server movement control are described. A capacity library service (CLS) can manage which hosts in a provider network can be taken in and out of production. The CLS may also control which entities may remove hosts from production and under what conditions the hosts may be removed from production. In some embodiments, the CLS can execute various workflows to manage checkout and check-in of hosts. Workflows may also be used to manage hosts while they are out of production to manage state transitions (e.g., in production, in testing, in reserve, etc.) based on current host fleet capacity and checkout rules.

Server movement control system based on monitored status and checkout rules

Techniques for on demand capacity management in a provider network are described. The provider network includes electronic devices that provide computing-related resources to customers. The unused capacity of these electronic devices&#x2014;such as processor cores, memory, network bandwidth, etc.&#x2014;can be used to satisfy a variety of computing needs. Services of the provider network allocate portions of the unused capacity based on customer requests for computing-related resources.

On demand capacity management in provider networks using type-agnostic resources

A system and methods are disclosed for adding slots to a group of slots for instantiating compute instances. Compute capacity of a computing system of a plurality of computing systems is detected. A first slot and a second slot of the group of slots are determined based on compute instances instantiated on the computing systems. The first slot is associated with a first type of compute instance and the second slot is associated with a second type of compute instance. The first type of compute instance and the second type of compute instance have different computing resource values associated therewith. The first slot and the second slot are added to the group of slots for respectively instantiating the first type and the second type of compute instances.

Compute capacity allocation based on multi-factor analysis

Techniques for launching compute instances on cloud provider network substrate extensions deployed within communications service provider networks are described. A service of a cloud provider network receives a request to launch a compute instance from a customer, the request including a latency requirement. A provider substrate extension is selected to host the compute instance from a plurality of provider substrate extensions of the cloud provider network based at least in part on the latency requirement. The plurality of plurality of provider substrate extensions are connected to a communications service provider network and controlled at least in part by the service of the cloud provider network via a connection through the communications service provider network. A message is sent to cause the selected provider substrate extension to launch the compute instance for the customer.

Latency-based placement of cloud compute instances within communications service provider networks

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.

Methods and apparatus for allocating host resources to virtual machines

Deployment feedback for updates to resources implemented in a private network may be implemented. Feedback codes may be generated and included in deployments sent to a private network for deployment at resources implemented in the private network. One or more of the included feedback codes may be selected based on the performance of the deployment and provided via a feedback communication channel that is disconnected and distinct from the private network. Once received, a current status of the deployment may be determined based on the one or more feedback codes provided via the feedback communication channel.

Growing community of inventors

Seattle, WA, United States of America

Michael Phillip Quinn