LearningTree · AWS · Compute

AWS Lambda —
Serverless Compute

Run code without provisioning servers. Pay only for execution time. Scale automatically from zero to thousands of concurrent requests — the core building block of serverless architecture on AWS.

⚡ Lambda in 30 Seconds

Serverless compute — upload your code, AWS runs it in response to events
No servers to manage — no patching, no scaling config, no idle costs
Pay per invocation + duration — billed in 1ms increments (minimum 1ms)
Scales automatically — from 0 to 1000+ concurrent executions instantly
Integrates with 200+ AWS services — S3, API Gateway, SQS, DynamoDB, EventBridge

Chapter One

What is Lambda

Introduction Introductory

AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers. You upload your function code, define what triggers it, and AWS handles everything else — server provisioning, patching, scaling, high availability, and monitoring. Your code runs only when triggered and you pay only for the compute time consumed.

👉 Think of Lambda as: A vending machine for code execution — insert an event, get a result. No kitchen to maintain.

Lambda was released in 2014 and fundamentally changed how applications are built on AWS. Instead of running servers 24/7 waiting for requests, you write small, focused functions that execute only when needed — transforming fixed infrastructure costs into variable costs proportional to actual usage.

Why Lambda Exists Introductory

⚠️

Traditional Server Problems

Must provision servers before traffic arrives — pay for idle capacity 24/7
Scaling requires configuration — Auto Scaling Groups, health checks, ALBs
OS patching and security updates — your responsibility, constant maintenance
Over-provisioning to handle peaks — paying for capacity used 5% of the time
Deployment complexity — rolling updates, drains, health checks

✅

Lambda Solves

Zero idle cost — code runs only in response to events, scale to zero
Automatic scaling — from 0 to 1000+ concurrent executions, no config needed
No OS management — AWS manages the execution environment entirely
Pay per millisecond — exactly proportional to actual usage
Deploy in seconds — upload code, done. No instance rollouts or drains

The Serverless Concept Introductory

"Serverless" doesn't mean no servers — it means you don't think about servers. AWS runs your code on servers they manage, but the infrastructure is completely abstracted away. You focus solely on business logic.

Aspect	EC2 (Server-based)	Lambda (Serverless)
Provisioning	You choose instance type, size, count	Automatic — AWS allocates resources per invocation
Scaling	Configure ASG, min/max, policies	Instant — each event gets its own execution
Cost model	Pay per hour/second while running	Pay per invocation + milliseconds of compute
Maintenance	Patch OS, update runtimes, manage AMIs	AWS manages everything below your code
Idle cost	Running 24/7 even with zero traffic	$0 when not executing — true scale-to-zero
Max execution	Unlimited (server stays running)	15 minutes per invocation (hard limit)
State	Local disk, memory persists between requests	Stateless — no guaranteed persistence between calls

Concept Diagram — Event-Driven Execution Introductory

Lambda Concept: Event → Function → Response

AWS Architecture Diagram — Lambda in Context Core

Typical Lambda Integration: API Gateway → Lambda → DynamoDB

Where Lambda Fits in AWS Introductory

🌐

APIs & Web

REST/HTTP APIs via API Gateway. Backend logic without servers — the most common Lambda pattern. Powers millions of production APIs.

📨

Event Processing

S3 file uploads, SQS messages, DynamoDB stream changes, IoT events. React to events in real-time without polling.

⏰

Scheduled Jobs

Cron-like execution via EventBridge rules. Reports, cleanup, data sync — without a running server waiting between runs.

🔄

Data Pipelines

Transform data between services: S3 → Lambda → Redshift. ETL, image processing, PDF generation, video transcoding triggers.

🛡️

Security & Ops

Auto-remediation: detect config drift → Lambda fixes it. Respond to CloudTrail events, GuardDuty findings, security alerts.

🔌

Glue & Integration

Connect services that don't natively talk to each other. Lambda as the universal adapter between AWS services and external APIs.

Mental Model Core

Think of Lambda like a taxi service vs owning a car:

🚗

EC2 = Owning a Car

Buy the car (provision the instance)
Pay insurance even when parked (idle cost)
You maintain it — oil changes, tires (OS patches)
Always available — just walk to the garage
You choose the size and model (instance type)
Great for: daily commute (steady workloads)

🚕

Lambda = Taking a Taxi

No car to buy — just hail when needed (event triggers)
Pay only for the ride — meter running only during execution
Driver handles maintenance (AWS manages runtime)
Slight wait for pickup (cold start — 100-500ms first time)
Limited trip length (15 min max execution)
Great for: occasional trips (bursty/event-driven workloads)

Key Takeaway

Lambda is not a replacement for EC2 — it is a different compute model. Use Lambda when workloads are event-driven, short-lived, and bursty. Use EC2 when workloads are long-running, stateful, or need full OS control.

Use Cases — When Lambda Shines Core

Use Case	Pattern	Why Lambda Wins
REST API backend	API Gateway → Lambda → DynamoDB	Zero idle cost, auto-scales to any traffic level
File processing	S3 upload → Lambda → transform → S3	Process only when files arrive, pay per file
Queue consumer	SQS → Lambda batch processing	Scales consumers with queue depth automatically
Real-time streams	Kinesis/DynamoDB Streams → Lambda	Process each record as it arrives
Cron jobs	EventBridge schedule → Lambda	No server running 24/7 for a 5-second daily job
Webhooks	API Gateway → Lambda → forward/process	Handle sporadic external callbacks at any volume
ChatOps / Bots	API Gateway → Lambda → Slack/Teams	Idle 99% of the time — perfect for pay-per-use

When NOT to Use Lambda Core

🚫

Lambda is Wrong For

