Abstract: Methods and apparatus for client-directed placement of remotely configured service instances are described. One or more placement target options are selected for a client of a network-accessible service based on criteria such as service characteristics of the placement targets. The selected options, including a particular placement target that includes instance hosts configurable from remote control servers, are indicated programmatically to the client. A determination is made that a service instance is to be configured at the particular placement target on behalf of the client. A remote control server is configured to issue administrative commands to an instance host at the particular placement target to configure the service instance.

Abstract: Methods and apparatus for flexible batch job scheduling in virtualization environments are disclosed. A descriptor for a batch job requested by a client is received at a job scheduling service. The descriptor comprises an indication of a time range during which a job iteration may be performed. A target time for executing the iteration is determined based on an analysis of a plurality of received descriptors. An indication of the target time at which the iteration is to be scheduled is provided to a selected execution platform.

Abstract: Methods and apparatus for client-directed placement of remotely configured service instances are described. One or more placement target options are selected for a client of a network-accessible service based on criteria such as service characteristics of the placement targets. The selected options, including a particular placement target that includes instance hosts configurable from remote control servers, are indicated programmatically to the client. A determination is made that a service instance is to be configured at the particular placement target on behalf of the client. A remote control server is configured to issue administrative commands to an instance host at the particular placement target to configure the service instance.

Abstract: Techniques are described for providing service availability zones for computing-related services provided by a cloud provider network. According to some embodiments, the use of service availability zones enables users to achieve greater availability assurance for workloads sensitive to downtime or outages. The sensitivity of such workloads to downtime may be due to financial, regulatory, safety, or other reasons. Such availability-sensitive applications may in some cases be configured to run in multiple regions of a cloud provider network to increase their availability compared to running in a single availability zone. However, for some applications, the implementation of an application across multiple regions may not be feasible or desirable. The use of service availability zones provides user-visible fault domains within a single region of a cloud provider network, thereby enabling users to readily and reliably achieve application layer availability of approximately 99.

Abstract: A storage manager implements adaptive snapshot chunk sizing, wherein snapshot chunks are sized differently based on an access pattern for volume data to be included in the respective snapshot chunks. For example, sequentially accessed sectors of a volume may be grouped into snapshot chunks of varying sizes and individually accessed sectors may be snapshotted as individual snapshot chunks. When a volume is populated from the snapshot chunks, the volume data is re-mapped into standard sized volume blocks. In some embodiments, an optimized manifest is generated indicting an order in which the snapshot chunks are to be used to populate a volume to perform a launch process using the volume. In some embodiments, adaptively sized snapshot chunks and a corresponding optimized manifest are used to accelerate performing a launch using a volume populated from a snapshot, such as launching an operating system, an application, a database, a machine image, etc.

Abstract: Disclosed are various embodiments for a system that hardware locks a virtual machine to a host machine. The host machine can include a processor and a memory. A hypervisor can be stored in the memory that, when executed by the processor, causes the computing device to host one or more virtual machines. In addition, machine readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least: receive a request to perform an operation on a virtual machine hosted by the hypervisor; evaluate the request to determine that the request complies with a policy; and in response to a determination that the request complies with the policy, cause the hypervisor to initiate the operation.

Abstract: A first communicating entity determines session state parameters of a security protocol session between itself and a second communicating entity. The first entity uses the session state parameters to transmit a first set of messages of the session to the second entity via a first communication mechanism. The first entity also uses the session state parameters to transmit a second set of messages of the session to the second entity via a second communication mechanism.

Abstract: Methods and apparatus that allow clients to specify custom network rules for their resource instances or network constructs in a provider network environment. Services and interfaces may be provided that allow a client to provide an executable module that implements custom rules for their resources, or alternatively to specify or select custom rules for their resources. The module may be installed on a host device, and may apply the custom rules to packets to and from the client's resources. Alternatively, the client-defined rules may be applied to packet flows according to the custom rules specified by the client and applied by a client rules service implemented on the provider network external to the host device or on a client resource instance on the host device. The custom network rules may, for example, extend or modify standard network rules for the client's resources on the host device.

Abstract: Systems and methods are disclosed to implement a request routing layer of a service provider system, where the request routers are aware of different versions of a service implemented by the servers of the system. In embodiments, the request routers may discover the different versions of the service via periodic health messages or request responses from the servers. Requests are routed to the servers according to a routing policy that specifies the relative proportions of requests that are to be routed to each version. Version metrics generated from the requests may be captured and provided to a version change manager, which may update the routing policy based on the metrics, either increasing or decreasing the proportion of requests for the different versions. In embodiments, the request router may implement additional rules that control their routing behavior in response to detected error conditions.

Abstract: Techniques for monitoring computer system components for degraded operation are described. In some embodiments, a baseline performance metric value is received from a system monitoring service, a request directed to an input/output (I/O) device is received that was generated by a first computing device, a timer is started, the timer having a duration based on the baseline performance metric value, the received request is sent to the I/O device, an error message is generated upon expiration of the duration of the timer before a response to the request is received from the I/O device, and the generated error message is sent to a second computing device to cause the second computing device to perform at least one action in response to the generated error message.

