Lambda — execution model, Snap Start, provisioned concurrency

AWS Lambda functions execute in ephemeral compute environments called execution environments, created on demand and reused across invocations to amortise initialisation costs. The execution model is deceptively simple at the surface but has profound implications for latency, cost, and architectural design. Understanding how environments are created, reused, and terminated is the prerequisite for correctly interpreting Lambda performance metrics and selecting the right concurrency model for each workload.

Every invocation follows one of two paths. A cold start occurs when no warm execution environment is available: Lambda provisions a microVM, downloads the function package, initialises the runtime, and runs the init code before executing the handler. A warm invocation reuses an existing environment, executing only the handler and bypassing all initialisation. Cold start duration varies from under 150 milliseconds for Node.js to over one second for Java functions with heavy classloading.

Provisioned Concurrency and SnapStart address the cold start problem at different layers and different cost points. Provisioned Concurrency pre-warms a configurable number of execution environments so they are always ready without cold starts. SnapStart, introduced for Java runtimes in 2022, takes a snapshot of the fully-initialised environment and restores from it on subsequent cold starts, reducing Java cold start times by up to 90%. Choosing between them depends on the runtime, invocation pattern, and acceptable cost trade-offs.

Analogy🏏Cricket

🏏 Think of it like cricket: In Test cricket, the ICC publishes playing conditions — governing over rates, DRS quotas, pitch inspection protocols, and player conduct — that both captains sign before the first session, whether the match is at Lord’s, the MCG, or Eden Gardens. Just as the playing conditions give umpires a single authoritative standard so every ruling references the same document rather than personal judgement, the Well-Architected Framework gives architects a shared evaluation language so every workload is measured against the same six pillars rather than each engineer’s intuition. Just as a team posting a slow over rate incurs penalties regardless of their score, a workload with Security or Reliability gaps carries structural risk regardless of how quickly it shipped. Just as every specialist role — opener, keeper, tail — has defined performance expectations against which selectors evaluate each player, every workload component is evaluated against pillar-specific best-practice questions. This reveals why the framework must precede any advanced architectural decision: a shared, evidence-based standard transforms subjective trade-offs into structured, auditable risk assessments that hold across teams, accounts, and regions.