Amazon Technologies, Inc.

Devlin Roarke Dunsmore

Diwakar Gupta

Ishwardutt Parulkar

Dougal Stuart Ballantyne

Upendra Bhalchandra Shevade

Colm MacCarthaigh

Georgios Elissaios

Christopher Brian Barclay

Pragya Agarwal

Sairam Sasank Chundi

Mark Walters

Aditya Chayapathy

Michael Phillip Quinn

Leslie Andrew Prock

Scott Renda

Techniques are described for a location-aware service-oriented application deployment management ('SOADM') service that abstracts the complexities of deploying distributed applications in a cloud provider network providing many possible deployment zones of one or multiple types. These deployment zone types can include traditional cloud provider regions and availability zones as well as so-called edge locations (e.g., cloud provider operated edge locations, customer-operated edge locations, third-party operated edge locations, communications service provider (CSP) associated edge locations). The SOADM service enables users to create service group configurations representing a service-oriented application, including its constituent services and dependent resources, and specify distribution strategies for deploying and/or redistributing application services and resources, among other configurations. Using such configurations, the SOADM service automatically deploys and scales simple or complex, single or multi-service applications for users across any number of deployment zones and deployment zone types.

Latency-based service discovery and routing for multi-location service-oriented applications

Techniques for API-based endpoint discovery and centralized load balancing involving provider substrate extension resources are described. A discovery coordinator service located within a provider network can identify one or more endpoints from a set of potentially distributed endpoints for a client to utilize, where endpoints may be located within provider substrate extensions of the provider network. The discovery coordinator service can analyze the loads of these endpoints, via client lease information, to identify nearby, low-load resources that may be most optimal for the client to use via providing minimal latency of access.

Centralized load balancing of resources in cloud edge locations embedded in telecommunications networks

User-configured multi-location service deployment and scaling

Techniques for distributed network connectivity monitoring of provider network edge location resources from cellular networks are described. A central service transmits test suites of commands to agents executed by test devices, which can execute the commands to test network characteristics between the test devices and target locations via one or multiple cellular communications networks. Results of the testing are sent back to the central service for processing, and the resultant metrics can be used for intelligent latency-based routing of clients, latency-based placement of resources, and/or performance monitoring of deployed resources.

Distributed network connectivity monitoring of provider network edge location resources from cellular networks

Techniques for API-based endpoint discovery involving provider substrate extension resources are described. A discovery coordinator service located within the provider network can identify one or more endpoints from a set of potentially distributed endpoints for a client to utilize, where endpoints may be located within provider substrate extensions of the provider network. The discovery coordinator service can utilize location values of the client provided via an API request, such as its network address or geographic coordinates, to identify a nearby resource that may be most optimal for the client to use via providing minimal latency of access.

API-based endpoint discovery of resources in cloud edge locations embedded in telecommunications networks

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

Techniques for reducing latency between resources of a cloud provider network and end user devices are described. In one embodiment, a system includes a cloud provider network including a first control plane service to manage customer compute instances hosted on resources of the cloud provider network. The system further includes a first provider substrate extension of the cloud provider network connected to a first communications service provider network. The first provider substrate extension includes a first computer system having capacity for executing customer compute instances, is controlled at least in part by the first control plane service via a connection through at least a portion of the first communications service provider network, executes at least a first customer compute instance using the first computer system, wherein the first customer compute instance communicates with a first mobile computer system connected via the first communications service provider network.

Cloud computing in communications service provider networks

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.

Growing community of inventors

Bothell, WA, United States of America

Devlin Roarke Dunsmore