AWS Lambda: Serverless Functions, Concurrency & Cold Starts

AWS Lambda

AWS Lambda is a serverless function platform (Functions-as-a-Service). You deploy a handler, and AWS runs it on demand in response to events — HTTP requests, queue messages, schedules, object uploads — scaling automatically and billing only for the compute you use. There are no servers to provision or patch.

It excels as event-driven glue and for bursty workloads, but it rewards a particular discipline: stateless handlers, short run times, and an awareness of concurrency's downstream effects. For the broader design patterns, see Serverless Architecture Patterns.

TL;DR

Great for event-driven glue and bursty workloads.
Design for stateless execution and short run times.
Watch cold starts, timeouts, and dependency size.
Push heavy or spiky work through queues + workers.

Quick Example

A handler receives an event and returns a response — AWS handles the rest:

How Lambda Works

You write a function handler; AWS runs it in a managed runtime, triggered by events:

API Gateway — HTTP/REST APIs
SQS / SNS — queues and notifications
S3 events — object created/deleted
EventBridge schedules — cron-like jobs

Packaging & Deployment

Zip bundle — simple, fast, fine for most functions.
Container image — useful for larger dependencies or custom runtimes.

Either way, keep the handler small and push heavy logic into shared libraries or downstream services.

Concurrency & Backpressure

Lambda scales concurrency fast — which is great until it overwhelms something downstream. The classic failure mode:

⚠️ Traffic spike → hundreds of concurrent Lambdas → database connection pool exhausted → cascading failures.

Mitigations:

Cap reserved concurrency so downstream systems stay healthy.
Put a queue in front to smooth bursts.
Cache read-heavy paths.
Use RDS Proxy or a serverless driver for database connections.

Common Use Cases

Webhook handlers
Background processing
File processing on S3 uploads
Scheduled tasks
Lightweight APIs

See Message Queues.

Best Practices

Set explicit timeouts and understand each trigger's retry behavior.
Make handlers idempotent — events can be delivered more than once; assume at-least-once, not exactly-once.
Initialize clients outside the handler (HTTP/DB) so warm invocations reuse them.
Never store secrets in code — use environment variables and a secret manager. See Secrets Management.
Emit structured logs and metrics (duration, errors) and trace multi-step workflows. See Logging.

Common Mistakes

Non-idempotent handler on retry

Reconnecting to the database per invocation

FAQ

How do I deal with cold starts?

A cold start is the latency when Lambda initializes a new execution environment. Reduce it by keeping deployment packages small, initializing SDK/DB clients at module scope (so they're reused on warm invocations), choosing a lean runtime, and — for latency-critical paths — enabling provisioned concurrency to keep instances warm.

Does Lambda guarantee exactly-once execution?

No. Depending on the trigger, events can be delivered more than once and functions can be retried on failure. Design idempotent handlers that dedupe on a stable key, so reprocessing the same event is harmless. Never assume exactly-once delivery.

When should I NOT use Lambda?

For long-running tasks (beyond the timeout), steady high-throughput workloads (where always-on compute is cheaper), workloads needing persistent connections or large in-memory state, and anything that hammers a connection-limited database without a proxy. In those cases use ECS/Fargate, EC2, or a queue-plus-worker design.

How do I keep Lambda from overwhelming my database?

Cap reserved concurrency, put an SQS queue in front to buffer bursts, use a connection proxy (RDS Proxy) or serverless-native driver, and cache read-heavy paths. The goal is to decouple Lambda's fast scaling from the database's finite connection capacity.