Lambda & Serverless Computing

Every service so far — EC2 (Chapter 3), RDS (Chapter 6) — runs on something you provision and keep running. Lambda, launched 13 November 2014, is genuinely different: real serverless compute, where you supply only code, and AWS provisions, runs, scales, and tears down the actual execution environment automatically, entirely behind the scenes.

Function as a Service

Lambda is real, event-driven "Function as a Service" (FaaS): you write a function, AWS runs it in response to a real trigger, and you're never responsible for an underlying server at all — no OS patching (Chapter 2's own shared-responsibility line shifts even further toward AWS here than it did for RDS), no idle capacity to pay for while nothing's happening.

Real Triggers & Event Sources

A Lambda function does nothing on its own — it runs only in response to a real, configured event source:

• S3 events — a function fires automatically when an object is uploaded to a bucket (Chapter 4), e.g. resizing an image the moment it lands.
• API Gateway — a function fires in response to a real, incoming HTTP request, turning it into a genuine REST/HTTP API endpoint with no server behind it.
• DynamoDB Streams — a function fires when items change in a DynamoDB table (Chapter 6).
• EventBridge (scheduled events) — a function fires on a real, defined schedule (cron-style), a serverless alternative to a scheduled task on a persistent server.

Building a Real Serverless API

API Gateway plus Lambda is a real, common pattern for a fully serverless backend: API Gateway receives an HTTP request, invokes the corresponding Lambda function with that request's own data, and returns the function's response back to the caller — with no EC2 instance, load balancer, or persistent process running between requests at all.

The Real Pricing Model

Lambda charges for exactly two real things: the number of requests, and the duration a function actually runs, measured in GB-seconds (memory allocated × execution time). AWS's own real, documented free tier covers 1 million requests and 400,000 GB-seconds of compute every month, at no cost. Genuinely different from EC2 (Chapter 3), where an On-Demand instance bills by the hour whether it's doing useful work or sitting idle — a Lambda function costs nothing at all while it isn't running.

Cold Starts

When a function hasn't run recently, Lambda must provision a fresh execution environment before running it — a real, measurable delay called a cold start. This delay genuinely varies by language: Rust and Go, which compile to native static binaries, start with minimal real overhead, while Java and C# tend to see longer real cold starts due to their own runtime/JVM initialization cost. AWS's own real mitigation for Java specifically, SnapStart, significantly reduces this overhead by resuming from a pre-initialized snapshot rather than starting cold every time.

A Real, Hard Boundary: The Execution Limit

EC2 vs. Lambda

A Lambda function still needs an IAM role (Chapter 2) — least privilege applies exactly as much here as it did to an EC2 instance's own attached role in Chapter 3; "serverless" changes what you manage, not whether permissions still need to be scoped correctly.

Hands-On Exercises