AWS Lambda Reserved vs. Provisioned Concurrency: What Is the Difference?

AWS Lambda lets you run code without managing servers. You upload your function, configure its memory and timeout, and AWS handles the infrastructure needed to execute it.

However, serverless does not always mean that every request starts immediately. When Lambda needs to create a new execution environment, a request can experience a cold start. For applications that need predictable response times, this delay can become a problem.

AWS Lambda provides two concurrency settings that are often confused: reserved concurrency and provisioned concurrency.

Both affect how your function handles incoming requests, but they solve different problems. Reserved concurrency helps control how many executions a function can use. Provisioned concurrency prepares execution environments in advance so requests can start with less initialization work.

Let's look at how they work, when to use each one, and how to configure them.

1. What Does Concurrency Mean in AWS Lambda?

Concurrency is the number of function executions running at the same time.

Suppose your API receives 100 requests at once. If each request invokes a Lambda function and all requests are still running, the function may need up to 100 concurrent executions to handle them without waiting for an existing execution to finish.

A simplified calculation is:

Concurrency = Requests per second × Average execution duration in seconds

For example, if a function receives 40 requests per second and each invocation takes an average of 0.5 seconds:

Concurrency = 40 × 0.5
            = 20

The function needs approximately 20 concurrent executions to handle that traffic under these average conditions.

Actual concurrency requirements can be higher during traffic spikes or when requests take longer than usual. You should measure real workloads rather than relying only on averages.

Understanding concurrency is important because both reserved and provisioned concurrency affect how Lambda capacity is allocated or made available.

2. What Is Reserved Concurrency?

Reserved concurrency sets aside a portion of your AWS account's regional Lambda concurrency capacity for a function. It also sets the maximum number of concurrent executions that function can use.

Consider an application with three Lambda functions:

• An order-processing function
• A reporting function
• A notification function

If reporting suddenly receives a large number of requests, it could consume capacity that the order-processing function also needs.

You can assign reserved concurrency to protect the order-processing function from being crowded out by other functions.

For example:

aws lambda put-function-concurrency \
  --function-name OrderProcessor \
  --reserved-concurrent-executions 50

This configures the function to use at most 50 concurrent executions and reserves that capacity for it within the account's regional concurrency allocation.

If the function needs more than 50 simultaneous executions, additional requests may be throttled until capacity becomes available.

You can inspect the configuration with:

aws lambda get-function-concurrency \
  --function-name OrderProcessor

A successful configuration protects the function's capacity, but it does not guarantee that 50 execution environments will already be initialized and ready to serve requests.

When should you use reserved concurrency?

Reserved concurrency is useful when:

• A critical function must have a predictable share of account capacity.
• A background job should not consume all available Lambda concurrency.
• You need to limit calls to a database or another downstream service.
• You want to control how much concurrency a function can consume.

For example, if your database can safely handle only a limited number of simultaneous operations, limiting Lambda concurrency can help reduce pressure on it.

However, concurrency is not a strict database connection limit. Each invocation may open zero, one, or several connections, and connections can remain open between invocations. Monitor database connections separately.

3. What Is Provisioned Concurrency?

Provisioned concurrency prepares a specified number of Lambda execution environments in advance.

Normally, Lambda may need to initialize an environment when a request arrives and no suitable environment is ready. This initialization contributes to cold-start latency.

With provisioned concurrency, Lambda keeps the configured number of execution environments initialized and ready to respond to requests.

For example, you can configure 20 provisioned environments for a published function version:

aws lambda put-provisioned-concurrency-config \
  --function-name OrderProcessor \
  --qualifier 1 \
  --provisioned-concurrent-executions 20

Here, qualifier 1 refers to a published version of the function. Provisioned concurrency is configured for a published version or an alias that points to a published version, not directly for the unqualified $LATEST version.

Check the configuration status:

aws lambda get-provisioned-concurrency-config \
  --function-name OrderProcessor \
  --qualifier 1

Wait until the status reports READY before relying on the provisioned environments for traffic. While the configuration is being prepared, the status may be IN_PROGRESS or may report an error.

Provisioned concurrency reduces initialization delays for requests served by those prepared environments. It does not eliminate every source of latency, and cold starts can still occur when requests exceed the available provisioned capacity.

When should you use provisioned concurrency?

It is useful when:

• An API has strict response-time requirements.
• A function handles user-facing requests during predictable traffic periods.
• Cold-start delays affect checkout, login, or payment workflows.
• You know approximately how many simultaneous executions you need to keep ready.

Provisioned concurrency is especially useful for latency-sensitive applications, but it has an additional cost. You pay for the configured capacity while it is provisioned, including periods when the function receives little or no traffic.

4. Reserved Concurrency vs. Provisioned Concurrency

The main difference is that reserved concurrency controls allocation and maximum usage, while provisioned concurrency prepares execution environments.

The two settings can be used together.

