AWS Lambda Scaling and Concurrency Explained

Simple explanation

Lambda does not have servers you manage. When your function is invoked, AWS creates an isolated execution environment, a lightweight container that runs your code. If 50 requests arrive at the same time, Lambda runs 50 environments in parallel. If requests arrive one at a time, Lambda uses one environment and reuses it for the next request.

The number of environments running at the same moment is your concurrency. Every scaling decision in Lambda flows from this number. Account limits, reserved concurrency, provisioned concurrency, and throttling all relate to managing how many environments are running simultaneously.

How Lambda scaling works

Concurrency is the real scaling unit

Unlike EC2 or containers, you do not choose instance counts or pod replicas. Lambda’s scaling unit is concurrent executions: the number of function invocations running at the same instant. Lambda adds new execution environments automatically when concurrent demand increases, and freezes or terminates idle environments when demand drops.

Each execution environment handles exactly one request at a time. Environments are not shared between concurrent requests. More concurrency means more environments running in parallel, not a queue of requests waiting behind each other.

This matters for sizing. A function that runs fast can handle high throughput with low concurrency. A slow function needs more concurrency to handle the same throughput.

The basic concurrency formula

You can estimate the concurrency your function needs at steady state:

Concurrency = Requests per second × Average duration (in seconds)

Worked example: Your API function receives 500 requests per second and each invocation takes 200ms on average:

500 × 0.2 = 100 concurrent executions needed

Now imagine traffic doubles to 1,000 requests/second during peak hours. You now need 200 concurrent executions. If your account limit is 1,000 and no other function is consuming concurrency, you have plenty of headroom. But if your critical payment API only has 50 reserved concurrency and a spike hits, it throttles regardless of available account capacity.

Use this formula to size reserved concurrency, spot whether a function might starve others, and decide whether provisioned concurrency makes sense for your traffic pattern.

What happens during traffic spikes

Warm environments vs cold starts

If a warm (previously used) execution environment is available, Lambda routes the new request to it immediately with no startup overhead. The only time cost is your handler’s own execution time.

If no warm environment is available (because all existing ones are busy, or because this is the first invocation), Lambda creates a new one. This is a cold start. It involves downloading your code, starting the runtime, and running any initialisation code outside your handler. Cold starts typically add 100 to 300ms for Python and Node.js functions. Java functions can take significantly longer without SnapStart.

Cold starts, warm starts, and strategies to minimise their impact are covered in the Lambda Overview.

Why latency can jump during sudden scale-out

When a traffic spike hits and Lambda needs to create many new environments quickly, every one of those new environments has a cold start. If your function goes from 5 concurrent executions to 200 in a few seconds, 195 new environments are initialising at the same time. This creates a latency spike at the moment of scale-out: p99 latency can look terrible even though the function itself is running correctly.

Lambda does not scale to maximum concurrency instantly. It can reach a substantial initial burst quickly, then continues adding capacity per minute until the account limit is reached. For most workloads this is fast enough. For functions where sudden spikes from near-zero to high concurrency are common and latency matters, provisioned concurrency is the solution. Pre-warmed environments are always ready with no cold start.

Lambda concurrency controls

Account concurrency

Every AWS account has a regional concurrency limit: the maximum total concurrent Lambda executions across all functions in that region. The default is 1,000. This pool is shared across every Lambda function in the region.

If one function is using 950 concurrent executions and a second function suddenly spikes, the second function only has 50 executions left before throttling, even if it has never caused problems before. This shared pool is why concurrency planning matters in accounts with multiple Lambda functions.

You can request a limit increase via the Service Quotas console or AWS Support. See the Service Quotas guide for how that process works.

Reserved concurrency

Reserved concurrency allocates a dedicated slice of the account concurrency pool to a specific function. It has two effects simultaneously:

1. Ceiling: The function cannot exceed its reserved limit, even if the account has spare concurrency. This caps a noisy function from consuming the whole pool.
2. Guarantee: No other function can consume that reserved slice. The capacity is held exclusively for this function.

Reserved concurrency reduces the unreserved pool available to all other functions. If you set reserved concurrency of 300 on one function, the remaining functions share 700 (assuming a 1,000 limit). Plan this carefully: over-reserving starves your other functions.

Setting reserved concurrency to 0 disables the function entirely. Every invocation is throttled immediately. This is useful for emergency shutoffs.

# Reserve 200 concurrent executions for a specific function
aws lambda put-function-concurrency \
  --function-name my-api-function \
  --reserved-concurrent-executions 200

Provisioned concurrency