Abstract: Techniques are described for enabling customers of a service provider network to modify and extend the functionality of application programming interfaces (APIs) provided to customers by various services of the provider network. Services of a service provider network provide interfaces that enable customers and other users to define custom API actions representing functionality to be performed by the services upon receipt of corresponding API requests. In this manner, the functionality exposed by provider network services to customers via APIs becomes extensible and customizable to fit customers' particular use cases and without the provider network needing to contemplate and explicitly implement all possible customer-specific API action variations.

Abstract: Methods and apparatus for profile-guided preloading for virtualized resources are described. A block-level storage volume whose contents are to be populated via data transfers from a repository service is programmatically attached to a compute instance. An indication of data transfers from the repository to a block storage service implementing the volume is obtained, corresponding to a particular phase of program execution at the compute instance. A storage profile is generated, based at least in part on the indication of data transfers. The storage profile is subsequently used to pre-load data from the repository service on behalf of other compute instances.

Abstract: Techniques are described for enabling customers of a service provider network to modify and extend the functionality of application programming interfaces (APIs) provided to customers by various services of the provider network. Services of a service provider network provide interfaces that enable customers and other users to define custom API actions representing functionality to be performed by the services upon receipt of corresponding API requests. In this manner, the functionality exposed by provider network services to customers via APIs becomes extensible and customizable to fit customers' particular use cases and without the provider network needing to contemplate and explicitly implement all possible customer-specific API action variations.

Abstract: Techniques for configurable compute instance resets are described. A user can issue a request to securely reset one or more compute instances implemented within a service provider system. Each compute instance is reset to a previous point in time, such that any activity of the compute instance or effects thereof occurring since that point in time are completely eliminated. Each compute instance reset can include removing an existing volume of the compute instance, obtaining a volume, attaching the obtained volume to the compute instance, and rebooting the compute instance. Configuration data of the compute instance, such as an instance identifier or network addresses, can be maintained after the reset.

Abstract: A peripheral device may accelerates deployment of a virtual computing resource at a resource host. Storage locations in a memory of a host may be identified for an image of a virtual computing resource to be implemented at the host. The image data may be prepared to be hosted by the peripheral device. The peripheral device may store the prepared image in the storage locations via a direct memory access channel between the peripheral device and the host memory instead of writing the prepared image via a processor of the host system.

Abstract: Systems and methods are disclosed to implement a request routing layer of a service provider system, where the request routers are aware of different versions of a service implemented by the servers of the system. In embodiments, the request routers may discover the different versions of the service via periodic health messages or request responses from the servers. Requests are routed to the servers according to a routing policy that specifies the relative proportions of requests that are to be routed to each version. Version metrics generated from the requests may be captured and provided to a version change manager, which may update the routing policy based on the metrics, either increasing or decreasing the proportion of requests for the different versions. In embodiments, the request router may implement additional rules that control their routing behavior in response to detected error conditions.

Abstract: Techniques are described for automatically adapting conditions associated with triggers used to monitor the performance of computing resources managed by a service provider or other entity. The monitored computing resources can include, for example, virtual machines (VMs), physical servers, applications, or any combinations thereof. Metric data generated by or otherwise obtained from the monitored computing resources—for example, metrics measuring CPU utilization, network latency, or other performance characteristics of the computing resources—is collected and tracked by a monitoring service of a service provider network. The monitoring service can be used generally to monitor and track computing resource utilization, application performance, and operational health of one or more computing resources based on collected metric data.

Abstract: Systems and methods are disclosed to implement a request routing layer of a service provider system, where the request routers are aware of different versions of a service implemented by the servers of the system. In embodiments, the request routers may discover the different versions of the service via periodic health messages or request responses from the servers. Requests are routed to the servers according to a routing policy that specifies the relative proportions of requests that are to be routed to each version. Version metrics generated from the requests may be captured and provided to a version change manager, which may update the routing policy based on the metrics, either increasing or decreasing the proportion of requests for the different versions. In embodiments, the request router may implement additional rules that control their routing behavior in response to detected error conditions.

Abstract: Techniques for configurable compute instance resets are described. A user can issue a request to securely reset one or more compute instances implemented within a service provider system. Each compute instance is reset to a previous point in time, such that any activity of the compute instance or effects thereof occurring since that point in time are completely eliminated. Each compute instance reset can include removing an existing volume of the compute instance, obtaining a volume, attaching the obtained volume to the compute instance, and rebooting the compute instance. Configuration data of the compute instance, such as an instance identifier or network addresses, can be maintained after the reset.

Abstract: Functionality is disclosed for throughput and latency optimized volume initialization. Data blocks used for boot processes of multiple virtual machine (VM) instances are identified, for example, where the multiple VM instances are created from a specific VM image. A load order document is generated that identifies the data blocks, and also identifies an order in which the data blocks are used for the boot process. The identified data blocks are coalesced to generated a coalesced boot volume. Subsequently, each time a VM instance is created from the specific VM image, the coalesced boot volume (e.g., instead of the individual data blocks) is transmitted from a data store to the a block storage service in the order specified by the load order document. The block storage service exposes a storage volume to the VM instance that can be used to initialize the VM instance.