Amazon Technologies, Inc.

Daniel Robert Gerdesmeier

Anthony Joseph Suarez

Scott Kerns Windsor

Nare Alan Hayrapetyan

Pooja Kalpana Prakash

Anirudh Balachandra Aithal

Kiran Kumar Meduri

Deepak Singh

Muhammad Umer Azad

William Andrew Thurston

Euan Skyler Kemp

Christopher Brian Barclay

Archana Srikanta

Carlos Eduardo Lopez Biagi

A request to store a container image is received from a device associated with a customer of a computing resource service provider. Validity of a security token associated with the request is authenticated using a cryptographic key maintained as a secret by the computing resource service provider. One or more layers of the container image is built based at least in part on at least one build artifact to form a set of built layers. The software image including the set of built layers is stored in a repository associated with the customer. A manifest of metadata for the set of built layers is stored in a database of a structured data store. The container image is obtained in the form of an obtained container image. The obtained container image is deployed as the software container in at least one virtual machine instance associated with the customer.

Software container registry service

A task definition is received. The task definition indicates at least a location from which one or more software image can be obtained and information usable to determine an amount of resources to allocate to one or more software containers for the one or more software image. A set of virtual machine instances in which to launch the one or more software containers is determined, the one or more software image is obtained from the location included in the task definition and is launched as the one or more of software containers within the set of virtual machine instances.

System for managing and scheduling containers

A request to update a software container image within a container registry hosted by a computing resource service provider is received from an entity associated with a customer account with the computing resource service provider, where the container registry is a scalable distributed data storage service. The software container image is stored in the container registry in association with the customer account. A layer of the software container image stored in the container registry is scanned for a reference identifier associated with a security vulnerability as a result of said scan finding the reference identifier within the software container image, notice is provided to the entity indicating that the security vulnerability was found. Software within the software container image is updated based at least in part on the vulnerability scan; and the update software is deployed.

Techniques for instantiating container instances from a pool of available container instances are described herein. An instance type is determined from a container description such that the instance type satisfies the resource parameters in the container description. An instance of the instance type is selected from a pool of running container instances, the instance is provisioned, and a container is instantiated on the instance.

Managed container instances

A request to store, in first data store associated with a customer of a computing resource service provider, a software image is received, the request including a set of layers of the software image to be stored. As a result of successful authentication of the request, based at least in part on a security token included with the request, a subset of layers of the software image that have not previously been stored in the first data store are determined, based at least in part on first metadata obtained from a second data store, the subset of layers in the first data store are stored, second metadata about the subset of layers are stored in the second data store, and the software image is caused to be launched in a software container of an instance based at least in part on the subset of layers.

A request to a scan a software image for specified criteria is received, the software image comprising layers stored in a first data store. Metadata in a second data store, different from the first data store, is searched through to obtain information corresponding to the software image. A first set of the layers that matches the specified criteria is determined, based at least in part on the information. The first set of layers is marked as un-referenceable. Asynchronous to fulfillment of the request, a second set of layers of the layers to be deleted is determined, based at least in part on the metadata, the second set of layers including layers marked as un-referenceable, and the second set of layers is deleted.

Software container registry inspection

A software image associated with a first customer of a computing resource service provider and criteria for identifying an event is received, the software image comprising a set of layers. The set of layers is stored in a first data store to form a stored set of layers, the first data store being physically located in a first region. The set of layers is copied to a second data store to form a copied set of layers, the second data store being physically located in a second region different from the first region. The copied set of layers is launched as a container executing in an instance that is physically located in the second region, and, as a result of identifying an occurrence of the event, the container is caused to be unavailable to an entity associated with the instance.

Software container registry container image deployment

A system and method for a container service that obtains a software image of a software container that has been configured to be executed within a computer system instance registered to a cluster by one or more processors. The container service is configured to receive a request to launch the software image in accordance with a task definition, wherein the task definition specifies an allocation of resources for the software container. The container service may then determine, according to a placement scheme, a subset of a set of container instances registered to the cluster in which to launch the software image in accordance with the task definition. Upon determining the subset of the set of container instances, the container service may launch the software image as one or more running software containers in the set of container instances in accordance with the task definition.

Growing community of inventors

Seattle, WA, United States of America

Daniel Robert Gerdesmeier