Long-running processes — anything >15 minutes (use ECS/Fargate)
Stateful workloads — in-memory caches, persistent connections (use EC2)
High-performance computing — GPU, custom hardware (use EC2 P/G instances)
Constant, steady-state load — 100% CPU 24/7 is cheaper on EC2
Large applications — 250MB deploy limit, 10GB memory max

📏

Lambda Constraints

Timeout: max 15 minutes per invocation
Memory: 128MB to 10,240MB (CPU scales proportionally)
Package size: 50MB zipped, 250MB unzipped (layers help)
Concurrency: 1000 per region default (can increase)
Ephemeral storage: 512MB to 10GB /tmp
No persistent state between invocations (use DynamoDB/S3)

📋 Chapter 1 — Summary

Lambda is serverless compute — run code without managing servers.
Event-driven: code executes only in response to triggers (API call, file upload, message, schedule).
Pay per invocation + duration — true scale-to-zero, $0 when idle.
Automatic scaling — from 0 to 1000+ concurrent without configuration.
Constraints: 15-min timeout, 10GB memory max, stateless, 250MB package size.
Best for: APIs, event processing, scheduled jobs, glue between services.
Not for: long-running processes, stateful workloads, steady-state high CPU.
Mental model: Lambda = taxi (pay per ride), EC2 = owning a car (pay while parked).

Chapter Two

Core Concepts

The Anatomy of a Lambda Function Core

A Lambda function is more than just code — it's a configuration bundle that tells AWS what to run, how to run it, and what permissions it has. Understanding these components is essential before writing your first function.

Lambda Function Anatomy

Handler — The Entry Point Core

The handler is the method Lambda calls when your function is invoked. It receives two arguments: the event (input data from the trigger) and context (metadata about the invocation — remaining time, request ID, log group).

Runtime	Handler Format	Example
Node.js	file.exportedFunction	`index.handler`
Python	file.function_name	`lambda_function.lambda_handler`
Java	package.Class::method	`com.example.Handler::handleRequest`
Go	Binary name	`main` (compiled binary)
.NET	Assembly::Type::Method	`MyApp::MyApp.Function::Handler`

👉 The event object is your input. Its structure depends entirely on the trigger — an API Gateway event looks nothing like an S3 event. Always validate the event shape in your handler.

Runtime — Language Environment Core

Lambda supports multiple managed runtimes. AWS maintains and patches these — you don't install anything. Choose based on your team's skills and performance requirements.

Runtime	Cold Start	Best For	Notes
Node.js 20	~100-200ms	APIs, lightweight processing	Most popular Lambda runtime. Fast cold starts.
Python 3.12	~150-250ms	Data processing, ML inference, scripting	Excellent library ecosystem (boto3, pandas).
Java 21	~800-3000ms	Enterprise apps, heavy computation	Slow cold start. Use SnapStart to reduce ~90%.
Go	~50-80ms	High-performance, low-latency	Fastest cold start. Compiled binary, no runtime overhead.
.NET 8	~300-600ms	Enterprise .NET ecosystems	AOT compilation available for faster starts.
Custom (AL2023)	Varies	Rust, C++, any language	You provide the runtime bootstrap binary.

Key Takeaway

For latency-sensitive APIs: use Node.js, Python, or Go. For enterprise workloads: use Java with SnapStart or Provisioned Concurrency to eliminate cold starts.

Memory & CPU — The Only Knob You Turn Core

Lambda doesn't let you choose CPU directly. Instead, CPU scales linearly with memory. More memory = more CPU = higher cost per millisecond. The sweet spot balances execution speed vs cost.

Memory	vCPU Equivalent	Cost/ms	Good For
128 MB	~0.08 vCPU	$0.0000000021	Simple transforms, tiny handlers
512 MB	~0.3 vCPU	$0.0000000083	API handlers, light processing
1,769 MB	1 full vCPU	$0.0000000292	Most production workloads
3,008 MB	2 vCPU	$0.0000000493	CPU-intensive tasks, image processing
10,240 MB	6 vCPU	$0.0000001667	ML inference, video processing

👉 Counter-intuitive truth: doubling memory can halve execution time for CPU-bound functions — meaning the same total cost but faster response. Always benchmark with different memory sizes.

IAM Execution Role — What Lambda Can Do Core

Every Lambda function has an execution role — an IAM role that grants permissions for what the function can access. This is the security boundary. A function with no S3 permissions cannot read S3, even if your code tries.

🔑

Execution Role Includes

Trust policy: allows Lambda service to assume this role
Permission policies: what AWS resources the function can access
CloudWatch Logs: always included (logs:CreateLogGroup, PutLogEvents)
Follows least-privilege — only grant what's needed

🛡️

Common Managed Policies

AWSLambdaBasicExecutionRole — CloudWatch Logs only
AWSLambdaVPCAccessExecutionRole — ENI management for VPC
AWSLambdaSQSQueueExecutionRole — read from SQS
AWSLambdaDynamoDBExecutionRole — read DynamoDB streams

Environment Variables Core

Environment variables inject configuration into your function without changing code. Use them for database endpoints, API keys, feature flags, and stage identifiers (dev/staging/prod). They are encrypted at rest using KMS.

Variable	Example Value	Purpose
`TABLE_NAME`	users-prod	DynamoDB table name (changes per environment)
`STAGE`	production	Control behavior per deployment stage
`LOG_LEVEL`	INFO	Adjust logging verbosity without redeploy
`API_KEY`	(encrypted)	External service credentials — use SSM/Secrets Manager instead for rotation

Layers — Shared Dependencies In-Depth

Layers let you package libraries, custom runtimes, or shared code separately from your function. This keeps deployment packages small and enables reuse across multiple functions.

✅

