AWS Lambda
AWS's function-as-a-service — code that runs on demand in Firecracker microVMs, scales to zero, and bills per millisecond. The reference implementation of serverless.
What is AWS Lambda?
AWS Lambda runs your code in response to events — HTTP requests (via API Gateway), queue messages, file uploads, schedules — with no servers to manage. You upload a function; Lambda provisions an isolated execution environment on demand, runs it, and bills per millisecond of execution plus memory. It scales to zero (pay nothing idle) and scales out automatically to thousands of concurrent executions. It effectively defined the modern serverless FaaS category.
The Firecracker foundation
Lambda’s isolation is worth understanding because it dissolves the old container-vs-VM tradeoff. Each function runs in a Firecracker microVM — a minimal virtual machine that boots in ~125ms, giving Lambda VM-grade security isolation between tenants at container-grade speed and density. This is why AWS can safely pack many customers’ functions onto shared hardware, and it’s the same technology under Fargate. It’s also why cold starts exist and why they’re as fast as they are.
The constraints that shape Lambda architectures
Lambda’s limits are its design language. 15-minute max execution — long jobs need Step Functions or a different service. Stateless — no local persistence between invocations; state lives in S3/DynamoDB/ElastiCache. Package/memory caps and a coupling where more memory also means more CPU (so memory tuning is performance tuning, not just capacity). Cold starts on scale-out and after idle. The cost model rewards short, efficient, event-driven functions and punishes long-running or high-sustained-throughput workloads — past a certain constant load, a container or EC2 is cheaper, which is the serverless-vs-containers crossover in miniature.
What people get wrong
- Lambda for sustained high-throughput — per-invocation pricing crosses over containers; do the math before committing.
- Connections per invocation: opening a fresh DB connection each time exhausts the database — use RDS Proxy or pooling.
- Ignoring memory-CPU coupling — under-provisioning memory throttles CPU and can make functions slower and pricier than a larger setting.
Primary source: AWS Lambda documentation
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.