Lambda — Concept
What it is
AWS Lambda = serverless compute. You upload code (ZIP / container image) and Lambda runs it in isolated execution environments in response to events, billing by GB-seconds of memory × duration.
Why it exists
No servers, no patching, auto-scale to thousands of concurrent invocations in seconds, pay only when running. Perfect glue for event-driven and serverless architectures.
How it works
- Event source triggers Lambda: API Gateway, S3, SNS, SQS, DynamoDB Streams, Kinesis, EventBridge, ALB, CloudFront (Lambda@Edge), Step Functions, IoT, Cognito, etc.
- Lambda creates execution environments (micro-VMs / Firecracker) on demand.
- After a cold start, the env stays warm for reuse (~minutes).
Limits (memorize)
| Limit | Value |
|---|---|
| Memory | 128 MB – 10,240 MB (CPU scales with memory) |
Ephemeral storage /tmp | 512 MB – 10,240 MB |
| Max execution time | 15 minutes |
| Package size | 50 MB zipped, 250 MB unzipped (or 10 GB container image) |
| Layers | up to 5 per function, 250 MB unzipped combined |
| Default concurrency / region | 1,000 (soft, request increase) |
| Env vars total | 4 KB |
| Invocation payload | 6 MB sync, 256 KB async |
Invocation models
- Synchronous: API Gateway, ALB, SDK invoke — caller waits.
- Asynchronous: S3, SNS, EventBridge — Lambda retries on failure (up to 2 retries by default), can send failures to DLQ or on-failure destinations.
- Stream-based: Kinesis, DynamoDB Streams, MSK — Lambda polls; batch size; retries until expiration.
- Queue-based poll: SQS — Lambda polls; visibility timeout matters; batch up to 10,000 messages (SQS standard) / 10 (FIFO).
Concurrency
- Reserved concurrency = guarantee up to N, also a hard cap on that function.
- Provisioned concurrency = pre-warmed envs, no cold start (extra cost).
- Concurrency burst varies per region (e.g. 500–3,000 / minute).
Networking
- Default: runs in AWS-managed VPC (with internet access).
- Configure to run in your VPC (subnet + SG) when accessing private resources (RDS, ElastiCache, internal ALB).
- VPC Lambda uses Hyperplane ENIs (shared per security-group/subnet) — fast cold starts now.
Layers and extensions
- Layers = shared code/dependencies across functions.
- Extensions = sidecar processes (telemetry, secrets) attached to the runtime.
Performance tips (exam-relevant)
- Cold start ↑ if VPC + large deps + Java/.NET. Mitigate with Provisioned Concurrency, smaller deps, language choice (Node / Python / Go faster cold start).
- Pick memory deliberately — CPU scales linearly with memory; sometimes more memory = faster + cheaper.
- Use SnapStart (Java) to reduce cold starts.
Use cases
- API backends (with API Gateway / ALB).
- Event processing (S3 / SNS / SQS / EventBridge / DynamoDB Streams).
- ETL / data transformation.
- Scheduled jobs (cron via EventBridge).
- Edge logic (Lambda@Edge / CloudFront Functions for simpler cases).
When to use vs alternatives
| Use ... | Instead of ... | When ... |
|---|---|---|
| Lambda | EC2 / ECS | Event-driven, < 15 min, stateless |
| Fargate | Lambda | Long-running container, custom runtime, > 15 min |
| Step Functions | Many Lambdas chained | Orchestration with retries / state |
| EC2 | Lambda | Long-running daemons, non-standard workloads |
| Lambda@Edge | Lambda | Logic at CloudFront edge (4 trigger points) |
Common exam scenarios
- "Process uploaded images to S3" → S3 PUT event → Lambda → store thumbnails.
- "Run a job for 8 hours" → NOT Lambda (15-min limit); use ECS/Fargate or Batch.
- "Lambda hits the DB connection limit" → RDS Proxy.
- "Cold starts hurt API latency" → Provisioned Concurrency.
- "Async invocation failed — capture failures" → DLQ or EventBridge destination on failure.
- "Run Lambda in VPC to access RDS" → set subnets + SG; outbound internet needs NAT.
- "Schedule a function every 5 min" → EventBridge Scheduler or rule.
Exam tip
- 15-minute hard limit and 6 MB sync payload are the most-tested numbers.
- Sync → ALB / API GW, Async → S3 / SNS / EventBridge, Stream → Kinesis / DDB Streams, Poll → SQS.