Abstract: 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.

Abstract: 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.

Abstract: A mountable support and vice device for field use in small work areas includes a fastener, which is attached to a first terminus of a rod. The fastener is selectively attachable to an element of a structure, such as a scaffold, to removably attach the rod to the element of the structure. A pipe is nested around the rod so that the pipe is selectively extensible from, and selectively rotatable relative to, the rod. A coupler attached to the pipe and is positioned to selectively couple to the rod so that the pipe is fixedly positioned relative to the rod and the element of the structure. A vice is attached to the pipe proximate to a first end of the pipe and can selectively grip a substrate, such as a pipe elbow. The substrate thus is fixedly positioned and can be manipulated by a user.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: Techniques for selecting a network communications protocol based on network topology and/or network performance are described. A first application executing on a first computer system obtains a distance characteristic of a network coupling the first computer system to a second computer system. The first application selects a network communications protocol from a plurality of network communications protocols based on the distance characteristic of the network. The first application and the second application connect with the selected network communications protocol. In some embodiments, the distance characteristic of the network may be based on topological or performance characteristics of the network.

Abstract: Aspects relate to techniques for using read-only volume replicas in a distributed computing environment to enable over-subscription on server performance. In order to provide a good customer experience, the I/O handling replicas of a volume are typically reserved at a high percentage of the customer's desired performance. A read-only replica of the volume does not serve user I/O, and can therefore be reserved at a much lower percentage of desired performance. Particularly, as the number of read-only replicas increases, the performance reservation can be lowered due to the statistical likelihood that the server(s) hosting at least one read-only replica will have sufficient performance to support the desired reads during new volume creation (even though that performance has not been fully reserved). Aspects relate to techniques for selecting among read-only replicas to serve reads during creation of a new volume copy.

Abstract: 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. In one embodiment, the service allows for oversubscription of use on hosts, as well as parallelization of placement decisions, by distributing requests among a set of parallelized placement engines. Each engine can distribute its subset of volumes at least partly randomly among a candidate set of volumes, with the size of the candidate set selected based on a total number of volumes. This distribution mechanism can ensure distribution of volumes without requiring centralized placement of the volumes.

Abstract: Generally described, aspects of the present application correspond to enabling rapid duplication of data within a data volume hosted on a network storage system. The network storage system can maintain a highly distributed replica of the data volume, designated for duplication of data within the volume and separate from one or more other replicas designated for handling modifications to the data volume. By providing increased parallelization, the highly distributed replica can facilitate rapid duplication of the volume. When a sufficiently large request to duplicate the data volume is received, the system can create additional duplicate portions of the volume to further increase parallelization. For example, a partition of the highly distributed replica may be repeatedly duplicated to create a large number of intermediary duplicate partitions. The intermediary duplicate partitions can then be used to service the duplication request rapidly, due to increased parallelism.