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: Systems and methods are described for implementing load-dependent encryption mechanism selection in an elastic computing system. The elastic computing system can include a set of host devices configured to implement block storage volumes on behalf of users. Users may desire that such volumes be encrypted prior to storing data. It may be generally preferable for encryption to occur on the same host devices that host the volume, to reduce latency and bandwidth usage needed to encrypt the data. However, encryption of data can utilize significant computational resources, which may not be available on host devices that also have sufficient storage resources to host the volume. The present disclosure describes systems and methods that can account for computational resource availability on host devices, selecting “in-place” encryption only when available resources exist on host devices, and otherwise implementing remote encryption of volume data.

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: 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: A new metadata field is described that can be used with requests to store a volume in a block storage service. The metadata field is a parameter included in the request and is a logical association identifier that associates the volume to be stored with other already-stored volumes. Using this logical association identifier, the block storage service can ensure that all volumes having the same identifier are sufficiently spread across server computers. The logical association identifier can be a workload identifier indicating that the volumes are all from a same relational database, application, etc. Target customers are defined as customers that request an action of a service within a cloud environment and the service then makes a request to the block storage service. In this case, the service is a customer of the block storage service and it can pass the target customer identifier as the logical association identifier.

Abstract: Data volumes hosted for customers in a multi-tenant environment can be moved advantageously throughout the environment to improve performance and reduce cost. A data volume can serve I/O for a virtual machine instance, and it can be advantageous for the virtual machine and the data volume to be in the same network locality, or share at least some of the same network state and interconnection. Since there is limited capacity in a network locality, data volumes not attached to virtual machines can be moved to other locations in the environment. This can include moving data volumes to other local network topologies or snapshotting data volumes and writing the snapshots to another storage service. If the data volume is again needed for I/O, the data volume can moved, allocated, or reattached as necessary.

Abstract: Data volumes for a customer can be placed on various storage tiers, including different hardware types or storage systems, that are determined to be appropriate for the anticipated usage of those data volumes. The actual usage can be monitored to determine one or more types of workload for the data volume, and a determination made as to whether all, or portions, of the data volume could obtain a significant performance improvement by being migrated to a different storage tier. In some instances the chunks or partitions of a volume can be concurrently distributed across multiple different storage tiers in order to satisfy various performance and/or cost criteria. Once workload information is available for a customer, that information can be used to determine the storage tiers for initial placement of subsequent data volumes.

Abstract: Placement decisions can be made for data storage volumes based at least in part upon the requirements of the storage volumes and the capabilities of the types of hardware available to host those volumes. There may be multiple types of hardware capable of supporting a volume, and the placement can be biased to hardware capable of supporting fewer types of storage volumes in order to ensure sufficient capacity for the various types of storage volumes. A consistent level of performance can also be provided independent of the type of hardware utilized. Hardware can be selected to host a volume that is able to satisfy various volume requirements, and the operation can be adjusted to ensure that the volume requirements are satisfied over time.

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 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 distributed system may implement analyzing bit vectors for resource placement. Bit vectors may be maintained or generated for currently hosted resources in a distributed system according to placement criteria so that individual bit values of a bit vector indicate whether a corresponding one of the placement criteria is satisfied for the current placement of the resource. A resource may be identified for migration and a possible placement determined for the resource. A bit vector may be generated for the possible placement and compared with the bit vector for the current placement of the resource to determine whether the possible placement improves the placement of the resource with respect to the placement criteria.

Abstract: The allocation of resources, such as for data storage, can be performed based at least in part upon predicted values for utilization and growth, among other such values. Various features can be used to predict the initial utilization and growth rate for a data volume, and these predicted values can be used to determine where to place the volumes. The features can include, for example, customer usage history, volume type, volume purpose, type of attached virtual machine, and the like. The ability to predict actual usage can enable capacity to be allocated based on an as-needed basis instead of providing large blocks of allocated capacity that would go largely unused. Similar predictions can be used to determine whether and where to migrate data volumes so as to maintain sufficient capacity across a group of resources.

