Filter concepts by levelShowing all levels.

AWS · Lambda — Serverless Compute

Lambda — Serverless Compute

The execution lifecycle, invocation models, cold starts and concurrency, and when Lambda is the right fit

  • Init → Invoke → Shutdownoutside-handler code runs once, handler runs per request
  • Sync, async, or event source mappingthree genuinely different invocation models
  • Cold starts under 1%provisioned concurrency pre-warms, reserved concurrency caps
  • At-least-once deliveryhandlers must be idempotent, not exactly-once

1.Lambda Core Vocabulary

A Lambda function runs your handler code in a managed execution environment that goes through Init (bootstrap + your outside-handler code), Invoke (runs the handler per request), and Shutdown (cleanup) phases. Memory (128 MB–10,240 MB) also scales CPU. A version is an immutable snapshot; an alias is a mutable pointer to a version, letting you shift traffic without changing the invoker.

Key features

  • Init phase: bootstrap the runtime, run code outside the handler (e.g. open a DB connection) — capped at 10 seconds on-demand
  • Invoke phase: runs the handler; duration is bounded by the function timeout (1 second–15 minutes)
  • Memory (128 MB–10,240 MB) also scales proportional CPU — more memory can mean faster execution, not just more headroom
  • A version is an immutable, numbered snapshot of code + configuration; an alias is a mutable named pointer to a version
  • Layers package shared dependencies separately from function code, attached by ARN
  • Environment variables carry configuration; secrets should route through Secrets Manager/SSM rather than plain env vars
Execution environment lifecycle
readyfinishesyes — warmstartno —eventually

Init

bootstrap + outside-handler code

Invoke

handler runs per request

Reused?

warm start if yes

Shutdown

cleanup, eventually

  • Init — bootstrap + outside-handler code
    • leads to Invoke (ready)
  • Invoke — handler runs per request
    • leads to Reused? (finishes)
  • Reused? — warm start if yes
    • leads to Invoke (yes — warm start)
    • leads to Shutdown (no — eventually)
  • Shutdown — cleanup, eventually

Signature

Init (once) → Invoke (per request, timeout-bound) → Shutdown

Init runs once per environment (bootstrap + outside-handler code); Invoke runs per request, bounded by timeout. Version = immutable snapshot; alias = mutable pointer callers actually target.

2.Synchronous, Asynchronous, and Event Source Mappings

Synchronous invocation makes the caller wait for a response (API Gateway calling Lambda). Asynchronous invocation queues the event and returns immediately (S3, SNS calling Lambda) — Lambda retries on failure separately from the caller. An event source mapping is Lambda itself polling a source (SQS, DynamoDB Streams, Kinesis) and invoking your function with batches.

Key features

  • Synchronous: caller waits for the response; errors are returned directly to the caller (e.g. API Gateway, ALB)
  • Asynchronous: Lambda queues the event and returns success immediately; retries and failure handling happen separately (e.g. S3, SNS, EventBridge)
  • Event source mapping: Lambda polls the source itself (SQS, DynamoDB Streams, Kinesis) and invokes your function with a batch
  • Streaming sources (DynamoDB Streams, Kinesis) are processed synchronously in order per shard by the poller
  • SQS event source mappings support batching with a configurable batch size and batching window

Which invocation model a source uses

Which invocation model a source uses
TriggerModel
API Gateway, ALBSynchronous
S3 event notifications, SNSAsynchronous
EventBridge rule targetAsynchronous
SQS queueEvent source mapping (polling)
DynamoDB Streams, KinesisEvent source mapping (polling, ordered per shard)
Who controls delivery, and does the caller wait
Synchronous (API Gateway)
caller blocks for the response
Asynchronous (S3, SNS)
queued, returns 202 immediately
Event source mapping (SQS, Kinesis)
Lambda polls, invokes with a batch
  • Synchronous (API Gateway): caller/source pushes, caller waits — caller blocks for the response
  • Asynchronous (S3, SNS): caller/source pushes, returns immediately — queued, returns 202 immediately
  • Event source mapping (SQS, Kinesis): Lambda itself polls, returns immediately — Lambda polls, invokes with a batch

Command

bash
--invocation-type RequestResponse   # synchronous (default)
--invocation-type Event             # asynchronous

Synchronous: caller waits, errors return directly. Asynchronous: Lambda queues and returns immediately, retries happen separately. Event source mapping: Lambda itself polls the source and controls batching.

3.Cold Starts, Reserved and Provisioned Concurrency

A cold start happens when Lambda has to create and initialize a new execution environment before it can run your handler — typically under 1% of invocations, from under 100ms to over 1 second. Reserved concurrency sets a hard min/max on how many concurrent executions a function can use. Provisioned concurrency pre-initializes environments so requests never hit a cold start, at extra cost.