For example, a function may have reserved concurrency of 50 and provisioned concurrency of 20. In that configuration, 20 environments are prepared in advance, while the function's total concurrency remains limited to 50.

The remaining capacity does not mean that 30 more environments are guaranteed to be warm. Requests using capacity beyond the provisioned amount may experience cold starts.

5. How to Configure Both Settings

Suppose an order API needs enough prepared capacity for normal traffic but must not exceed a safe maximum during traffic spikes.

A practical approach is:

1. Publish a version of the function.
2. Create or update an alias that points to that version.
3. Set reserved concurrency on the function.
4. Configure provisioned concurrency on the alias.
5. Wait until the provisioned configuration is ready.
6. Monitor latency, throttling, and concurrency under realistic load.

First, publish a version:

aws lambda publish-version \
  --function-name OrderProcessor

The command returns a version number. In the following examples, assume that version is 12.

Create an alias that points to the published version:

aws lambda create-alias \
  --function-name OrderProcessor \
  --name production \
  --function-version 12

If the alias already exists, update it instead:

aws lambda update-alias \
  --function-name OrderProcessor \
  --name production \
  --function-version 12

Set reserved concurrency:

aws lambda put-function-concurrency \
  --function-name OrderProcessor \
  --reserved-concurrent-executions 50

Then configure provisioned concurrency on the production alias:

aws lambda put-provisioned-concurrency-config \
  --function-name OrderProcessor \
  --qualifier production \
  --provisioned-concurrent-executions 20

Wait for the configuration to become ready:

aws lambda get-provisioned-concurrency-config \
  --function-name OrderProcessor \
  --qualifier production

The provisioned concurrency configuration must fit within the function's concurrency limits. If the requested capacity cannot be allocated, Lambda may return an error or fail to reach the ready state.

Also remember that reserved concurrency consumes part of your account's regional concurrency allocation. Check the account's available quota before assigning large values across multiple functions.

6. What Happens When Traffic Exceeds Provisioned Concurrency?

Suppose a function has 20 provisioned execution environments and suddenly receives 60 simultaneous requests.

The first 20 requests may be served by the prepared environments, assuming they are available and the requests fit the configured execution model.

Additional requests may use other available Lambda capacity, subject to the function's concurrency limits and the account's regional limits. Those requests can experience cold starts.

If the function reaches its concurrency limit, Lambda can throttle additional requests.

This distinction is important: provisioned concurrency does not automatically set a maximum of 20 executions. Reserved concurrency, when configured, controls that maximum.

For example, with 20 provisioned concurrency and 50 reserved concurrency, the function can potentially handle more than 20 concurrent executions, but no more than the configured reserved limit.

If you instead configure 20 reserved concurrency, the function cannot use more than 20 concurrent executions, regardless of how much other account capacity is available.

7. Monitor Latency, Throttling, and Capacity

After configuring either setting, check whether it solves the actual problem.

Useful Lambda CloudWatch metrics include:

• ConcurrentExecutions: The number of concurrent executions.
• Throttles: Requests that Lambda throttled.
• Duration: How long function invocations take.
• ProvisionedConcurrentExecutions: The number of provisioned environments actively handling invocations.
• ProvisionedConcurrencyUtilization: How much of the configured provisioned capacity is being used.

For latency-sensitive applications, also measure end-to-end request latency at the API or client level. Lambda's Duration metric does not capture every part of a request's journey, such as time spent waiting before invocation or network latency outside the function.

If provisioned concurrency is consistently underused, you may be paying for more capacity than needed. If utilization frequently reaches its limit and latency increases, you may need to adjust capacity or investigate traffic spikes.

Reserved concurrency should also be reviewed against the function's actual workload. A limit that is too low can cause throttling even when the account has unused capacity.

8. Can Provisioned Concurrency Scale Automatically?

Yes. AWS Lambda supports Application Auto Scaling for provisioned concurrency, allowing capacity to change based on configured scaling policies.

This can help when traffic varies throughout the day. You can configure scheduled scaling for predictable events or use supported utilization-based scaling policies to respond to demand.

However, scaling is not instantaneous. Provisioned environments need time to be prepared, so sudden traffic spikes may arrive before additional capacity is ready.

For predictable events, such as a scheduled product launch, consider increasing provisioned concurrency ahead of time. For variable traffic, monitor scaling behavior and keep a realistic estimate of how much demand can arrive before capacity increases.

Conclusion

Reserved concurrency and provisioned concurrency solve different problems in AWS Lambda.

Use reserved concurrency when you need to reserve account capacity for a function or prevent it from consuming too much concurrency. Use provisioned concurrency when you need initialized execution environments ready for latency-sensitive requests.

You can combine both settings when an application needs prepared capacity as well as a firm concurrency limit. Choose values based on measured traffic, execution duration, downstream service limits, and response-time requirements.

The goal is not to provision the largest possible number of environments. It is to provide enough ready capacity for important requests while keeping concurrency and costs under control.