Concurrency, Throttling, and Reserved Concurrency

Lambda scales by running multiple concurrent executions of your function—one per simultaneous event. When 100 requests arrive at the same time, Lambda runs 100 parallel instances of your function. AWS manages the underlying infrastructure automatically. The account-level concurrency limit is 1,000 concurrent executions per Region by default (soft limit, can be increased via a service quota request).

Concurrency is calculated as: Concurrency = Requests per second × Average duration in seconds. If your function handles 500 requests/second and each takes 0.2 seconds, you need 100 concurrent executions. Understanding this formula helps you predict whether your account limits are sufficient and whether you need to request quota increases before a high-traffic event.

When Lambda receives more requests than its concurrency limit allows, it throttles the excess. For synchronous invocations (e.g., API Gateway), throttled requests immediately receive a 429 TooManyRequestsException that must be handled by the caller. For asynchronous invocations (e.g., S3 events), Lambda queues the events and retries for up to 6 hours before sending to a dead-letter queue.

Reserved Concurrency guarantees a specific number of concurrent executions for a particular function, reserving those from the account pool. It serves two purposes: (1) it guarantees capacity—the function will always have that many executions available even if other functions are consuming account quota; (2) it caps concurrency—the function can never exceed the reserved amount, protecting downstream dependencies from being overwhelmed.

A key exam scenario: a Lambda function writes to an RDS database that has a connection limit of 50. Without concurrency controls, Lambda could scale to hundreds of concurrent executions and exhaust all database connections, causing errors for every function. Setting reserved concurrency to 40 ensures Lambda never exceeds 40 simultaneous database connections, protecting the RDS instance. This is a critical pattern for any Lambda function that calls a connection-limited service.

Provisioned Concurrency pre-initialises a specified number of Lambda execution environments so they are ready to respond immediately without a cold start. This is critical for latency-sensitive APIs where even a 100ms cold start is unacceptable. You pay an hourly rate for provisioned concurrency even when those environments are idle, so combine it with Auto Scaling to adjust provisioned levels based on predicted traffic patterns.

These are often confused but serve different purposes. Reserved Concurrency limits and guarantees capacity allocation from the account pool—it does NOT eliminate cold starts. Provisioned Concurrency pre-warms execution environments to eliminate cold starts—it does NOT prevent other functions from using the same pool. Use reserved concurrency to cap throughput; use provisioned concurrency to improve latency. Both can be used together on the same function.

Lambda does not scale to full concurrency instantaneously. There is an account-level burst limit (initial scale rate) that varies by Region—typically 3,000 initial burst, then 500 additional executions per minute until the limit is reached. For applications that anticipate sudden massive spikes (viral traffic, flash sales), use Provisioned Concurrency to pre-warm enough environments so the burst limit doesn't cause throttling during the initial surge.

Monitor Lambda concurrency with these key CloudWatch metrics:

• ConcurrentExecutions: current number of running instances
• Throttles: count of throttled invocations (should be zero in a healthy system)
• UnreservedConcurrentExecutions: account-level unreserved pool
• ProvisionedConcurrencyUtilization: how much provisioned capacity is in use

Set alarms on Throttles to get notified before throttling impacts end users.

When designing systems that invoke Lambda synchronously (API Gateway, SDK direct calls), implement exponential backoff with jitter in the caller. AWS SDKs have built-in retry logic, but for API Gateway-fronted Lambda you must handle 429 responses in your client application. For SQS-triggered Lambda, the SQS service itself handles retry; set the Maximum Receives on the source queue appropriately and configure a DLQ for exhausted retries.

For Kinesis Data Streams and DynamoDB Streams, Lambda concurrency is bounded by the number of shards (Kinesis) or partitions (DynamoDB). Each shard/partition is processed by exactly one concurrent Lambda execution. If you have 10 Kinesis shards, Lambda runs up to 10 concurrent executions for that trigger. This means throttle issues with stream-based triggers are usually solved by increasing shard count rather than raising concurrency limits.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Reserved Concurrency both guarantees and caps a function's concurrent executions to protect downstream services and ensure availability, Provisioned Concurrency pre-initialises environments to eliminate cold starts for latency-sensitive workloads, and throttling manifests as 429 errors for synchronous invocations and queued retries for asynchronous ones—monitor with the Throttles CloudWatch metric. Next up we explore Lambda Layers and deployment packages for managing large dependencies.