Abstract: A data storage service may operate one or more storage servers configured to maintain logical volumes on behalf of customers of the remote data storage service. The logical volumes may have various dimensions. The various dimensions may be used to generate an average volume. The average volume may then be used to execute a simulation of an amount of remaining storage capacity of the data storage service.

Abstract: Data volumes for a customer can be placed on various storage tiers, including different hardware types or storage systems, that are determined to be appropriate for the anticipated usage of those data volumes. The actual usage can be monitored to determine one or more types of workload for the data volume, and a determination made as to whether all, or portions, of the data volume could obtain a significant performance improvement by being migrated to a different storage tier. In some instances the chunks or partitions of a volume can be concurrently distributed across multiple different storage tiers in order to satisfy various performance and/or cost criteria. Once workload information is available for a customer, that information can be used to determine the storage tiers for initial placement of subsequent data volumes.

Abstract: Data volumes for a customer can be placed on various storage tiers, including different hardware types or storage systems, that are determined to be appropriate for the anticipated usage of those data volumes. The actual usage can be monitored to determine one or more types of workload for the data volume, and a determination made as to whether all, or portions, of the data volume could obtain a significant performance improvement by being migrated to a different storage tier. In some instances the chunks or partitions of a volume can be concurrently distributed across multiple different storage tiers in order to satisfy various performance and/or cost criteria. Once workload information is available for a customer, that information can be used to determine the storage tiers for initial placement of subsequent data volumes.

Abstract: Data volumes hosted for customers in a multi-tenant environment can be moved advantageously throughout the environment to improve performance and reduce cost. A data volume can serve I/O for a virtual machine instance, and it can be advantageous for the virtual machine and the data volume to be in the same network locality, or share at least some of the same network state and interconnection. Since there is limited capacity in a network locality, data volumes not attached to virtual machines can be moved to other locations in the environment. This can include moving data volumes to other local network topologies or snapshotting data volumes and writing the snapshots to another storage service. If the data volume is again needed for I/O, the data volume can moved, allocated, or reattached as necessary.

Abstract: Data volumes hosted for customers in a multi-tenant environment can be moved advantageously throughout the environment to improve performance and reduce cost. A data volume can serve I/O for a virtual machine instance, and it can be advantageous for the virtual machine and the data volume to be in the same network locality, or share at least some of the same network state and interconnection. Since there is limited capacity in a network locality, data volumes not attached to virtual machines can be moved to other locations in the environment. This can include moving data volumes to other local network topologies or snapshotting data volumes and writing the snapshots to another storage service. If the data volume is again needed for I/O, the data volume can moved, allocated, or reattached as necessary.

Abstract: A distributed system may deploy infrastructure units according to resource hosting constraints. Additional infrastructure units, or infrastructure units to be redeployed, may be identified for deployment. State information describing the deployment of infrastructure units currently deployed amongst different infrastructure localities of a distributed system may be evaluated for different possible deployments according to resource hosting constraints. Possible deployments that optimize or increase resource hosting capacity in the distributed system within the resource hosting constraints may be determined. Deployment at those infrastructure localities of the determined possible deployments may be directed.

Abstract: A distributed system may implement dynamic resource creation for connecting resources. Resource creation requests may be received for resources which are accessed by other resources hosted in a distributed system. An intention for the creation request is stored to perform the creation request. At a subsequent time, a request to connect another resource to the resource of the creation request is received. An infrastructure locality for the other resource may then be identified and utilized to determine a placement location for the resource. The resource may then be created at the placement location according to the stored intention. The resource may then be connected with the other resource for access.

Abstract: A remirror buffer can be used in failover situations so as to backup storage volumes in a service provider. The remirror buffer is dynamically resized to meet current usage metrics captured from a data center. A risk boundary can be defined through which resource hosts are grouped together so as to determine the usage metrics. The risk boundary can be based on a topology of the data center, such as a room/rack/sharing of power supplies, or other characteristics of the resource hosts.