Amazon Technologies, Inc.

Christopher Magee Greenwood

Mitchell Gannon Flaherty

Surya Prakash Dhoolam

Gary Michael Herndon

Danny Wei

Wells Lin

Marc John Brooker

Sriram Venugopal

Marc Stephen Olson

James Michael Thompson

Colin Williams

Igor A Kostic

Kiran-Kumar Muniswamy-Reddy

Nishant Satya Lakshmikanth

Yilin Guo

Patrick E Brennan

Linfeng Yu

Anthony Nicholas Liguori

Andrew Kent Warfield

Madhuvanesh Parthasarathy

Divya Ashok Kumar Jain

Jacob Taylor Wires

Marc Levy

Kristina Kraemer Brenneman

Pavel Labovich

Mark Robinson

Iain Michael Christopher Peet

Rahul Karnik

Alexander R Yee

James T Pinkerton

Prashant Singh

Nachiappan Arumugam

Joshua Dawie Mentz

Michael Groenewald

Steven J Kruy

Avram Israel Blaszka

Tarun Goyal

Sushant Bhatia

Jing Wang

Haoyu Huang

Dragos Diaconescu

Srinivas Jasti

Ashritha Nagavaram

Sonal Agarwal

Gautham Narayanasamy

Linlin Ding

Manish Verma

Bhagyasri Pavuluri

Mark Danoher

Gabriël De Vos Smit

Meiwen Li

Eric Jeffrey Heinz

Nathan William Sharp

Described are systems and methods that use a donor memory that is accessible from multiple compute instances to access and execute portions of user data stored on the donor memory, thereby decreasing the time required to initialize a compute instance. Upon receipt of a first request to execute a user data, a compute instance group is initialized that includes a donor memory and a donor file system. At least a portion of the requested user data, or a snapshot of at least a portion of the user data, is loaded into the donor memory and a first compute instance is initialized in the compute instance group to execute the user data from the donor memory. Upon receipt of a second request to execute the user data, rather than having to again load the portion of the user data (or snapshot), a second compute instance is initialized within the compute instance group that is able to directly access the donor memory and execute the user data.

Shared donor memory compute instances

Systems and methods are provided for handling file operations from a hosted computing instance via a secure compute layer. The secure compute layer is presented to the instance as a virtualized service device that is locally addressable by the instance. Software within the instance can submit file operations to the virtualized service device, which the secure compute layer can translate into calls to a network-accessible storage service. Results from the calls can then be passed back to the instance through the virtualized service device. As a result, the instance can communicate with a variety of different network services, without itself implementing network communications for those services.

Offloading of remote service interactions to virtualized service devices

Systems and methods are provided for managing provision of—and access to—data sets among instances of function code executing in an on-demand manner. An API is provided by which functions can store data sets to be shared with other functions, and by which functions can access data sets shared by other functions.

On-demand code execution data management

Systems and methods are provided for implementing a multi-service file system for a hosted computing instance via a locally-addressable secure compute layer. Software within the instance can submit file operations to the secure compute layer, which the secure compute layer can translate into calls to one or more network-accessible storage services. To provide a multi-service file system, the secure compute layer can obtain mapping data mapping file system objects within the virtualized file system to different network-accessible storage services. On receiving a file operation, the secure compute layer can determine one or more network-accessible storage services corresponding to the file operation, and submit appropriate calls to the one or more network-accessible storage services. By varying the calls for file operations, various functionalities, such as data backup, write staging, read caching, and failover can be implemented independent of both operation of the hosted computing device and the network-accessible storage services.

Pseudo-local multi-service enabled file systems using a locally-addressable secure compute layer

Systems and methods are described for controlled migration of workloads between cell systems arranged in a cell-based architecture. Each cell system can implement a portion of an overall workload of the architecture, which may represent a network-accessible service. The isolation provided by cells may prevent widespread problems at the service, but may also conceal errors that might occur should workloads between the cells be redistributed. Such redistribution is often forced at inopportune moments, such as when a cell of the service has already failed. Systems and methods described herein enable detection of such errors by repeatedly migrating portions of workloads between cells. The system can monitor health information during or between migrations to ensure continued health of the service. If the service appears to be unhealthy after a migration, future migrations can be halted to enable a cause of the unhealthy state to be identified and rectified.

Controlled cross-cell migration of data in cell-based distributed computing architecture

A block storage service analyzes customer behaviors as external signals to the health of the block storage service. In one example, using rules set by a customer for a health monitoring service, the block storage service can gain insights into what the customer cares about. The customer rules can then be used to setup internal monitors within the block storage service. If the internal monitors are triggered, the block storage service can proactively correct problems before the customer alarm thresholds are reached. For example, customer volumes can be moved to increase performance characteristics. In some cases, if the customer has too much performance capability, the customer volume can be moved to a less costly alternative.

