AWS Lambda
Serverless compute that runs your code in response to events — no servers to provision or manage.
Verified against AWS documentation · 2026-08-28
Key facts
- 01Event-driven: code runs only when triggered (S3 upload, API Gateway request, SQS message, schedule) and you pay only while it runs
- 02Scales automatically per-request — 1 invocation or 10,000 concurrent, no capacity planning
- 03Stateless between invocations — persist anything you need in S3, DynamoDB, etc.
- 04Limits: 15-min max timeout (hard), 128 MB–10,240 MB memory, 6 MB sync / 256 KB async payload, 512 MB /tmp (expandable to 10 GB), 1,000 default concurrency (soft)
Exam triggers
Phrases and scenarios that point here.
- "Serverless", "no infrastructure to manage", "pay only for what you use", "event-driven"
- Run code when something happens — file lands in S3, message hits a queue, API is called → Lambda
- Task exceeds 15 minutes → NOT Lambda; use ECS/Fargate, Batch, or Step Functions to break it up
- Unpredictable or spiky traffic where idle EC2 would waste money → Lambda
- Cron-style scheduled jobs without a server → EventBridge Scheduler + Lambda
Not this service
- Long-running (>15 min) or always-on workloads → ECS/Fargate or EC2
- Container orchestration with full control → ECS/EKS
- Multi-step workflow coordination with retries and branching → Step Functions (which calls Lambda)
Use cases
- 01Thumbnail factory: user uploads a photo to S3, the upload event fires a Lambda that resizes it — no server sitting idle waiting for uploads
- 02API backends via API Gateway, where each request spins up compute on demand and disappears — ideal when traffic is bursty or unpredictable
- 03Queue workers: Lambda polls SQS and processes orders/jobs in parallel, scaling with queue depth instead of a fixed worker fleet
- 04Scheduled housekeeping — nightly report generation, cleaning up expired records, rotating data — via EventBridge Scheduler instead of a cron server
- 05Real-time stream processing: transform or filter Kinesis/DynamoDB Streams records as they arrive
How it's charged
- 01Two dimensions: number of requests + compute duration in GB-seconds (memory allocated × execution time, billed per millisecond)
- 02Memory is the price-and-speed lever — CPU scales with memory, so a bigger allocation that finishes faster can cost the same or less than a starved one
- 03Arm (Graviton) is billed at a lower per-GB-second rate than x86 for the same work
- 04Always-free tier every month: 1M requests + 400,000 GB-seconds — doesn't expire after 12 months
- 05Provisioned Concurrency is billed for the time it's enabled, whether or not invocations arrive, and the free tier doesn't cover it — a classic 'why is my serverless bill not zero' surprise
- 06No charge for idle functions — code sitting deployed costs nothing until invoked