Key features

  • Cold start: Lambda downloads code, starts the environment, runs Init — happens under 1% of invocations
  • Reserved concurrency: both a floor and ceiling for one function's concurrent executions, carved out of the account's shared pool
  • Provisioned concurrency: pre-initialized environments, eliminating cold starts for that many concurrent requests, at extra cost
  • Account default concurrency limit: 1,000 concurrent executions per Region (adjustable via quota increase)
  • A function throttles (drops/retries per invocation type) once it exceeds its available concurrency

Reserved vs provisioned concurrency

Reserved vs provisioned concurrency
PropertyReservedProvisioned
What it guaranteesMax + min concurrency slotsPre-warmed environments
Cold startsStill possibleNot possible while within the provisioned amount
CostNo additional chargeAdditional charge
Effect on other functionsRemoves that capacity from the shared poolNone — separate from reserved
A cold start, end to end
  1. Request arrives

    No warm environment available

    triggers a new environment

  2. +0ms

    Download code

    part of the cold-start cost

  3. +~50-900ms

    Start environment + run Init

    the bulk of the delay

  4. Handler runs

    Request finally processed

    environment stays warm for reuse

  1. Request arrives: No warm environment available — triggers a new environment
  2. +0ms: Download code — part of the cold-start cost
  3. +~50-900ms: Start environment + run Init — the bulk of the delay
  4. Handler runs: Request finally processed — environment stays warm for reuse

Command

bash
aws lambda put-function-concurrency --function-name my-fn --reserved-concurrent-executions 100
aws lambda put-provisioned-concurrency-config --function-name my-fn --qualifier LIVE --provisioned-concurrent-executions 20

Cold start = new environment created on demand, under 1% of invocations. Reserved concurrency = capacity floor/ceiling, no effect on cold starts. Provisioned concurrency = pre-warmed environments, extra cost, eliminates cold starts up to that count.

4.Retries and Idempotency

Lambda's asynchronous invocations retry automatically on failure, and most event sources deliver at-least-once — so the same event can genuinely reach a handler more than once. A handler needs to produce the same end result whether it runs once or twice for the same event.

Key features

  • Async invocations retry automatically on failure — configure a DLQ or on-failure destination to observe and act on final failures
  • Event source mappings (SQS, DynamoDB Streams, Kinesis) generally deliver at-least-once — duplicate invocations for the same event are possible
  • Idempotency means handling the same event twice produces the same end state as handling it once
  • A common idempotency pattern: use a unique event/message ID as a conditional-write key (e.g. DynamoDB conditional put) to detect and skip duplicates

Command

text
At-least-once delivery + automatic retries → handler must be idempotent, not "run exactly once"

Lambda's managed infrastructure comes with at-least-once delivery and automatic retries on failure — write handlers to be idempotent (safe to run twice for the same event), not to assume exactly-once execution.

5.When Lambda Is a Strong Fit

Lambda is a strong fit for event-driven, bursty, short-lived work, where per-invocation billing and zero server management outweigh cold starts and the 15-minute execution ceiling. A long-running service (ECS/EC2) fits steady, sustained, or longer-duration workloads better.

Key features

  • Lambda fits: event-driven processing, bursty/unpredictable traffic, short-lived tasks, glue code between AWS services
  • A long-running service (ECS/EC2) fits: sustained high or steady throughput, workloads over 15 minutes, specialized networking, or heavy in-memory state that benefits from staying warm
  • The 15-minute maximum timeout is a hard ceiling — workloads that can exceed it structurally do not fit Lambda
  • Cost crosses over at high, steady utilization — per-invocation billing can cost more than a continuously-running instance at that point

Command

text
Event-driven + bursty + short-lived → Lambda. Steady/sustained + long-running + specialized networking → ECS/EC2.

Lambda: event-driven, bursty, short-lived, zero idle cost. A long-running service fits steady high throughput, workloads over 15 minutes, or specialized networking needs — know the crossover before defaulting to either.

Remember

  • Code outside the handler runs once per environment during Init; only handler code runs per Invoke.
  • A version is immutable; an alias is a mutable pointer — callers target the alias, not the version, for zero-downtime rollout.
  • Reserved concurrency caps capacity; provisioned concurrency pre-warms it — they solve different problems.
  • Async invocation returning 202 means "accepted," not "succeeded" — configure a DLQ or destination to observe real outcomes.

Pro tip

  • Event source mappings (SQS, Kinesis, DynamoDB Streams) have Lambda itself poll — a different model from async invocation.
  • The 15-minute timeout ceiling is the clearest hard signal a workload does not fit Lambda at all.

Next up

  • API Gateway and API Front Doors
  • S3 — Object Storage
  • S3 Security and Data Lifecycle

Sources

  • Lambda execution environment lifecycle — docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html
  • Understanding Lambda function scaling — docs.aws.amazon.com/lambda/latest/dg/invocation-scaling.html
  • Invoking a Lambda function asynchronously — docs.aws.amazon.com/lambda/latest/dg/invocation-async.html
  • Checked against official AWS documentation 2026-08-21

Spotted a mistake on this page? Tell us.

ReadSheet