Using customer input to determine proper functionality of a block storage service

A block storage service can ensure volumes are placed in a same region as an attached virtual machine instance for performance and durability guarantees. A region can reference multiple things, but one example is that a volume is within a same spine as a virtual machine in order to meet performance guarantees. Each region can have a buffer of server computers held in reserve for volumes having a type where performance guarantees are required. If performance guarantees cannot be met, a rejection is transmitted to the customer. In another embodiment, the customer can provide a list in priority order of different volume types so that if a desired volume type cannot be placed, then alternative volume types can be used.

Block storage with volume locality placement based on performance requirements

A data storage manager may manage storage locations for blocks of a storage volume. The blocks of the storage volume may be assigned to a logical volume exposed to a computing instance supported by a host. Furthermore, the data storage manager may also generate and maintain a set of rules that specify the locations of blocks of the storage volume, and provides the set of rules to the host. The set of rules may be included in a data structure enabling the host to access the blocks based at least in part on the information included in the set of rules.

Enabling host computer systems to access logical volumes by dynamic updates to data structure rules

Data replication groups may be used to store data in a distributed computing environment. A data replication group may include a set of nodes executing a consensus protocol to maintain data durably. In order to increase efficiency and performance of the data replication group leadership and/or fitness information may be determined for each node of the set of nodes executing the consensus protocol. The fitness information may be based at least in part on information associated with computing resource in the distributed computing environment and one or more constraints on assignment of a role of master node in the data replication group. The master node may be responsible for advancing the data replication group.

Prioritized leadership for data replication groups

A distributed system may implement evaluating placement configurations for distributed resource placement. Placement requests for a partition of a distributed resource may be received. An evaluation of prospective placement configurations of the distributed resource is performed that locates the partition at different resource hosts. In some embodiments, placement configurations may be analyzed with respect to infrastructure zone locality. Multiple infrastructure zone localities may be analyzed and combined to evaluate prospective placement configurations. Prospective placement configurations may be analyzed with respect to other criteria, such as resource host utilization data. Based, at least in part, on the evaluation of the prospective placement, a resource host is identified for placing the partition.

Evaluating placement configurations for distributed resource placement

A distributed system may implement analyzing resource placement fragmentation for capacity planning. Capacity planning may determine when, where, and how much capacity to implement for a distributed system that hosts resources. Placement constraints for resources may, over time, create fragmentation or stranded capacity which is available yet unusable to host new resources. Analyzing capacity fragmentation across a distributed system may allow a determination of available capacity that is actually available to host additional resources. In some embodiments, future resource placements may be estimated in order to perform capacity fragmentation analysis to determine available capacity.

Analyzing resource placement fragmentation for capacity planning

Systems and methods are disclosed for reducing interdependency among control plane on a block storage system. Embodiments described herein can implement a key-value data store on the data plane servers. In one embodiment, the key-value store stores data regarding placement constraints and enables the block storage system to make placement decisions without control plane dependencies. In another embodiment, the key-value store persisted by the data plane enable the block storage system to migrate volumes while maintaining performance settings.

Arbitrary server metadata persistence for control plane static stability

Generally described, one or more aspects of the present application correspond to a highly distributed replica of a volume stored in a networked elastic computing environment. First and second replicas of the volume can be synchronously replicated, and some implementations of the tertiary replica can be asynchronously replicated. The highly distributed nature of the tertiary replica supports parallel data transfer of the data of the volume, resulting in faster creation of backups and new copies of the volume.

Rapid volume backup generation from distributed replica

A snapshot object or other type of object may be stored in a first storage system and may be accelerated in another storage system, wherein an accelerated snapshot or other type of object can be used to populate volumes in the other storage system with data more rapidly than a non-accelerated snapshot or other type of object. The accelerated snapshot or other object may be implemented using an intermediate volume implemented in the other storage system that is populated with data from the snapshot object or the other object stored in the first storage system.

Accelerated volumes

Systems and methods are disclosed for handling requests to create multiple volumes with an expected usage correlation on a block storage service. Rather than handling each request to create a volume independently, embodiments described herein can handle the request in bulk, quickly determining whether the request as a whole can be handled at the system. In one embodiment, the service allows for oversubscription of use on hosts, as well as parallelization of placement decisions, by rejecting placement requests when a number of possible hosts for a volume within a requested set falls below a candidate set size, which is determined based on factors such as a number of requested volumes and an expected accuracy of state information for the service at a placement engine within a distributed set of engines.

Correlated volume placement in a distributed block storage service

Growing community of inventors

Seattle, WA, United States of America

Christopher Magee Greenwood