When to Use Layers

Large dependencies (numpy, pandas, ffmpeg)
Shared utility code across 5+ functions
Custom runtimes (Rust bootstrap, PHP)
Reducing deploy package below 50MB limit

⚠️

Layer Gotchas

Max 5 layers per function (250MB total unzipped)
Layers are immutable — publish new version for changes
Version pinning required — no "latest" auto-update
Adds complexity — weigh convenience vs dependency management

Versions & Aliases In-Depth

Lambda supports versions (immutable snapshots) and aliases (named pointers to versions). This enables safe deployments and traffic shifting without changing client configurations.

Versions & Aliases: Safe Deployment Pattern

Aliases enable canary deployments: route 10% of traffic to the new version while 90% stays on the stable version. If errors spike, roll back instantly by updating the alias pointer — no redeploy needed.

Function Configuration Reference In-Depth

Setting	Default	Range	Notes
Memory	128 MB	128 – 10,240 MB	CPU scales proportionally. 1769MB = 1 vCPU.
Timeout	3 seconds	1s – 15 min	Set just above p99 duration + buffer.
Ephemeral /tmp	512 MB	512 MB – 10 GB	Persists across warm invocations only.
Concurrency	1000/region	0 – account limit	Per-function reserved concurrency available.
Package size	—	50 MB zip / 250 MB unzipped	Use layers or container images (10GB) for more.
Env vars	—	4 KB total	Encrypted at rest with KMS. Use SSM for large configs.
Layers	0	Max 5	Total unzipped must still be ≤250MB.

📋 Chapter 2 — Summary

Handler: entry point (file.method). Receives event + context objects.
Runtime: Node.js, Python, Java, Go, .NET, or custom. Choose based on cold start tolerance.
Memory: only config knob — 128MB to 10GB. CPU scales linearly. 1769MB = 1 vCPU.
Timeout: max 15 min. Set to p99 + buffer — never use max blindly.
Execution role: IAM role defining what the function can access. Least privilege always.
Environment variables: inject config (table names, stage, keys). Encrypted at rest.
Layers: shared dependencies across functions. Max 5, versioned, immutable.
Versions & aliases: immutable snapshots + named pointers enable canary deployments and instant rollback.

Chapter Three

Execution Model

How Lambda Actually Runs Your Code Core

When Lambda receives an event, it finds (or creates) an execution environment — a lightweight container with your code, runtime, and dependencies. Understanding this lifecycle is the key to optimizing cold starts and managing state.

Invocation Types Core

Lambda supports three invocation models. The model determines who waits for the result and who handles retries.

Three Invocation Types

Type	Caller Waits?	Retry Behavior	Triggers	Error Handling
Synchronous	Yes — blocks until response	Caller must retry	API Gateway, ALB, SDK invoke	Error returned to caller directly
Asynchronous	No — 202 Accepted immediately	Lambda retries 2× (configurable)	S3, SNS, EventBridge, CloudFormation	DLQ or on-failure destination
Event Source Mapping	N/A — Lambda polls	Retries until success or expiry	SQS, Kinesis, DynamoDB Streams, Kafka	Bisect batch, maxRetries, DLQ

Cold Start vs Warm Start Core

The most important performance concept in Lambda. A cold start happens when Lambda must create a new execution environment from scratch. A warm start reuses an existing environment — dramatically faster.

Cold Start vs Warm Start Lifecycle

Aspect	Cold Start	Warm Start
When	First invocation, after idle (~5-15 min), code update, scaling up	Reuses existing container (within minutes of last invocation)
Latency added	100ms (Go) to 3000ms+ (Java unoptimized)	~1-5ms (just handler execution)
Init code runs?	Yes — code outside handler runs once	No — skips directly to handler
Connections	Must establish new DB/API connections	Reuses connections from init phase
Frequency	~1-5% of invocations under steady traffic	95-99% of invocations

👉 Init code (outside the handler) runs only on cold start. Put SDK client creation, DB connections, and config loading outside the handler — they persist across warm invocations. This is the single most impactful optimization.

Execution Lifecycle in Detail In-Depth

🧊

INIT Phase (Cold Start Only)

