Abstract: An opportunistic throttling approach can be used for customers of shared resources in a multi-tenant environment. Each customer can have a respective token bucket with a guaranteed fill rate. When a request is received for an amount of work to be performed by a resource, the corresponding number of tokens are obtained from, or charged against, a global token bucket. If the global bucket has enough tokens, and if the customer has not exceeded a maximum work rate or other such metric, the customer can charge less than the full number of tokens against the customer's token bucket, in order to reduce the number of tokens that need to be taken from the customer bucket. Such an approach can enable the customer to do more work and enable the customer's bucket to fill more quickly as fewer tokens are charged against the customer bucket for the same amount of work.

Abstract: A storage management system monitors an indicator of whether data storage is capable of meeting a performance description as stored on a current implementation resource, such as a storage server. The indicator may be used to determine whether none, some or all of the data storage should be moved from the current implementation resource to an available implementation resource.

Abstract: Patterns of access and/or behavior can be analyzed and persisted for use in pre-fetching data from a physical storage device. In at least some embodiments, data can be aggregated across volumes, instances, users, applications, or other such entities, and that data can be analyzed to attempt to determine patterns for any of those entities. The patterns and/or analysis can be persisted such that the information is not lost in the event of a reboot or other such occurrence. Further, aspects such as load and availability across the network can be analyzed to determine where to send and/or store data that is pre-fetched from disk or other such storage in order to reduce latency while preventing bottlenecks or other such issues with resource availability.

Abstract: A system and method for optimizing the performance of one or more disks in a storage array in response to access requests by other computer devices and processes across a network. For requests to access to the storage disk from the network, such as a read/write request, a response monitor notes the service time for each access requests by the storage disk, and if the performance in handling the access requests fails to meet, at least, a predetermined time threshold, actions can be taken to migrate data, modify accesses permitted to the disk, or otherwise indicate underperformance.

Abstract: A distributed system for collecting and processing packet routing information is provided. A service provider, such as a content delivery network service provider, can maintain multiple Points of Presence (“POPs”). Routing computing devices associated with each POP can forward information about the packet routing information to a packet routing management component. The packet routing component can process the information provided by the various POPs. The packet routing component can then update, or otherwise modify, packet routing information used by one or more of the POPs. Accordingly, the packet routing management component can then selectively distribute the updated or modified packet routing information, including the distribution to all POPs, the targeted distribution to specific POPs and the creation of centrally accessible routing information.

Abstract: Commitments against various resources can be dynamically adjusted for customers in a shared-resource environment. A customer can provision a data volume with a committed rate of Input/Output Operations Per Second (IOPS) and pay only for that commitment (plus any overage), for example, as well as the amount of storage requested. The customer can subsequently adjust the committed rate of IOPS by submitting an appropriate request, or the rate can be adjusted automatically based on any of a number of criteria. Data volumes for the customer can be migrated, split, or combined in order to provide the adjusted rate. The interaction of the customer with the data volume does not need to change, independent of adjustments in rate or changes in the data volume, other than the rate at which requests are processed.

Abstract: Methods and systems for cursor remirroring are disclosed. A mirroring process is initiated for a plurality of chunks stored by a master node. The mirroring process comprises visiting a sequence of one or more of the chunks and, for at least some of the chunks, copying chunk data or metadata to a slave node. During the initiated mirroring process, a request is received for a write operation on one of the chunks stored by the master node. If the chunk in the request has been visited in the mirroring process, the write operation is performed on the master node and on the slave node. If the chunk in the request has not been visited, the write operation is performed on the master node and postponed on the slave node until the chunk in the request has been visited in the mirroring process.

Abstract: An opportunistic throttling approach can be used for customers of shared resources in a multi-tenant environment. Each customer can have a respective token bucket with a guaranteed fill rate. When a request is received for an amount of work to be performed by a resource, the corresponding number of tokens are obtained from, or charged against, a global token bucket. If the global bucket has enough tokens, and if the customer has not exceeded a maximum work rate or other such metric, the customer can charge less than the full number of tokens against the customer's token bucket, in order to reduce the number of tokens that need to be taken from the customer bucket. Such an approach can enable the customer to do more work and enable the customer's bucket to fill more quickly as fewer tokens are charged against the customer bucket for the same amount of work.

Abstract: A group of computers is configured to implement a block storage service. The block storage service includes a block-level storage for storing data from a set of distinct computing instances for a set of distinct users. An interface is configured to allow the set of distinct users to specify respective destinations for storing backup copies of respective data stored in the block-level storage for the distinct users. At least some of the respective destinations are for different storage systems remote from one another. A backup copy function is provided for creating backup copies of data stored in the block-level storage by the set of distinct computing instances for the set of distinct users. The backup copies are stored in different destination locations specified by respective ones of the plurality of distinct users via the interface.

Abstract: A set of virtualized computing services may include multiple types of virtualized data store differentiated by characteristics such as latency, throughput, durability and cost. A sequence of captures of a data set from one data store to another may be scheduled to achieve a variety of virtualized computing service user and provider goals such as lowering a probability of data loss, lowering costs, and computing resource load leveling. Data set captures may be scheduled according to policies specifying fixed and flexible schedules and conditions including flexible scheduling windows, target capture frequencies, probability of loss targets and/or cost targets. Capture lifetimes may also be managed with capture retention policies, which may specify fixed and flexible lifetimes and conditions including cost targets. Such data set capture policies may be specified with a Web-based administrative interface to a control plane of the virtualized computing services.

