AWS Lambda Concurrency

AWS Lambda Concurrency

AWS Lambda concurrency is the number of function invocations that are actively running at the same time.

If a function receives multiple requests before earlier requests finish, Lambda needs additional execution capacity to process them concurrently.

Understanding concurrency helps you predict scaling requirements, prevent throttling, protect downstream services, and isolate important workloads.

AWS Lambda Concurrency at a Glance

How Does Lambda Concurrency Work?

Suppose a function takes one second to execute.

If it receives one request every second:

Request 1 ----- 1 sec
Request 2       ----- 1 sec
Request 3             ----- 1 sec

Concurrency stays near:

1

Now imagine the same function receives five requests simultaneously.

Request 1 -----
Request 2 -----
Request 3 -----
Request 4 -----
Request 5 -----

Lambda needs approximately:

5 concurrent executions

AWS defines concurrency as the number of in-flight requests a function is handling at the same time.

How to Calculate Lambda Concurrency

A useful approximation is:

Concurrency =
requests per second × average request duration in seconds

Consider:

Request rate = 100 requests/sec
Average duration = 0.5 sec

Then:

100 × 0.5 = 50

Approximate required concurrency is 50.

Now suppose a downstream API becomes slower and function duration increases to two seconds:

100 × 2 = 200

Traffic did not change.

Required concurrency increased four times because execution became slower.

This relationship makes duration an important concurrency signal.

What Is the Default Lambda Concurrency Limit?

AWS currently documents a default account-level concurrency quota of 1,000 concurrent executions per Region.

Functions without their own concurrency allocation share the available pool.

AWS allows qualifying accounts to request increases to this regional quota.

Account-specific quotas should always be checked rather than assuming the documented default applies to every environment.

What Is Unreserved Concurrency?

Unreserved concurrency is the portion of account concurrency that remains available to functions without reserved capacity.

Suppose the regional concurrency quota is:

1,000

and you reserve:

300 → checkout
200 → payments

A simplified view is:

Total concurrency       1,000
Reserved                 -500
Remaining shared pool     500

AWS maintains some unreserved capacity for functions without reserved concurrency, so you cannot allocate every available concurrency unit as reserved capacity.

What Is Reserved Concurrency?

Reserved concurrency allocates capacity exclusively to a function.

For example:

checkout-function
Reserved concurrency = 300

This has two effects.

First, other functions cannot consume those 300 concurrency units.

Second, the checkout function cannot scale above 300 concurrent executions.

AWS therefore describes reserved concurrency as both a reservation and a maximum.

Reserved concurrency does not carry an additional Lambda charge.

Why use reserved concurrency?

It is useful when you need to:

• protect a critical function
• prevent one function from taking the entire shared pool
• protect a downstream database
• limit calls to a third-party API
• isolate workloads

Consider a database that supports only 100 safe concurrent connections.

Allowing a Lambda function to scale to 1,000 database connections could cause the database to fail.

Setting reserved concurrency around the downstream capacity can act as a protective boundary.

What Is Provisioned Concurrency?

Provisioned concurrency keeps a configured number of execution environments initialized before requests arrive.

Its primary goal is lower and more predictable startup latency.

For example:

Provisioned concurrency = 100

Lambda prepares 100 environments ahead of demand.

AWS describes provisioned concurrency as useful for interactive and latency-sensitive applications and notes that it incurs additional charges.

Reserved vs. Provisioned Concurrency

A common mistake is using provisioned concurrency to solve ordinary throttling.

Provisioned concurrency primarily addresses environment initialization latency.

Reserved concurrency and account quotas are more directly related to capacity isolation.

Lambda Concurrency Scaling Rate

Account concurrency is not the same thing as scaling speed.

For standard Lambda functions, AWS currently documents a concurrency scaling rate of:

1,000 additional execution environments
per function
every 10 seconds

AWS also describes this as the ability to accommodate up to 10,000 additional requests per second every 10 seconds, depending on execution characteristics.

This distinction matters during abrupt traffic spikes.

You may have sufficient total account concurrency while still temporarily exceeding the speed at which a function can create new execution environments.

What Happens When Lambda Runs Out of Concurrency?

When a function cannot obtain the required concurrency, Lambda throttles additional requests.

The exact behavior depends on the invocation model.

Synchronous callers can receive a throttling response.

Asynchronous and event-driven workloads can involve retries, queues, or event-source-specific behavior.

This is why a Lambda throttle should be investigated alongside the function's trigger and retry strategy.

Metrics for Monitoring Lambda Concurrency

AWS exposes several useful concurrency metrics through CloudWatch.

ConcurrentExecutions

Number of active concurrent function invocations.

UnreservedConcurrentExecutions

Concurrency currently being used from the shared unreserved pool.

ClaimedAccountConcurrency

Concurrency unavailable for new on-demand invocations, including active unreserved executions and allocated reserved/provisioned concurrency.

AWS specifically notes that ClaimedAccountConcurrency can provide a better picture of capacity availability than looking only at currently active executions.

For provisioned concurrency, also watch:

• ProvisionedConcurrentExecutions
• ProvisionedConcurrencyUtilization
• ProvisionedConcurrencySpilloverInvocations

Lambda Concurrency Example

Imagine this environment:

Regional quota             1,000

Checkout reserved            300
Payments reserved            200
Other workloads             shared

Normal traffic:

Checkout      120
Payments       80
Other         250

Everything operates normally.

Then a background job suddenly consumes most of the shared capacity.

Checkout and payments remain protected because they have reserved concurrency.

Without those reservations, the background workload could have consumed the concurrency required by critical functions.

When Should You Increase Lambda Concurrency?

Increase the account quota when:

• traffic legitimately requires more concurrent execution
• functions are healthy
• downstream systems can absorb additional load
• throttling comes from regional capacity rather than poor performance

Do not automatically increase concurrency when:

• function duration suddenly increased
• a database is overloaded
• an external API became slower
• retry storms are occurring
• one function is consuming capacity unexpectedly

Higher concurrency can make downstream failures worse.