Download: code + layers fetched from S3
Runtime boot: Node.js/Python/Java process starts
Extension init: monitoring agents (Datadog, etc.) initialize
Function init: your code outside the handler runs
Free 10 seconds for init — not billed (timeout doesn't apply)
After init: environment is "warm" and ready

🔥

INVOKE Phase (Every Invocation)

Lambda calls your handler with (event, context)
Billed from first ms of handler execution
Must complete within configured timeout
Return value sent back to caller (sync) or logged (async)
Environment stays "warm" for ~5-15 min after completion
Next invocation reuses same environment (warm start)

Execution Environment Reuse In-Depth

Lambda reuses execution environments across multiple invocations. This is the single most important optimization concept — code outside the handler runs once and persists across warm invocations.

❌

Bad — Inside Handler

Create DB connection on every invocation
Initialize SDK client every time
Load config from SSM on every call
Result: 50-200ms wasted per invocation

✅

Good — Outside Handler (Init)

DB connection created once, reused for ~5-15 min
SDK client initialized once, available instantly
Config loaded once, cached in module scope
Result: 1-5ms per warm invocation

👉 What persists across warm invocations: global/module variables, DB connections, SDK clients, /tmp files, imported modules. What does NOT persist: handler local variables, event/context objects, anything after environment timeout (~5-15 min idle).

Concurrency Model In-Depth

Each concurrent invocation gets its own execution environment. One environment handles one request at a time (no multi-threading across requests). If 100 requests arrive simultaneously, Lambda creates 100 environments.

Concurrency Type	What It Does	Cost	When to Use
Unreserved	Shares the account's 1000 pool with all functions	Free	Default — most functions
Reserved	Guarantees N environments for this function (throttles others)	Free	Critical functions that must never be throttled
Provisioned	Pre-warms N environments — always ready, no cold starts	$$$	Latency-sensitive APIs where cold starts are unacceptable

Throttling Behavior Core

When concurrency limits are reached, Lambda throttles additional invocations. The throttling behavior depends on the invocation type:

Invocation Type	Throttle Behavior	Client Experience
Synchronous	Returns 429 TooManyRequestsException	Error returned to caller — must implement retry with backoff
Asynchronous	Event queued, retried for up to 6 hours	Caller got 202 already — unaware. Event eventually processes or goes to DLQ.
Event Source Mapping (SQS)	Messages stay in queue	Processing delayed — messages visible again after visibility timeout
Event Source Mapping (Kinesis)	Shard iterator paused	Records back up in stream — processing resumes when capacity frees

👉 Exam scenario: "Lambda returns 429 errors" → answer is always about concurrency limits. Fix: increase account limit, add reserved concurrency, or add SQS queue in front to buffer.

Error Handling & Retries In-Depth

Lambda's retry behavior is completely different per invocation type. Misconfigured retries are the #1 cause of duplicate processing and unexpected costs in serverless systems.

🔄

Sync — Caller Retries

Error returned directly to caller
Lambda does NOT retry
Caller must implement retry logic
API Gateway: returns 5xx to client
SDK: built-in retry with backoff

🔁

Async — Lambda Retries 2×

Retries automatically (0, 1, or 2 times)
Configurable: MaximumRetryAttempts (0-2)
After all retries fail → DLQ or destination
MaximumEventAge: discard old events (60s-6hr)
Risk: 3 invocations for one event

📋

ESM — Until Expiry

SQS: retries until visibility timeout, then DLQ
Kinesis: retries until record expires (24h-7d)
Can block the entire shard (poison pill problem)
Fix: BisectBatchOnError, MaximumRetryAttempts
Fix: FunctionResponseTypes for partial batch failure

Destinations vs Dead-Letter Queue (DLQ) In-Depth

Both handle failed events, but Destinations are the modern, more flexible approach — they can capture both success and failure, and support more targets.

Feature	DLQ (Legacy)	Destinations (Recommended)
Captures	Failures only	Success AND failure
Targets	SQS or SNS only	SQS, SNS, Lambda, EventBridge
Metadata	Original event only	Event + response + error + request context
Configuration	On the function itself	On the function (async config)
Invocation types	Async only	Async (+ stream ESM on-failure)

👉 Use Destinations for new designs. DLQ captures only the failed event payload. Destinations capture the full invocation record — event, response, error details, and timestamps — making debugging significantly easier.

Idempotency — Handling Duplicate Events In-Depth

Lambda functions will process the same event multiple times. This is not a bug — it's by design (retries, at-least-once delivery from SQS, duplicate S3 notifications). Your functions must be idempotent: processing the same event twice must produce the same result without side effects.

🔑

Why Duplicates Happen

Async retries: Lambda retries failed async invocations
SQS at-least-once: message can be delivered more than once
S3 event notifications: can fire twice for one upload
Network timeouts: Lambda completed but caller didn't get response
Stream replay: Kinesis/DynamoDB on error re-read from checkpoint

✅

Idempotency Strategies

Idempotency key: use event's unique ID (request_id, message_id)
DynamoDB conditional write: PutItem with condition "attribute_not_exists(pk)"
Powertools Idempotency: AWS Lambda Powertools library handles it automatically
Check-before-write: verify if already processed before acting
Design operations to be naturally idempotent: SET (idempotent) vs INCREMENT (not)

Key Takeaway

If your function charges a credit card, sends an email, or increments a counter — it MUST be idempotent. Processing the same payment event twice must not charge twice. This is not optional for production systems.

Common Mistakes Core

Mistake	Impact	Fix
Creating DB connections inside handler	50-200ms added per invocation	Initialize outside handler — reuse across warm invocations
Ignoring retries → duplicate processing	Double charges, duplicate emails	Implement idempotency with unique keys
Using VPC unnecessarily	NAT Gateway cost + networking complexity	Only VPC when accessing private resources (RDS, Redis)
Setting memory too low	Slow execution (CPU starved) + higher total cost	Use Power Tuning tool to find optimal memory
Max timeout on API functions	Hung functions billed for 15 min	Set timeout to p99 + 20% buffer
No DLQ/destination configured	Failed events silently lost forever	Always configure on-failure destination

📋 Chapter 3 — Summary

Synchronous: caller waits (API Gateway, ALB). Caller retries on error.
Asynchronous: 202 Accepted immediately (S3, SNS). Lambda retries 2×. Use DLQ/Destinations.
Event Source Mapping: Lambda polls (SQS, Kinesis, DynamoDB Streams). Batch processing.
Cold start: new environment creation. 100ms (Go) to 3000ms (Java). ~1-5% of invocations.
Warm start: reuses existing container. ~1-5ms overhead. 95-99% of invocations.
Environment reuse: init code outside handler persists. DB connections, SDK clients reused.
Throttling: sync → 429 error, async → queued for retry, ESM → messages stay in queue.
Idempotency: functions WILL receive duplicates. Use idempotency keys + conditional writes.
Destinations > DLQ: capture success + failure, more targets, richer metadata.
Concurrency: 1 request per environment. Unreserved (shared), Reserved (guaranteed), Provisioned (pre-warmed).

🎓 Exam Tips — Chapter 3

Lambda = stateless · Max execution = 15 minutes · Async retries = 2 times · Throttled sync = 429 error · DLQ only captures failures, Destinations capture both · Idempotency is YOUR responsibility · VPC adds cold start latency · Reserved concurrency = free guarantee

Chapter Four

Event Sources & Integrations

Lambda's Superpower: 200+ Integrations Core

Lambda's value isn't just serverless compute — it's the universal glue between AWS services. Every major AWS service can trigger Lambda, and Lambda can call any AWS service via the SDK. This makes it the central nervous system of event-driven architectures.

API Gateway — REST & HTTP APIs Core

The most common Lambda trigger. API Gateway handles HTTPS, authentication, throttling, and CORS — Lambda handles business logic. Together they form a serverless API backend.

API Gateway + Lambda: Serverless REST API

⚡

HTTP API (Recommended)

$1.00/million requests (70% cheaper)
Faster — lower latency, simpler proxy
JWT authorizer built in (Cognito, Auth0)
Best for: most new APIs, microservices

🔧

REST API (Full-featured)

$3.50/million requests
Request/response transformation
WAF integration, API keys, usage plans
Best for: complex APIs needing throttling per client

S3 Events — File Processing Core

S3 triggers Lambda when objects are created, modified, or deleted. This powers image processing, video transcoding, log analysis, and ETL pipelines — all without polling.

S3 Event → Lambda: Image Processing Pipeline

SQS — Queue Processing Core

Lambda polls SQS queues and processes messages in batches. This decouples producers from consumers and enables reliable, scalable background processing with automatic retry and dead-letter handling.

📬

Standard Queue

Nearly unlimited throughput
At-least-once delivery (possible duplicates)
Batch size: 1-10 messages per invocation
Lambda scales up to 1000 concurrent batches
Best for: high-volume background jobs

📋

FIFO Queue

Exactly-once processing guaranteed
Strict ordering within message group
300 messages/sec (or 3000 with batching)
Lambda: 1 concurrent invocation per message group
Best for: orders, financial transactions

SNS — Fan-Out Pattern Core

SNS invokes Lambda asynchronously. One SNS topic can fan out to multiple Lambda functions (plus SQS, email, HTTP). This enables event broadcasting — one publish, many consumers.

DynamoDB Streams — Change Data Capture Core

When items change in DynamoDB, streams capture the before/after images. Lambda processes these changes in order — enabling real-time replication, notifications, materialized views, and audit logs.

EventBridge — Scheduled & Event-Driven Core

EventBridge Rules trigger Lambda on schedules (cron/rate) or event patterns from AWS services and custom applications. It's the backbone of event-driven architectures on AWS.

Event Source Summary Core

Source	Invocation Type	Batch?	Retry	Common Pattern
API Gateway	Synchronous	No	Caller retries	REST/HTTP APIs
S3	Asynchronous	No	2× then DLQ	File processing, ETL
SNS	Asynchronous	No	2× then DLQ	Fan-out, notifications
SQS	Event Source Mapping	Yes (1-10)	Until visibility timeout	Queue consumers, background jobs
Kinesis	Event Source Mapping	Yes (1-10K)	Until record expires (24h-7d)	Real-time stream processing
DynamoDB Streams	Event Source Mapping	Yes (1-10K)	Until record expires (24h)	CDC, replication, triggers
EventBridge	Asynchronous	No	Configurable	Cron jobs, event routing
ALB	Synchronous	No	Caller retries	Multi-target groups, weighted routing
CloudFront (Lambda@Edge)	Synchronous	No	—	Request/response manipulation at edge

Architecture Diagram — Multi-Source Event Processing In-Depth

Lambda as Central Event Processor (Multi-Source)

Key Takeaway

Lambda is not a standalone service — its power comes from integrations. Design around events flowing between services, with Lambda as the processing logic between them.

📋 Chapter 4 — Summary

API Gateway: most common trigger. HTTP API ($1/M) for most; REST API ($3.5/M) for advanced features.
S3: async trigger on PutObject. Powers file processing pipelines. Use DLQ for failures.
SQS: event source mapping. Batch processing (1-10 msgs). Auto-scales with queue depth.
SNS: async fan-out. One publish → multiple Lambda functions in parallel.
DynamoDB Streams: ordered change data capture. Real-time replication and triggers.
EventBridge: cron schedules + event pattern matching from 90+ AWS services.
Design principle: Lambda is the glue — connect services via events, not direct calls.

Chapter Five

Lambda + VPC Networking

Why Put Lambda in a VPC? Core

By default, Lambda runs in an AWS-managed VPC with internet access but no access to your private resources (RDS, ElastiCache, private EC2 instances). If your function needs to connect to a database in a private subnet, you must attach Lambda to your VPC.

✅

Put Lambda in VPC When

Connecting to RDS/Aurora in private subnets
Accessing ElastiCache (Redis/Memcached)
Reaching private EC2 instances or ECS services
Connecting to resources via VPC peering or Transit Gateway
Security requirements mandate private-only network access

⚠️

Do NOT Put Lambda in VPC When

Only calling public AWS APIs (S3, DynamoDB, SQS)
Only calling external HTTP APIs
No private resource access needed
Unnecessary VPC adds cold start latency + NAT cost
Most Lambda functions do NOT need VPC

👉 Golden rule: don't put Lambda in a VPC unless you must access private resources. VPC adds ENI creation overhead, NAT Gateway costs ($0.045/hr + data), and networking complexity. DynamoDB, S3, SQS, and SNS are all reachable without VPC.

How Lambda VPC Networking Works Core

When you attach Lambda to a VPC, AWS creates Elastic Network Interfaces (ENIs) in your specified subnets. Lambda execution environments use these ENIs to communicate with resources in the VPC. Since 2019, AWS uses Hyperplane ENIs — shared across functions in the same security group + subnet, dramatically reducing cold start impact.

Lambda in VPC: ENI Architecture

VPC Configuration Checklist Core

Setting	Recommendation	Why
Subnets	Private subnets in 2+ AZs	HA — Lambda uses ENIs across specified subnets. Never use public subnets.
Security Group	Dedicated sg-lambda	Outbound: allow 5432 (Postgres), 6379 (Redis), 443 (HTTPS). Inbound: none.
Internet access	NAT Gateway in public subnet	Lambda in private subnet has no internet without NAT. Required for external APIs.
AWS services	VPC Endpoints for S3, DynamoDB	Gateway endpoints are free — avoid NAT data charges for S3/DynamoDB.
IAM role	Add AWSLambdaVPCAccessExecutionRole	Grants ec2:CreateNetworkInterface, DescribeNetworkInterfaces, DeleteNetworkInterface.
IP addresses	Ensure subnet has enough IPs	Hyperplane ENIs share IPs, but 1 ENI per unique (security group + subnet) pair.

The NAT Gateway Problem In-Depth

Lambda in a VPC with internet access requires a NAT Gateway — and NAT Gateways are expensive. This is the biggest hidden cost of VPC-attached Lambda.

💰

NAT Gateway Cost

$0.045/hour = ~$32/month per NAT (always-on)
$0.045/GB processed data
2 AZs = 2 NATs = ~$65/month before any data
Lambda calling external APIs? Every byte goes through NAT
This can exceed Lambda compute costs for low-traffic functions

💡

Cost Reduction Strategies

VPC Endpoints: S3 + DynamoDB Gateway endpoints = $0
Interface Endpoints: for SQS, SNS, Secrets Manager ($7.20/mo each)
Separate functions: only VPC-attach functions that need private access
Non-VPC function → calls public APIs directly (no NAT)
VPC function → calls RDS only (no external internet needed)

Security Groups for Lambda Core

Lambda's security group controls outbound traffic from the function. The resources it connects to must allow inbound from the Lambda security group.

Rule	Lambda SG (sg-lambda)	RDS SG (sg-rds)	ElastiCache SG (sg-redis)
Inbound	None needed	5432 from sg-lambda	6379 from sg-lambda
Outbound	5432 to sg-rds 6379 to sg-redis 443 to 0.0.0.0/0 (HTTPS)	Default (allow all)	Default (allow all)

👉 Reference security groups, not IP addresses. Lambda's ENI IPs change — never hardcode them. Allow sg-lambda in your RDS/Redis security group inbound rules. This is the VPC-native, maintainable approach.

RDS Proxy — Connection Pooling In-Depth

Lambda creates a new database connection per execution environment. At scale (100+ concurrent), this can overwhelm RDS (PostgreSQL default: 100 connections). RDS Proxy solves this by pooling connections.

💥

Without RDS Proxy

100 concurrent Lambda = 100 DB connections
Spike to 500 = "too many connections" errors
Connection setup: 30-50ms per cold start (TCP + TLS + auth)
Connections linger in warm containers → wasted DB slots

✅

With RDS Proxy

Proxy pools connections — 500 Lambda share 50 DB connections
Connection reuse via multiplexing
IAM auth (no password in code/env vars)
Automatic failover — follows RDS Multi-AZ switchover
Cost: ~$21/month per proxy instance (based on ACU)

📋 Chapter 5 — Summary

VPC only when needed: RDS, ElastiCache, private EC2. Most functions don't need VPC.
Hyperplane ENIs: shared ENIs per (security group + subnet). Minimal cold start impact since 2019.
Private subnets only: never attach Lambda to public subnets (no public IP assigned to ENIs).
NAT Gateway required for internet: $32/month/NAT + data charges. Biggest hidden VPC cost.
VPC Endpoints: S3 and DynamoDB Gateway endpoints are free. Use them to skip NAT.
Security groups: reference sg-lambda in RDS/Redis inbound rules. Never hardcode IPs.
RDS Proxy: essential at scale — pools connections, prevents "too many connections" errors.

🎓 Exam Tips — Chapter 5

Lambda in VPC = needs ENI permissions (ec2:CreateNetworkInterface) · Private subnets only — public gives NO internet · NAT Gateway needed for internet access from VPC · VPC Endpoints for S3/DynamoDB avoid NAT · Lambda cannot have a public IP · Pre-2019 VPC = slow cold starts (fixed with Hyperplane ENIs)

Chapter Six

Performance & Optimization

The Performance Levers Core

Lambda performance optimization comes down to three things: reducing cold starts, right-sizing memory, and minimizing external call latency. Most performance issues are not Lambda's fault — they're network calls to databases and APIs.

Memory Tuning — The #1 Optimization Core

Memory is the only resource knob. CPU scales with memory — but the relationship is non-linear for your workload. A CPU-bound function at 128MB may take 2000ms; at 1024MB it takes 250ms — 8× faster for 8× memory but same total cost.

Memory vs Duration vs Cost: Find the Sweet Spot

👉 Use AWS Lambda Power Tuning (open-source tool by Alex Casalboni). It runs your function at every memory size and gives you the optimal cost/performance point. Don't guess — measure.

Cold Start Reduction Core

Technique	Impact	Cost	Complexity
Init code outside handler	Reuse SDK clients, DB connections across warm invocations	Free	Low — restructure code
Smaller package	Reduce download time. Tree-shake, exclude dev deps	Free	Low — build optimization
Choose fast runtime	Go ~50ms, Node ~150ms, Java ~1-3s cold start	Free	Medium — language choice
Provisioned Concurrency	Eliminates cold starts entirely — pre-warmed	$$$ — pay for idle warm environments	Low — config only
SnapStart (Java only)	Snapshots init state, restores in ~200ms vs 3s	Free	Low — enable in config
ARM64 (Graviton2)	~10-15% faster, 20% cheaper per ms	Savings	Low — change architecture flag

Provisioned Concurrency In-Depth

Provisioned Concurrency keeps N execution environments pre-initialized and ready. No cold starts, guaranteed sub-100ms startup. Use it for latency-sensitive APIs where even occasional 1-second cold starts are unacceptable.

⚡

When to Use Provisioned

APIs with strict SLA (<200ms p99)
Java/C# functions with heavy cold starts
Predictable traffic patterns (business hours)
Use Application Auto Scaling to schedule PC
Combine with alias for traffic shifting

💰

Cost Calculation

Provisioned: $0.015/GB-hour (keep-warm cost)
10 instances × 512MB × 24h = ~$1.80/day
Compare vs: EC2 t3.micro = ~$0.25/day
Only worth it if traffic justifies serverless benefits
Schedule: provision 50 at 8am, scale to 5 at 10pm

ARM64 / Graviton2 Core

Lambda supports ARM64 (Graviton2) processors — 20% cheaper per GB-second and often 10-15% faster than x86. For most workloads, switching is a one-line config change with immediate savings.

Aspect	x86_64	arm64 (Graviton2)
Price per GB-sec	$0.0000166667	$0.0000133334 (20% less)
Performance	Baseline	~10-34% faster (workload dependent)
Compatibility	All runtimes, all native binaries	All managed runtimes. Native binaries must be ARM-compiled.
Migration effort	—	Pure Python/Node/Java: zero effort. C extensions: recompile.

Timeout Tuning Core

Set timeout to p99 duration + 20% buffer, not the 15-minute max. Too-long timeouts waste money on hung invocations and delay error detection. Too-short timeouts cause false failures on legitimate slow paths.

🎯

API Handlers

10-30 seconds. API Gateway times out at 29s anyway. Clients expect fast responses.

📦

Queue Processors

30-120 seconds. Match SQS visibility timeout (6× Lambda timeout recommended).

🔄

Data Processing

5-15 minutes. Large file transforms. Use Step Functions for anything longer.

Concurrency & Throttling In-Depth

Type	Default	Purpose	Behavior When Exceeded
Account limit	1000/region	Protect account from runaway scaling	Throttled (429) or queued depending on invocation type
Reserved concurrency	Not set	Guarantee capacity for critical functions	Other functions share remaining pool
Provisioned concurrency	Not set	Eliminate cold starts for N instances	Overflow uses on-demand (with cold starts)
Burst concurrency	500-3000/region	Allow rapid scale-up	After burst, scales +500/minute

Cost Optimization Core

💡

Reduce Cost

ARM64: instant 20% savings, one config change
Power tuning: find optimal memory — avoid over-provisioning
Timeout: reduce from 15min default to actual need
VPC only when needed: avoid NAT Gateway costs
VPC Endpoints: S3/DynamoDB gateway = free vs NAT data charges

📊

Cost Breakeven: Lambda vs EC2

<1M invocations/month: Lambda almost always cheaper
1-10M/month: depends on duration and memory
>10M/month at steady rate: EC2/Fargate likely cheaper
Bursty traffic: Lambda wins even at high volume
Rule of thumb: if Lambda >14 hours/day utilized → consider EC2

📋 Chapter 6 — Summary

Memory is the only knob: CPU scales linearly. Use Lambda Power Tuning to find the cost/speed sweet spot.
Cold start reduction: init outside handler, smaller packages, fast runtimes, SnapStart (Java), Provisioned Concurrency.
ARM64/Graviton2: 20% cheaper, 10-15% faster. Switch for pure-language runtimes with zero effort.
Provisioned Concurrency: eliminates cold starts. Schedule with Auto Scaling for business-hours traffic.
Timeout: set to p99 + 20% buffer. Never use 15-min default on API handlers.
Concurrency: 1000/region default. Reserve for critical functions. Burst allows 500-3000 rapid scale.
Cost breakeven: Lambda wins for bursty/low-volume. EC2/Fargate wins for steady >14h/day utilization.

🎓 Exam Tips — Chapter 6

Memory ↑ = CPU ↑ (proportional) · 1769MB = 1 vCPU · Provisioned Concurrency = no cold starts (costs $$) · SnapStart = Java only, free · ARM64 = 20% cheaper, one config change · Burst limit = 500-3000 depending on region · Reserved concurrency of 0 = function disabled (throttles 100%)

Chapter Seven

Architecture Patterns

Production Patterns with Lambda In-Depth

Lambda shines in specific architectural patterns. These are battle-tested approaches used at scale by companies from startups to enterprises. Each pattern solves a different problem — choose based on your workload characteristics.

Pattern 1 — Serverless REST API Core

The most common Lambda pattern. API Gateway handles HTTP, auth, and throttling. Lambda handles business logic. DynamoDB handles state. Zero servers, zero idle cost, infinite scale.

Pattern 1: Serverless REST API (Production Stack)

Pattern 2 — Event-Driven Pipeline Core

Files arrive → Lambda processes → results go elsewhere. Each step is decoupled, independently scalable, and fault-isolated. Failed items go to dead-letter queues without blocking the pipeline.

Pattern 2: Event-Driven File Processing Pipeline

Pattern 3 — Queue-Based Load Leveling Core

SQS absorbs traffic spikes. Lambda processes at a controlled rate. This protects downstream services (databases, APIs) from being overwhelmed during bursts while ensuring every message is eventually processed.

📬

How It Works

Producers write to SQS at any rate (uncapped)
SQS buffers messages (up to 14 days retention)
Lambda polls and processes in batches (1-10)
Controlled by: batch size, concurrency limit, batch window
Failed messages → retry → DLQ after max attempts

🛡️

Protects Downstream

Set reserved concurrency = 10 → max 10 DB connections
Burst of 10,000 messages? SQS queues them safely
Lambda processes at steady rate (no DB overload)
Visibility timeout = 6× Lambda timeout (prevent duplicates)
Use FIFO queue when message order matters

Pattern 4 — Serverless Microservices In-Depth

Each microservice is a Lambda function (or group) with its own API, data store, and deployment lifecycle. Services communicate asynchronously via SNS/SQS/EventBridge — not direct invocation.

Pattern 4: Serverless Microservices via EventBridge

Pattern 5 — Scheduled Jobs (Cron) Core

Replace cron servers and scheduled EC2 instances with EventBridge rules triggering Lambda. Zero idle cost between executions — pay only for the seconds your job actually runs.

📊

Daily Reports

EventBridge: rate(1 day)
Query DynamoDB/RDS
Generate PDF → S3
Send via SES

🧹

Cleanup Jobs

EventBridge: rate(1 hour)
Delete expired sessions
Purge old temp files
Rotate logs

🔄

Data Sync

EventBridge: rate(5 minutes)
Poll external API
Update DynamoDB cache
Detect changes → notify

Pattern 6 — Step Functions Orchestration In-Depth

For complex workflows with branching logic, retries, parallel steps, and human approval — use Step Functions to orchestrate multiple Lambda functions. Each function stays simple; the workflow defines the complexity.

🔀

When to Use Step Functions

Multi-step workflows with branching/parallel
Long-running processes (>15 minutes total)
Human approval steps (wait for callback)
Complex error handling with retry/catch per step
Audit trail: visual execution history

📋

Real-World Examples

Order fulfillment (validate → pay → ship → notify)
User onboarding (create → verify → configure → welcome)
ML pipeline (fetch → preprocess → train → evaluate → deploy)
Document processing (extract → validate → sign → store)

Anti-Patterns to Avoid In-Depth

🚫

Lambda Anti-Patterns

Monolith Lambda: 250MB function doing everything → split into focused handlers
Lambda calling Lambda (sync): doubled latency + cost. Use SQS/SNS or Step Functions.
Long-running loops: processing 10,000 items sequentially → use SQS batch + fan-out
Using Lambda as a cron for heavy ETL: 15-min limit. Use Fargate/Glue instead.
VPC for DynamoDB/S3 access: no VPC needed for these. Adding VPC = cost + complexity for nothing.

✅

Best Practices

Single responsibility: one function, one purpose, one trigger
Async by default: use events/queues, not synchronous chains
Idempotent handlers: same event processed twice = same result (retries are real)
Structured logging: JSON logs with request_id, correlation_id for tracing
Infrastructure as Code: SAM, CDK, or Terraform. Never ClickOps Lambda.

Pattern Selection Guide Core

Workload	Pattern	Key Services
CRUD API	Serverless REST API	API Gateway + Lambda + DynamoDB
File processing	Event-driven pipeline	S3 → Lambda → SQS → Lambda → S3
Background jobs	Queue-based load leveling	SQS → Lambda (reserved concurrency)
Microservices	Event mesh	EventBridge + Lambda per domain
Periodic tasks	Scheduled execution	EventBridge rule → Lambda
Multi-step workflow	Orchestration	Step Functions + Lambda functions
Real-time streams	Stream processing	Kinesis/DynamoDB Streams → Lambda
Fan-out notifications	Pub/Sub	SNS → multiple Lambda subscribers

📋 Chapter 7 — Summary

REST API: API Gateway + Lambda + DynamoDB. Zero idle cost, ~$5/month for 1M requests.
Event pipeline: S3 → Lambda → SQS → Lambda → output. Steps decoupled, failures isolated.
Queue leveling: SQS buffers bursts, Lambda processes at controlled rate. Protects downstream.
Microservices: EventBridge routes events between independent Lambda-based services.
Cron jobs: EventBridge schedule → Lambda. Replace EC2 cron servers — $0 idle cost.
Step Functions: orchestrate multi-step workflows with branching, parallel, and approval.
Anti-patterns: avoid monolith Lambda, sync chains, VPC for public services, 15-min ETL.
Best practices: single-responsibility, async-first, idempotent, structured logs, IaC always.

🎓 Exam Tips — Chapter 7

Lambda calling Lambda synchronously = anti-pattern (use SQS/Step Functions) · EventBridge for microservice decoupling · Step Functions for workflows >15 min · SQS visibility timeout must be ≥ 6× Lambda timeout · Idempotent functions = mandatory for serverless

Lambda Quick Reference Core

Feature	Value
Compute Model	Serverless (event-driven)
Scaling	Automatic (0 → 1000+ concurrent)
Max Timeout	15 minutes
Max Memory	10,240 MB (6 vCPU equivalent)
State	Stateless (use DynamoDB/S3 for state)
Package Size	50 MB zipped / 250 MB unzipped (10 GB container image)
Concurrency Limit	1000/region (soft limit, can increase)
Billing	Per invocation ($0.20/1M) + per GB-second ($0.0000166667)
Billing Granularity	1ms increments (minimum 1ms)
Supported Runtimes	Node.js, Python, Java, Go, .NET, Ruby, Custom (AL2023)
VPC Support	Optional — via Hyperplane ENIs in private subnets
Ephemeral Storage	512 MB – 10 GB (/tmp)
Environment Variables	4 KB total, encrypted at rest (KMS)
Layers	Max 5 per function, 250 MB total unzipped
Async Retries	0, 1, or 2 (configurable)
ARM64 Savings	20% cheaper per GB-second