Abstract: A distributed system may implement prioritizing resource hosts for resource placement. A placement request for a resource to be placed in a distributed system at a resource host may be received. Available resource hosts may be filtered out according to placement constraints. The resource hosts may be assigned to different priority sets according to a priority scheme for placing resources at resource hosts. Evaluations of resource hosts from the different priority sets may be performed to select candidate resource hosts to provide as possible placement locations.

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

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: 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: 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: A method for selecting a service endpoint from a plurality of service endpoints in a distributed system of a service provider may include storing processing data for each of the plurality of endpoints. A success rate may be calculated for each of the plurality of service endpoints and based on a number of processed requests from a plurality of received requests. An average latency may be calculated based on latency associated with each of the processed requests. A latency score may be calculated based on a minimum average latency and the average latency. A raw score may be calculated based on the latency score and the success rate. A selection weight may be calculated based on the raw score and a balancing parameter. One of the plurality of endpoints may be selected based on the selection weight.

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: 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 request to create a volume to store data is received. A block within the storage node is selected, dependent at least in part on metadata indicating regions of available storage space in a storage node, to associate with a volume. Information is generated that includes an address to the block. A second computer system is determined to lacks the address to the block. The second computer system is enabled, by providing at least a portion of the information to the second computer system, to perform an operation to the block.

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.