AWS Lambda

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

Lambda’s Execution Model and Limits

A Lambda function executes in response to a triggering event — an API Gateway request, an S3 object upload, a scheduled CloudWatch event, among many others — running in an isolated, ephemeral execution environment that AWS provisions on demand and tears down after a period of inactivity. Functions have hard limits worth designing around: a maximum execution duration (15 minutes), memory allocation that also proportionally scales available CPU, and a deployment package size limit, all of which mean Lambda is best suited to relatively short-lived, stateless units of work rather than long-running processes or workloads with very large dependencies, where a container-based service like Fargate or a traditional server-based deployment is generally a better architectural fit.