Amazon Technologies, Inc.

Dylan Owen Marriner

Marc John Brooker

Julian Embry Herwitz

Mauricio Roman

Sean Philip Reque

Mikhail Danilov

Matthew Joseph Zulak

Sean Tyler Myers

Deepthi Chelupati

David Nasi

Sanath Kumar Ramesh

Suganya Rajendran

Guanghao Ding

Systems and methods are described for a multi-tenant mode of a serverless code execution system. For instance, a method may include maintaining a set of execution environments, wherein each execution environment is associated with a serverless function, wherein the serverless function is associated with a software as a service (SaaS) provider that is a tenant of a cloud services provider, wherein the SaaS provider provides services to sub-tenants, wherein the set of execution environments are partitioned based on sub-tenants of the SaaS provider; receiving a call to execute a serverless function, wherein the call includes a serverless function identifier and a sub-tenant identifier; identifying a sub-tenant-specific execution environment of the set of execution environments that is associated with the sub-tenant; and in response to identifying the tenant-specific execution environment, invoking the serverless function on the sub-tenant-specific execution environment.

Multi-tenant mode for serverless code execution

Systems and methods are described for adjusting a number of concurrent code executions allowed to be performed for a given user on an on-demand code execution environment or other distributed code execution environments. Such environments utilize pre-initialized virtual machine instances to enable execution of user-specified code in a rapid manner, without delays typically caused by initialization of the virtual machine instances. However, to improve utilization of computing resources, such environments may temporarily restrict the number of concurrent code executions performed on behalf of the given user to a number less than the maximum number of concurrent code executions allowed for the given user. Such environments may adjust the temporary restriction on the number of concurrent code executions based on the number of incoming code execution requests associated with the given user.

Adjusting variable limit on concurrent code executions

An event-driven compute service upgrades an execution environment for registered functions of the compute service. Some compute nodes of the service have an updated version of the execution environment and some compute nodes have the old version of the execution environment. As a part of the upgrade process, some functions are executed in both environments. For example, for some invocations of a particular function, the function is executed in the updated execution environment while for other invocations of the same function, the function is executed in the old execution environment. Based on resulting status of the executions, the compute service determines that the particular function is compatible or incompatible with the updated version of the execution environment. The compute service performs subsequent executions of incompatible functions in the old version of the execution environment instead of in the updated version. A client may be notified of the incompatibility.

Upgrading an execution environment for event-driven functions

Systems and methods are described for managing reuse of sandboxed computing environments in a network-based on-demand code execution system. Users may generate tasks on the system by submitting code to a frontend, which may interact with multiple worker managers that manage task execution in sandboxed computing environments such as containers or virtual machine instances. A sandbox may be reusable once provisioned, but the resources required to definitively locate an idle sandbox may be significant relative to the cost of provisioning a new sandbox. The system may therefore manage reuse by randomly or semi-randomly selecting a worker manager and requesting that it provide an existing sandbox if one is available. If not, then the system may select a different worker manager and repeat the request, or after consuming a threshold amount of resources may request that the next worker manager provision a new sandbox if an existing one is not available.

Managing sandbox reuse in an on-demand code execution system

Computing resource service providers operate various services used to provide functionality to customers and other computing resources operated by various entities. These services may use consistent hash rings to direct a request to a particular worker. Previous versions of the consistent hash ring may be maintained such that predecessor information can be determined. When a request is received the request and predecessor information may be provided to a worker manager. The worker manager may utilize the predecessor information to obtain state information from a predecessor worker manager. The state information may then be used to process the request.

Safe deployment using versioned hash rings

A hash ring is used to determine and deploy configurations for a computer system for servicing customer requests. A worker manager managing a set of worker computing systems is deployed and associated with the hash ring. Various aspects of the computer system may be implemented according to configuration information for one or more attributes. Predecessor information is determined and used to obtain state information in connection with the configuration information.

Resource distribution using attributes of versioned hash rings

Systems and methods are described for adjusting a number of concurrent code executions allowed to be performed for a given user on an on-demand code execution environment or other distributed code execution environments. Such environments utilize pre-initialized virtual machine instances to enable execution of user-specified code in a rapid manner, without delays typically caused by initialization of the virtual machine instances. However, to improve utilization of computing resources, such environments may temporarily restrict the number of concurrent code executions performed on behalf of the given user to a number less than the maximum number of concurrent code executions allowed for the given user. Such environments may adjust the temporary restriction on the number of concurrent code executions based on the number of incoming code execution requests associated with the given user and based on communication among the frontends processing the incoming code execution requests.

Growing community of inventors

Seattle, WA, United States of America

Dylan Owen Marriner