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 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: 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: A distributed system allocates capacity in response to client requests. The system monitors a rate of capacity allocation. Based on the monitored rate and on a set of parameters, the system generates a forecast of capacity available for allocation and determines a time when available capacity will fall below a threshold level. The system adjusts the parameters to cause the predicted time to align with a target time, and then causes the system to be reconfigured according to the adjusted parameters.

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 implement preventing concentrated selection of resource hosts for placing resources within the distributed system. When a request to place a resource at a resource host is received, an evaluation of load metrics for the resource host is made with respect to rejection criteria. If the rejection criteria is satisfied, then the resource host may reject the request to place the resource. If the rejection criteria is not satisfied, then the resource host may not reject the placement of the resource. Rejection criteria may be provided to resource hosts along with the placement request, in some embodiments. Rejection criteria may be changed, weakened, or removed entirely if initial attempts to place a resource are unsuccessful.

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 distributed system may implement network locality-based throttling for automatic resource migration. Utilization of a distributed system that includes multiple resources at multiple resource hosts may be monitored. New migration operations to migrate a resource in the distributed system may be evaluated with respect a migration operation limit for one or more network localities of the distributed system. If the migration operation limit for the one or more network localities is exceeded, then the new migration operations may be throttled. Different network localities may have different migration operation limits.

Abstract: A distributed system may implement opportunistic resource migration to optimize resource placement. Resources may be placed amongst different resource hosts of a distributed system. An evaluation of the current placement may be performed according placement criteria that improve placement of the resources at the distributed system. Based on the evaluation, the prospective migration of resources that exceed an improvement threshold may be identified as candidate resources to migrate. Migration for the candidate resources may be opportunistically performed. In some embodiments, a priority may be assigned to the candidate resources according to which the candidate resources are selected for performing migration.

Abstract: A movement system of a block-level data storage service obtains usage information for a data storage volume. The movement system processes the usage information to identify a placement strategy for the data storage volume that is associated with a second operational state for the data storage volume. Based on the placement strategy, the movement system causes a set of servers to perform an operation to implement the second operational state for the data storage volume. As a result of the operation being successfully performed, the movement system provides access to the data storage volume in accordance with the second operational state.

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 distributed system may implement optimizing for infrastructure diversity in resource placement. A placement request for a resource to be placed at one of multiple resource hosts respectively implemented at infrastructure units may be received. An evaluation of utilization data for the multiple resource hosts may be performed with regard to an infrastructure diversity constraint for placing resources at the infrastructure units. A selection of a resource host may be made based on the evaluation of the utilization data according to the infrastructure diversity constraint. In some embodiments to select the resource host, the effect of placing the resource on candidate resource hosts on an infrastructure-diverse capacity metric may be determined to score the candidate resource hosts. The resource may be placed at the selected resource host.

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