AWS Lambda
Lambda runs code in response to events without provisioning servers. You pay only for compute time consumed (duration × memory). Functions can be triggered by API Gateway, S3 events, SQS, EventBridge, DynamoDB Streams, and more.
Lambda is a taxi on demand — you call (invoke), it shows up (execution environment), completes the trip (runs your code), then waits. If no one calls for a while, the taxi goes home (environment terminates). Cold start is waiting for the first taxi to arrive.
Execution environment: each invocation gets a micro-VM (Firecracker). Cold starts occur when a new execution environment is initialized — typically 100ms–1s depending on runtime and package size. Warm starts reuse the existing environment, including global variables and database connection pools. Concurrency: reserved concurrency caps executions for a function; provisioned concurrency pre-warms environments to eliminate cold starts. Memory: 128MB–10GB; CPU scales proportionally with memory. Timeout: max 15 minutes. Deployment package: 50MB zipped, 250MB unzipped; layers for shared dependencies.
Lambda's concurrency model: burst limit (3,000 in us-east-1/us-west-2/eu-west-1; 1,000 in most other regions; 500 in some), then 500 additional per minute. Account-level concurrency limit (default 1,000). Throttled invocations return HTTP 429; async invocations retry twice before sending to a dead-letter queue or EventBridge Pipes. Lambda SnapStart (Java) pre-initializes and snapshots the execution environment, reducing cold starts to under 1 second. Lambda@Edge and CloudFront Functions run at edge locations. VPC-attached Lambda used to add ~10s to cold starts for ENI creation, but Hyperplane ENIs (2019+) reduced this to near-negligible latency via shared networking infrastructure. For long-running jobs, Lambda is wrong — use ECS Fargate tasks or AWS Batch.
Lambda is event-driven compute where you pay per execution. Cold starts are the key operational challenge — I address them with provisioned concurrency for latency-sensitive functions and Lambda SnapStart for Java. I keep handler code thin, initialization code outside the handler (reused on warm starts), and avoid VPC unless necessary. For anything beyond 15 minutes, I use ECS Fargate. For API workloads, Lambda + API Gateway gives automatic scaling with zero instance management.
Initializing heavy objects (DB connections, SDK clients) inside the handler — they get re-created on every invocation. Initialize outside the handler to reuse on warm invocations. Also, Lambda timeouts shorter than API Gateway's 29-second timeout will cause misleading errors to API callers.