Lambda isolation technologies

Lambda uses a variety of open-source and proprietary isolation technologies to protect Workers and execution environments. Each execution environment contains a dedicated copy of the following items:

• The code of the particular function version.

• Any AWS Lambda layers selected for your function version.

• The chosen function runtime (for example, Java 11, NodeJS 12, Python 3.8, and so on) or the function's custom runtime.

• A writeable /tmp directory.

• A minimal Linux user space based on Amazon Linux 2.

Execution environments are isolated from one another using several container-like technologies built into the Linux kernel, along with AWS proprietary isolation technologies. These technologies include:

• Control groups (cgroups) – Used to constrain the function's access to CPU and memory.

• Namespaces – Each execution environment runs in a dedicated namespace. We do this by having unique group process IDs, user IDs, network interfaces, and other resources managed by the Linux kernel.

• seccomp-bpf – To limit the system calls (syscalls) that can be used from within the execution environment.

• iptables and routing tables – To prevent ingress network communications and to isolate network connections between MVMs.

• chroot – Provide scoped access to the underlying filesystem.

• Firecracker configuration – Used to rate limit block device and network device throughput.

• Firecracker security features – For more information about Firecracker's current security design, refer to Firecracker's latest design document.

Along with AWS proprietary isolation technologies, these mechanisms provide strong isolation between execution environments.

Storage and state

Execution environments are never reused across different function versions or customers, but a single environment can be reused between invocations of the same function version. This means data and state can persist between invocations. Data and/or state may continue to persist for hours before it is destroyed as a part of normal execution environment lifecycle management.

For performance reasons, functions can take advantage of this behavior to improve efficiency by keeping and reusing local caches or long-lived connections between invocations. Inside an execution environment, these multiple invocations are handled by a single process, so any process-wide state (such as a static state in Java) can be available for future invocations to reuse, if the invocation occurs on a reused execution environment.

Each Lambda execution environment also includes a writeable filesystem, available at /tmp. This storage is not accessible or shared across execution environments. As with the process state, files written to /tmp remain for the lifetime of the execution environment. This allows expensive transfer operations, such as downloading machine learning (ML) models, to be amortized across multiple invocations. Functions that don’t want to persist data between invocations should either not write to /tmp, or delete their files from /tmp between invocations. The /tmp directory is encrypted at rest.

If you want to persist data to the file system outside of the execution environment, consider integrating Lambda with Amazon EFS. For more information, refer to Using Amazon EFS with Lambda.

If you don’t want to persist data or state across invocations, we recommend that you do not use the execution context or execution environment to store data or state. If you want to actively prevent data or state leaking across invocations, we recommend you create distinct functions for each state. We do not recommend that you use or store security sensitive state into the execution environment, as it may be mutated between invocations. We recommend recalculating the state on each invocation instead.