AWS Lambda

Firecracker, MicroVM, and Host Architecture

A Lambda host is an EC2 bare-metal or Nitro instance running the Lambda Worker software. Inside the host:

Firecracker is the load-bearing piece. It was open-sourced in 2018 (originally written for Lambda; later adopted for Fargate too). Each VMM is a single Rust process with seccomp filters limiting it to roughly 50 syscalls. The jailer chroots Firecracker into a per-microVM directory and drops privileges before the VMM ever touches guest code. The guest kernel is a custom Amazon Linux 2 build with module loading disabled, no PCI bus, and only the virtio devices Lambda needs.

Key Numbers

The Cold-Start Lifecycle

A "cold start" is overloaded terminology. There are at least four distinct phases that contribute to it, and each has different mitigation strategies.

The asymmetry between phases drives optimization choices:

Memory, CPU, and the Linear Coupling

Lambda has one knob the user controls for performance: memory. CPU is allocated proportionally, with breakpoints that AWS does not officially document but that are well-characterized by benchmarks:

The breakpoint at 1,769 MB is the key one: below it, you have less than a full core, and any single-threaded compute is artificially throttled. AWS Lambda Power Tuning (open source state-machine tool) will sweep memory settings for your function and produce a cost-vs-latency Pareto frontier — the result is often counterintuitive, e.g. doubling memory halves duration and halves cost.

// Lambda Power Tuning typical output for a CPU-bound function
// Memory  Duration  Cost (per 1M invocations)
// 128 MB  6,800 ms  $14.20
// 512 MB  1,720 ms  $14.40
// 1024 MB   860 ms  $14.40
// 1769 MB   500 ms  $14.50   <-- 1 vCPU breakpoint
// 3008 MB   480 ms  $24.10   <-- diminishing returns
//
// Sweet spot: 1769 MB for single-threaded work.

Provisioned Concurrency vs SnapStart

For workloads where cold-start latency is unacceptable, Lambda offers two distinct mechanisms:

// Java SnapStart: regenerate connections after restore
import org.crac.Resource;
import org.crac.Core;

public class DbHandler implements Resource {
  private Connection conn;

  public DbHandler() {
    Core.getGlobalContext().register(this);
  }

  // Called BEFORE snapshot -- close transient state
  public void beforeCheckpoint(org.crac.Context<? extends Resource> ctx) {
    if (conn != null) conn.close();
    conn = null;
  }

  // Called AFTER restore in each new microVM -- recreate
  public void afterRestore(org.crac.Context<? extends Resource> ctx) {
    conn = DriverManager.getConnection(System.getenv("DB_URL"));
  }
}

Execution Environment Reuse and Frozen State

Between invocations, Lambda freezes the microVM using the cgroup freezer subsystem. CPU is paused; memory is retained. When the next invocation arrives, the runtime is unfrozen and resumes. This is why module-scoped variables persist across invocations on the same environment — a fact that's both a powerful optimization and a source of subtle bugs.

// Node.js -- module scope persists across warm invocations
const AWS = require('aws-sdk');
const ddb = new AWS.DynamoDB.DocumentClient(); // Created ONCE per env, reused
const cache = new Map(); // Persists across invocations on the same env

exports.handler = async (event) => {
  if (cache.has(event.id)) return cache.get(event.id); // Warm cache hit
  const item = await ddb.get({ TableName: 'T', Key: { id: event.id } }).promise();
  cache.set(event.id, item.Item);
  return item.Item;
};
// Caveats:
//  - Cache may be on ANY of N parallel envs -- partial hit rate
//  - Setting timers (setInterval) leaks across invocations — freeze stops them, but they fire on thaw
//  - Pending promises that aren't awaited may complete on a future invocation

The freeze/thaw model has three practical consequences:

• Background work is unsafe. A setTimeout or unawaited promise is paused when your handler returns. It may complete on the next invocation — or never, if the environment is reaped.
• File descriptors leak. Open sockets to a database survive freeze. Long-idle sockets get reset by the database; your next invocation gets EPIPE. Use connection-pooling libraries with health checks (e.g. RDS Proxy, or libraries that ping before reuse).
• Wall-clock drifts. A frozen environment doesn't see time pass. Code that caches based on Date.now() can hold stale entries longer than expected.

VPC, Hyperplane ENIs, and the Cold-Start Tax That Was

Pre-2019, attaching a Lambda to a VPC was punitive: Lambda would create an ENI per concurrent execution, and ENI attachment took 5–10 seconds. A burst of 100 cold concurrent invocations meant 100 ENI creations.

AWS replaced this in 2019 with Hyperplane ENIs — shared ENIs in your subnet that Lambda multiplexes across many concurrent function executions using NAT-style port mapping. The result:

• One Hyperplane ENI per (VPC, subnet, security group) combination, regardless of concurrency.
• ENI cold-start tax dropped from seconds to effectively zero.
• Lambda still needs an unused IP in your subnet — if your subnet's CIDR is exhausted, function scaling is capped.
• NAT for outbound: each Hyperplane ENI is a NAT gateway from the function's perspective. Bandwidth is shared across all functions on that ENI.

Function URLs vs API Gateway vs ALB

Function URLs (released 2022) are the lightest-weight option: a stable HTTPS URL with TLS termination, zero per-request charge beyond Lambda itself, and support for response streaming via the Lambda invoke-with-response-stream API. They lack the ergonomics of API Gateway (no resource models, no request validation, no integrated WAF), but for <10 RPS internal tools they're hard to beat.

Lambda Layers, Container Images, and the Deployment Question

Lambda has two deployment models that look similar but behave differently:

# Zip deployment (default, fastest cold start)
$ zip -r function.zip handler.js node_modules/
$ aws lambda update-function-code --function-name f --zip-file fileb://function.zip
# Limit: 50 MB zipped, 250 MB unzipped (incl. layers)
# Cold start: fastest -- code is fetched as one blob

# Container image deployment (10 GB ceiling, OCI-compatible)
$ docker build -t my-fn .
$ aws ecr get-login-password | docker login --username AWS --password-stdin <acct>.dkr.ecr.<region>.amazonaws.com
$ docker push <acct>.dkr.ecr.<region>.amazonaws.com/my-fn:latest
$ aws lambda update-function-code --function-name f --image-uri <acct>.dkr.ecr.<region>.amazonaws.com/my-fn:latest
# Lambda: chunks the image into 512 KB blocks, fetches lazily on first read
# Cold start: only marginally slower than zip if image is well-layered

Container images solved the 250 MB limit (huge for ML workloads with PyTorch + model weights), but they require an ECR repo, a VPC endpoint or NAT for ECR if Lambda is in a private subnet, and a Dockerfile based on an AWS-provided base image (or one with the runtime interface client embedded). The chunked lazy-load means a 5 GB image with a Python handler that imports only boto3 may only fetch ~50 MB on first call — but if your handler later loads a 4 GB model, that fetch happens during invocation, on the user's wall clock.

Lambda Layers are a separate mechanism: a zip mounted at /opt on the microVM. Up to 5 layers per function, 250 MB combined unzipped. Layers are deduplicated across functions that reference the same layer ARN, so if 100 of your functions share a 50 MB layer, the layer is fetched once per worker, not once per function. Layers are most useful for cross-function utility code (the AWS SDK is pre-bundled in the runtime, so you don't need to layer it).

Lambda Extensions API

Extensions are out-of-band sidecars that run inside the same microVM as your function. They register with the Lambda extensions API at init time and receive lifecycle events: INVOKE, SHUTDOWN. Common uses: APM agents (Datadog, New Relic), secrets prefetching (AWS Parameters and Secrets Lambda Extension caches Parameter Store values in-memory), log shippers.

# Extension manifest at /opt/extensions/<name>
# It's a binary or script; Lambda starts it, then your runtime
# Lifecycle:
#  1. Lambda starts extension processes from /opt/extensions/
#  2. Each extension calls POST /2020-01-01/extension/register
#  3. Lambda starts your runtime + handler
#  4. On each INVOKE, extensions get notified (parallel to your handler)
#  5. Extensions have until 2 seconds AFTER your handler returns to do work
#     before Lambda freezes the env
#  6. SHUTDOWN event when env is reaped

# Example: AWS Parameters & Secrets Lambda Extension
# Adds layer arn:aws:lambda:<region>:177933569100:layer:AWS-Parameters-and-Secrets-Lambda-Extension:N
# Your handler hits localhost:2773 instead of SSM/Secrets Manager
# 5-minute in-memory TTL -- huge cold-start win for secrets-heavy functions

Lambda@Edge vs CloudFront Functions

At the CloudFront edge, AWS offers two compute options that sound similar but have very different execution models:

CloudFront Functions runs in V8 isolates — the same isolation primitive as Cloudflare Workers, not microVMs. That's why cold start is sub-millisecond but the model is restrictive: no async, no network, 1 ms CPU budget. Lambda@Edge is "real Lambda," replicated across 13+ regional edge caches. Use CloudFront Functions for header manipulation; Lambda@Edge for anything that needs to do real work.

How Lambda Compares to Other Function Platforms

The fundamental trade-off: Workers' V8 isolates give you near-zero cold start at the cost of running only sandboxed JavaScript with no native code. Lambda's microVMs give you any language and any binary, but every cold start pays for VM boot + runtime init. Cloud Run sits in between with concurrency >1 per instance, blunting the cold-start cost across many requests.

Tradeoffs & Failure Modes

• Concurrency limits cause throttles, not queueing. Account-level concurrency is 1,000 by default. Hit it and synchronous invocations get TooManyRequestsException; async invocations retry with exponential backoff for up to 6 hours, then go to your DLQ. Always set a reserved concurrency on critical functions to protect them from being starved by other functions in the account.
• Async retry semantics are surprising. Async invocations retry twice on failure (3 attempts total) with delays of ~1 minute and ~2 minutes. After that, events go to a DLQ if configured. For event sources like SNS, the SNS retry policy is layered on top — you can end up with up to ~20 attempts depending on failures.
• Idempotency is your problem. Lambda may invoke your function more than once for the same event, especially with SQS, Kinesis, and DynamoDB Streams. The function must be idempotent. Use Powertools idempotency utility (DynamoDB-backed) or your own dedupe table.
• Concurrency-per-event-source bottlenecks. SQS standard queues scale Lambda concurrency at +60 per minute, capped at 1,000 per function. A backlog of 100K messages takes ~17 minutes to fully spin up consumers. SQS FIFO and Kinesis are bounded by shard/group count, not Lambda concurrency.
• Init phase has its own timeout. If your global-scope code takes >10 seconds, the init fails and the invocation errors out. Lazy-load instead of eagerly importing everything.
• The 6 MB payload cap is an HTTP body cap, not a JSON-string cap. Base64 encoding for binary in API Gateway eats your budget. For larger payloads, write to S3 and pass a key.
• Hot environments don't load-balance fairly. Lambda routes to "stickiest available warm env first." Module-scoped state on a popular env grows; on a rare env, it's stale or empty. Don't use module scope as cache for anything where staleness matters > minutes.
• SnapStart restore is not free of state. A snapshot is a moment in time. UUIDs generated at init are identical across restored microVMs unless you regenerate them in afterRestore. Be paranoid about anything that "should be unique."