Abstract: Usage of shared resources can be managed by enabling users to obtain different types of guarantees at different times for various types and/or levels of resource capacity. A user can select to have an amount or rate of capacity dedicated to that user. A user can also select reserved capacity for at least a portion of the requests, tasks, or program execution for that user, where the user has priority to that capacity but other users can utilize the excess capacity during other periods. Users can alternatively specify to use the excess capacity or other variable, non-guaranteed capacity. The capacity can be for any appropriate functional aspect of a resource, such as computational capacity, throughput, latency, bandwidth, and storage. Users can submit bids for various types and combinations of excess capacity, and winning bids can receive dedicated use of the excess capacity for at least a period of time.

Abstract: Methods and apparatus for implementing anycast flow stickiness in stateful sessions are described. For the first packet from a source device to an anycast group, a destination anycast endpoint is selected from the anycast group by a routing process via an algorithm that is specified for the anycast group. A record of the mapping of the source device to the destination anycast endpoint may be stored. Additional packets in the flow are routed to the same anycast endpoint as the first packet according to the stored information. Alternatively, a hashing technique may be used to route packets to an anycast endpoint. The packets may be encapsulated in an encapsulation format that includes network substrate routing information to the destination anycast endpoint; anycast forwarding decisions are made at the overlay network level and not at the network substrate level, and thus flow stickiness can be maintained.

Abstract: Commitments against various resources can be dynamically adjusted for customers in a shared-resource environment. A customer can provision a data volume with a committed rate of Input/Output Operations Per Second (IOPS) and pay only for that commitment (plus any overage), for example, as well as the amount of storage requested. The customer can subsequently adjust the committed rate of IOPS by submitting an appropriate request, or the rate can be adjusted automatically based on any of a number of criteria. Data volumes for the customer can be migrated, split, or combined in order to provide the adjusted rate. The interaction of the customer with the data volume does not need to change, independent of adjustments in rate or changes in the data volume, other than the rate at which requests are processed.

Abstract: A request to copy at least a portion of a first network that includes a first set of devices is received, the request including one or more filtering criteria, with at least one of the one or more filtering criteria specifying a tag assigned to a device of the first set of devices. At least the portion of the first network is copied by causing the system to create, according to the one or more filtering criteria, a second network by causing a second set of devices to be configured to be duplicative of devices of the first set of devices that are assigned the tag specified by the filtering criteria.

Abstract: A group of computers is configured to implement a block storage service. The block storage service includes a block-level storage for storing data from a set of distinct computing instances for a set of distinct users. An interface is configured to allow the set of distinct users to specify respective destinations for storing backup copies of respective data stored in the block-level storage for the distinct users. At least some of the respective destinations are for different storage systems remote from one another. A backup copy function is provided for creating backup copies of data stored in the block-level storage by the set of distinct computing instances for the set of distinct users. The backup copies are stored in different destination locations specified by respective ones of the plurality of distinct users via the interface.

Abstract: Virtual data stores may be sparsely provisioned by virtual data storage services in a manner that controls risk of implementation resource shortages. Relationships between requested data storage space size, data storage server capacity, allocated data storage space size and/or allocated data storage space utilization may be tracked on a per data store, per customer, per data storage server, and/or a per virtual data storage service basis. For each such basis, a set of constraints may be specified to control the relationships. The set of constraints may be enforced during implementation resource allocation, and by migration of data storage space portions to different implementation resources as part of a sparse provisioning load balancing. Sparse provisioning details may be made explicit to virtual data storage service customers to varying degrees including explicit, aggregate on a per customer basis, and aggregate on a per virtual data storage service basis.

Abstract: The effects on networking systems of attacks on vulnerabilities, such as vulnerable modules in a webserver, SYN flooding, etc, can be devastating to a network environment. In various embodiments, a first, quick, or inexpensive analysis is performed on incoming network flows. If an intrusion issue or other problem is suspected based on the first, rapid, or an inexpensive analysis, then the flow can be flagged for redirection to another process, virtual machine, or physical computer module that will perform a deeper, more expensive analysis on the network flow. If there are no issues detected in the second, deeper analysis, then the network flow can be forwarded to its intended recipient. If an issue is detected in the second, deeper analysis, then the network flow can be throttled, quarantined, ignored, sent to an un-trusted portion of the system, sent for more analysis, or otherwise handled or flagged.

Abstract: A set of virtualized computing services may include multiple types of virtualized data store differentiated by characteristics such as latency, throughput, durability and cost. A sequence of captures of a data set from one data store to another may be scheduled to achieve a variety of virtualized computing service user and provider goals such as lowering a probability of data loss, lowering costs, and computing resource load leveling. Data set captures may be scheduled according to policies specifying fixed and flexible schedules and conditions including flexible scheduling windows, target capture frequencies, probability of loss targets and/or cost targets. Capture lifetimes may also be managed with capture retention policies, which may specify fixed and flexible lifetimes and conditions including cost targets. Such data set capture policies may be specified with a Web-based administrative interface to a control plane of the virtualized computing services.

Abstract: Techniques are described for managing access of executing programs to non-local block data storage. In some situations, a block data storage service uses multiple server storage systems to reliably store block data that may be accessed over one or more networks by programs executing on other physical computing systems. Users may create block data storage volumes that are each stored by at least two of the server block data storage systems, and may initiate use of such volumes by one or more executing programs, such as in a reliable manner by enabling an automatic switch to a second volume copy if a first volume copy becomes unavailable. A group of multiple server block data storage systems that store block data volumes may in some situations be co-located at a data center, and programs that use volumes stored there may execute on other physical computing systems at that data center.

Abstract: A storage management system monitors an indicator of durability of a dataset hosted by a current implementation resource, such as a storage server. The indicator may be used to determine whether none, some or all of the data storage should be moved from the current implementation resource to an available implementation resource.