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 controller is implemented for controlling a storage system. The storage controller may be implemented using a distributed computer system and may include components for servicing client data requests based on the characteristics of the distributed computer system, the client, or the data requests. The storage controller is scalable independently of the storage system it controls. All components of the storage controller, as well as the client, may be virtual or hardware-based instances of a distributed computer system.

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: The behavior of multiple users with access to a multi-tenant resource can be monitored and compliance enforced by monitoring state information for each user. The state information can be captured across a level of a network environment, such that any activity across that layer can be monitored and the data aggregated to give a global view of user behavior. If user behavior is determined to fall outside an acceptable range of behavior, any of a number of remedial actions can be taken, which can include notifying the user, billing the user for the inappropriate behavior, or modifying that behavior outside of the control of the user.

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 network-accessible block data storage volumes that may be used by programs executing on other physical computing systems. 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. If a program using a volume becomes unavailable, another program (e.g., another copy of the same program) may in some situations obtain access to and continue to use the same volume, such as in an automatic manner in some such situations.

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 copies of network-accessible block data storage volumes that may be used by programs executing on other physical computing systems, and snapshot copies of some volumes may also be stored (e.g., on remote archival storage systems). 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 computing systems at that data center, while the archival storage systems may be located outside the data center. The snapshot copies of volumes may be used in various ways, including to allow users to obtain their own copies of other users' volumes (e.g., for a fee).

Abstract: A block storage service provides block-level storage to a plurality of distinct computing instances for a plurality of distinct users. For each of one or more of the plurality of distinct computing instances, information about data being stored in the block storage service is determined. Based on the information about the data being stored in the block storage service, a block storage transaction enhancement for the data being stored in the block storage service is determined. The block storage service performs the selected block storage transaction enhancement with respect to the data being stored in the block storage service.

Abstract: With the advent of virtualization technologies, networks and routing for those networks can now be simulated using commodity hardware rather than actual routers. For example, virtualization technologies such as those provided by VMWare, XEN, or User-Mode Linux can be adapted to allow a single physical computing machine to be shared among multiple virtual networks by providing each virtual network user with one or more virtual machines hosted by the single physical computing machine, with each such virtual machine being a software simulation acting as a distinct logical computing system that provides users with the illusion that they are the sole operators and administrators of a given hardware computing resource. In addition, routing can be accomplished through software, providing additional routing flexibility to the virtual network in comparison with traditional routing. As a result, in some implementations, supplemental information other than packet information can be used to determine network routing.

Abstract: Various aspects of a data volume or other shared resource are determined and updated dynamically for purposes such as to provide guaranteed qualities of services. For example, the number of partitions in a data volume and/or the way in which data is stored across those partitions can be updated dynamically without significantly impacting the customer using the volume. The data stored to the volume can be striped or otherwise distributed across a number of logical areas, which then can be distributed across the partitions. Separate mappings can be used for the data in each logical area, and the logical areas in each partition, such that when moving a logical area only a single mapping has to be updated, regardless of the amount of data in that logical area. Further, logical areas can be moved between partitions without the need to repartition or redistribute the data in the data volume.

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: 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: Systems, methods and related processes for securely erasing and/or rendering permanently inaccessible data stored on storage systems securely erased is described. Such storage systems may, in some aspects, integrate hardware capable of secure erasure. In some aspects, a cryptographically-based system is utilized.

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 copies of network-accessible block data storage volumes that may be used by programs executing on other physical computing systems, and snapshot copies of some volumes may also be stored (e.g., on remote archival storage systems). 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 computing systems at that data center, while the archival storage systems may be located outside the data center. The snapshot copies of volumes may be used in various ways, including to allow users to obtain their own copies of other users' volumes (e.g., for a fee).

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: A block storage service provides block-level storage to a plurality of distinct computing instances for a plurality of distinct users. For each of one or more of the plurality of distinct computing instances, information about data being stored in the block storage service is determined. Based on the information about the data being stored in the block storage service, a block storage transaction enhancement for the data being stored in the block storage service is determined. The block storage service performs the selected block storage transaction enhancement with respect to the data being stored in the block storage service.

Abstract: Disclosed are various embodiments for replication of machine instances in a computing environment. A clone machine instance is instantiated from a machine image associated with an original machine instance. A stored execution state of the original machine instance is applied to the clone machine instance. At least a portion of a series of stored events received by the original machine instance is applied to the clone machine instance.

Abstract: In response to a request to duplicate a network, the network is duplicated. The duplicate network includes one or more virtual devices that correspond to one or more devices in the network being duplicated. The devices of the duplicate network are communicatively arranged in a manner consistent with a topology of the network being duplicated. Once the duplicate network is created, access to the duplicate network is provided.

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: As exterior routing protocols generally do not provide information about the internal routing paths of an autonomous system, a particular autonomous system has limited information about the internal health of other autonomous systems. However, if a monitoring system has access to routing data and/or other network data from multiple points of an autonomous system, the monitoring system can estimate, with some accuracy, the health of the autonomous system. In turn, by monitoring at least some of autonomous systems forming a larger internetwork, such as the Internet, the monitoring system can estimate the overall health of at least portions of the internetwork.

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.