The execution model and real limits

The execution model, briefly

A Lambda function is packaged code plus configuration (runtime, memory, timeout, environment variables, IAM role). AWS runs it inside a managed, sandboxed execution environment - you never provision or patch the underlying host. Two states matter for how it behaves:

• Cold start: no existing execution environment for this function version, so AWS provisions one from scratch (download code, start the runtime, run any top-level initialization in your code) before your handler runs.
• Warm start: an execution environment from a previous invocation is reused - your handler runs immediately, skipping initialization.

Lesson 3 goes deep on why this distinction matters for latency-sensitive workloads. For now, the key model to hold onto: you write a handler function; AWS decides when and how many execution environments exist to run it, scaling them up and down based on concurrent invocations.

The quotas that actually shape design decisions

Verified against AWS’s Lambda quotas documentation (docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html):

Quota	Value	Why it matters
Max execution timeout	900 seconds (15 min)	A task that can run longer needs Step Functions or a different service - not “just increase the timeout”
Memory	128 MB - 10,240 MB, 1 MB increments	CPU scales with memory - a memory bump can also be a CPU/performance lever
/tmp ephemeral storage	512 MB default, up to 10,240 MB, 1 MB increments	Relevant for anything that downloads, unpacks, or buffers files mid-execution
Deployment package (zipped)	50 MB via API/SDK, 50 MB via console	Push past this with container images or by uploading via S3 first
Deployment package (unzipped, incl. layers)	250 MB	The real ceiling for how much code + dependencies you can ship without a container image
Synchronous invoke payload	6 MB request and response	Matters for API Gateway-fronted functions returning large bodies
Synchronous invoke, streamed response	200 MB	Response streaming raises the ceiling substantially for large payloads
Asynchronous invoke payload	1 MB	Much tighter than sync - relevant for event-driven (S3, SNS, EventBridge-triggered) functions

What this rules in and out

• Batch/ETL jobs longer than 15 minutes: not a single Lambda invocation. Break the work into chunks orchestrated by Step Functions, or move to a container/batch service.
• A function that unpacks a large archive: check it fits in /tmp at the configured ephemeral storage size (default 512 MB is easy to exceed with, say, an ML model file).
• A large ML dependency (numpy, pandas, a model file): the 250 MB unzipped limit is the real constraint - lesson 2 covers packaging strategies, including when a container image is the better fit than a zip deployment.
• A CPU-heavy function that’s slow: before assuming you need to rewrite the algorithm, try raising memory - the proportional CPU increase is often the cheapest fix available.