Provisioned concurrency pre-initialises a specific number of execution environments so they are always warm and ready, with no cold start delay for the first N concurrent requests.

Provisioned concurrency must be applied to a published version or alias, not to $LATEST. This forces you to deploy versioned code for production, which is good practice anyway. See Deploying Your First Lambda Function for how Lambda versioning and aliases work.

# Configure provisioned concurrency on a published alias
aws lambda put-provisioned-concurrency-config \
  --function-name my-api-function \
  --qualifier production \
  --provisioned-concurrent-executions 50

Provisioned concurrency costs extra. You pay for pre-warmed environments whether they receive traffic or not. For cost-conscious deployments, use Application Auto Scaling to schedule provisioned concurrency to match your traffic pattern: scale up before peak hours, scale down at night, instead of running at full capacity 24/7. See Lambda Cost Optimisation for scheduling strategies and cost breakdowns.

Event source concurrency notes

Some event sources have their own concurrency behaviour that interacts with Lambda’s limits:

• SQS: Lambda scales the number of pollers based on queue depth. You can set MaximumConcurrency on the event source mapping to cap how many parallel invocations process messages from that queue. This is useful for protecting downstream systems (databases, third-party APIs) that cannot handle high fan-out.
• Kinesis and DynamoDB Streams: Lambda processes one batch per shard concurrently. Adding more shards increases parallelism. You cannot have more concurrent executions from a stream than the number of shards.
• Async sources (S3, SNS, EventBridge): Lambda manages an internal retry queue. If your function is throttled, Lambda retries automatically with backoff. Configure a dead letter queue so events are not silently lost after retries are exhausted. See Event-Driven Compute with Lambda for DLQ setup.

Reserved concurrency vs provisioned concurrency

These two features are commonly confused because their names sound similar. They solve different problems and can be used independently or together.

When to use concurrency controls

For decisions between Lambda and other compute options, see Choosing Between Lambda, ECS and EC2. If your workload regularly needs sustained high concurrency, containers or EC2 may be a better fit than provisioned concurrency.

Troubleshooting throttling

What throttling looks like

Throttling occurs when Lambda cannot accept a new invocation because concurrency is at its limit. The symptoms differ by invocation type:

• Synchronous (API Gateway, ALB, direct invoke): The caller receives a 429 TooManyRequestsException immediately. API Gateway surfaces this as an HTTP 429. Users may see errors if your client does not retry.
• Asynchronous (S3, SNS, EventBridge): Lambda retries automatically for up to 6 hours with exponential backoff. Events are not immediately lost, but they are delayed. After all retries fail, the event is dropped unless you have a dead letter queue configured.
• Event source mappings (SQS, Kinesis, DynamoDB Streams): Lambda pauses consumption from the source. For SQS, messages stay in the queue past their visibility timeout and become visible again for retry. For Kinesis and DynamoDB Streams, Lambda retries the batch until the records expire from the stream.

What to check in CloudWatch

Open CloudWatch and look for these Lambda metrics under the AWS/Lambda namespace:

• Throttles: count of throttled invocations. Any non-zero value warrants investigation.
• ConcurrentExecutions: current concurrency per function. Watch for this consistently hitting your reserved or account limit.
• UnreservedConcurrentExecutions: the remaining shared pool across all unreserved functions. If this is near zero, unreserved functions will throttle.
• InitDuration: how long cold starts are taking. Consistently high values suggest provisioned concurrency may help.

# Check the current concurrency settings for a function
aws lambda get-function-concurrency --function-name my-function

# Count throttled invocations in the last hour
aws cloudwatch get-metric-statistics \
  --namespace AWS/Lambda \
  --metric-name Throttles \
  --dimensions Name=FunctionName,Value=my-function \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 300 \
  --statistics Sum

What to change first

Work through this in order:

1. Is the function hitting its reserved concurrency cap? If so, either raise the reserved limit or investigate why traffic spiked. Understand the cause before raising limits.
2. Is the account concurrency pool exhausted? Check UnreservedConcurrentExecutions. If it is near zero, a different function may be consuming the pool. Use reserved concurrency to isolate critical functions.
3. Is this a burst spike (sudden jump from near-zero)? If the function handles sudden, unpredictable bursts and latency matters, provisioned concurrency is the right fix.
4. Are async callers handling retries? Configure DLQs, check retry counts, and ensure your application can handle delayed or out-of-order processing.
5. Should you request a quota increase? If your workload legitimately needs more than the default concurrency limit, request an increase via Service Quotas. See Service Quotas for the process.