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: 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 pool of the data volume, include a number of replicas duplicating data of the data volume. By providing increased parallelization, the replica pool can facilitate rapid duplication of the volume. In one configuration, each partition of a new volume is mapped to an individual replica within the replica pool, which supports population of the partition with data. Each replica can further include a set of replica partitions, such that read requests from each partition of a new volume are distributed among a number of servers to provide additional parallelization.

Abstract: A first request to create a first storage volume to store a first portion of a first logical volume is received by a first block storage server instance. A second request to create a second storage volume to store a second portion of the first logical volume is received by a second block storage server instance. A third request is sent to a third block storage server instance to create a third storage volume to store the second portion of the first logical volume. The second portion of the first logical volume is stored by the third block storage server instance to the third storage volume. A data store containing an identification of each block storage server instance hosting a portion of the first logical volume is updated to remove an identification of the second block storage server instance and add an identification of the third block storage server instance.

Abstract: Notice of migration of a portion of a data volume from a first location to a second location is received by a first computer system from a second computer system, where the data volume is separated over a network from the first computer system. A third computer system, separated over a network from the first computer system, is caused to invalidate a mapping between the portion and the first location. An indication that the third computer system seeks access to the portion is identified. A third computer system is enabled, by providing a mapping between the portion and the second location, to access portion at the second location.

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: A first request to create a first storage volume to store a first portion of a first logical volume is received by a first block storage server instance. A second request to create a second storage volume to store a second portion of the first logical volume is received by a second block storage server instance. A third request is sent to a third block storage server instance to create a third storage volume to store the second portion of the first logical volume. The second portion of the first logical volume is stored by the third block storage server instance to the third storage volume. A data store containing an identification of each block storage server instance hosting a portion of the first logical volume is updated to remove an identification of the second block storage server instance and add an identification of the third block storage server instance.

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: First information about regions of storage space in a storage environment available for a volume is provided to a service provider, with the storage environment being external to the service provider. The service provider is notified that information usable to locate a storage destination of a portion of the volume is unavailable. Second information that includes the storage destination in the storage environment is obtained from the service provider. A data operation is performed at the storage destination, with the storage destination determined based at least in part from the second information.

Abstract: A distributed system may include one or more interfaces, such as APIs, allowing a client to request a resource instance and further provide information about the resource instance that can be used to determine a placement domain for resource instance. For example, a compute instance may be placed in a same placement domain as a volume that provides block storage for the compute instance. In some embodiments, a resource placement manager may “jam” place a resource instance in a particular placement domain, wherein the “jam” placement causes one or more placement constraints to be temporarily violated. The resource placement manager may then perform one or more mitigating actions to return the particular placement domain to a state that satisfies the one or more placement constraints.

Abstract: Generally described, one or more aspects of the present application correspond to a highly distributed replica of a volume stored in a networked 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: 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 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: 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: 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 customer of a computing resource service provider submits a request to a virtual computer system service to instantiate a virtual computer system. In response to the request, the service obtains physical network information in order to identify any hardware groupings that may be used, at a later time, to provision one or more data storage volumes that may be associated with the virtual computer system. The service assigns a score to each of these hardware groupings based at least in part on the available capacity for provisioning of these data storage volumes. Based at least in part on these assigned scores, the virtual computer system service selects a hardware grouping and instantiates the virtual computer system within the selected hardware grouping.