Abstract: A materialization configuration request is received via a programmatic interface from a client of a journal-based multi-data-store database. The request indicates a partitioning rule to be used to select, for respective writes indicated in committed transaction entries of a journal, the materialization node at which the writes are to be stored. A control plane component of the database verifies that a set of materialization nodes corresponding to the partitioning rule has been established, and initiates the propagation of writes from the journal to the materialization nodes by respective write appliers.

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 journal manager of a multi-data-store storage system receives a transaction which includes a message to be stored in the storage system's journal if the transaction request is accepted for commit. The journal manager performs a conflict detection operation, accepts the transaction request, and stores a corresponding committed transaction entry including the message in the journal. A write applier associated with a registered materialization node of the journal reads the committed transaction entry and applies a write indicated in the entry. A registered message subscriber of the journal reads the committed transaction entry asynchronously with respect to the write applier, and reads the contents of the message without applying the write.

Abstract: Systems and methods dynamically manage replicas of data sets. A collection of data stores is used to redundantly store one or more replicas of one or more data sets. The replicas may be used to respond to read requests from multiple sources. Upon identification of a need to allocate storage space to a data object, space used by one or more of the replicas is allocated to the data object. Various parameters may be utilized in the selection of one or more replicas whose storage space can be allocated to the data object. The parameters may be based at least in part on characteristics of the one or more data sets relative to one another.

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: 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: 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 storage management system monitors relationships between data sets stored on current implementation resources, such as a storage servers. The relationships may be used to determine whether a data set should be moved from a current implementation resource to an available implementation resource.

Abstract: A storage management system monitors an indicator of whether data storage is or will be sufficiently responsive 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: Systems and methods dynamically manage replicas of data sets. A collection of data stores is used to redundantly store one or more replicas of one or more data sets. The replicas may be used to respond to read requests from multiple sources. Upon identification of a need to allocate storage space to a data object, space used by one or more of the replicas is allocated to the data object. Various parameters may be utilized in the selection of one or more replicas whose storage space can be allocated to the data object. The parameters may be based at least in part on characteristics of the one or more data sets relative to one another.

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: Systems, methods, and computer-readable media for network routing metering are disclosed. In some embodiments, various changes to the routes, and other actions requested by a computer system, physical or virtual, can be metered. Those actions may be performed and later rated in order to determine what amount, if any, to charge an account associated with the requesting network participant system. The network participant system can be billed based on the activities performed on its behalf. Therefore, even if a network is performing poorly and requires more resources that would normally be allowed by a neighboring router, if the network owner pays to have these requests performed, then the embodiments herein can allocate more resources to supporting the network's rapidly changing network.

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: Customers of shared resources in a multi-tenant environment can have token buckets allocated that have an associated depth and fill rate, with each token enabling the customer to obtain an amount of work from a shared resource. A resource management system can monitor one or more system or output metrics, and can adjust a global fill rate based at least in part upon values of the monitored metrics. Such an approach can provide a fair distribution of work among the customers, while ensuring that the metrics stay within acceptable ranges and there are no drastic changes in performance levels of the system. The fill rate can update dynamically with changes in the monitored parameters, such that the system can float near an equilibrium point. Commitments for specific minimum service levels also can be met.

Abstract: Customers of shared resources in a multi-tenant environment can have token buckets allocated that have an associated depth and fill rate, with each token enabling the customer to obtain an amount of work from a shared resource. A resource management system can monitor one or more system or output metrics, and can adjust a global fill rate based at least in part upon values of the monitored metrics. Such an approach can provide a fair distribution of work among the customers, while ensuring that the metrics stay within acceptable ranges and there are no drastic changes in performance levels of the system. The fill rate can update dynamically with changes in the monitored parameters, such that the system can float near an equilibrium point. Commitments for specific minimum service levels also can be met.

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