How do AWS Lambda concurrency and scaling work?

Concurrency is in-flight work, not request rate

A useful estimate is request rate multiplied by average duration. One hundred requests per second that each take half a second require about fifty concurrent executions at steady state; longer duration or traffic bursts increase the requirement.

This estimate is only a starting point. Retries, uneven partitions, cold initialization, external latency, and asynchronous buffers change the observed shape, so validate it with load tests and production metrics.

Use concurrency controls for different jobs

Reserved concurrency both guarantees a portion of regional capacity to one function and limits how much that function can consume. Provisioned concurrency keeps a configured number of execution environments initialized for latency-sensitive traffic.

Scale to the capacity of the whole path

Lambda can scale faster than a relational database connection pool, vendor API, or limited downstream service. Unbounded success at the compute layer can therefore create failure elsewhere.

Use queues, rate controls, reserved concurrency, connection reuse, caching, and load shedding to align demand with the slowest safe dependency. Monitor throttles and backlog age together rather than treating either in isolation.

Plan, test, and request quota changes early

Record expected steady traffic, burst size, duration percentiles, event-source parallelism, and recovery traffic after an outage. Confirm regional quotas and any service-specific scaling behavior before a launch or migration.

Load tests should exercise the integrated path with realistic payloads and dependency limits. A function-only benchmark cannot show queue buildup, database pressure, throttling, or customer-visible latency.