Lambda Concurrency: Reserved and Provisioned

AWS Lambda is a serverless compute service that runs your code in response to events and automatically manages the underlying compute resources. Each invocation of your function runs in an isolated execution environment. Concurrency refers to the number of in-flight invocations at any given time—i.e., the number of executions that are currently processing requests. By default, AWS Lambda can scale to handle thousands of concurrent executions per region, but there is a regional safety limit (default 1,000 concurrent executions per region) to protect against runaway code or accidental infinite loops.

For a production workload, you need fine-grained control over concurrency to:

AWS Lambda provides two concurrency controls: Reserved Concurrency and Provisioned Concurrency. They serve different purposes but can be used together.

Reserved Concurrency guarantees that your function always has a specific amount of concurrency available to it. This is a hard cap and a reservation. When you set Reserved Concurrency on a function, you are both reserving that capacity for the function and limiting it to that maximum. No other function can use the reserved concurrency, and your function cannot exceed the reserved amount.

How it works internally: - When you set Reserved Concurrency to, say, 100, Lambda deducts 100 from the regional concurrency pool. The function is guaranteed to have 100 concurrent executions available at all times. - If the function attempts to invoke more than 100 concurrent executions, it will be throttled (HTTP 429 TooManyRequestsException). - Other functions in the same account and region cannot use the reserved 100 concurrency; they compete for the remaining pool. - Reserved Concurrency does not pre-warm environments. Cold starts still occur when new execution environments are created.

Key values and defaults: - Regional concurrency limit: 1,000 by default (can be increased via Service Quotas request). - Reserved Concurrency can be any integer from 0 to the regional limit (subject to remaining pool). - Setting Reserved Concurrency to 0 effectively disables the function (all invocations are throttled). - You cannot set Reserved Concurrency higher than the regional limit minus the sum of all other Reserved Concurrency settings.

Configuration: You can set Reserved Concurrency via:

Verification: - AWS CLI: aws lambda get-function-concurrency --function-name my-function returns ReservedConcurrentExecutions. - CloudWatch metrics: ConcurrentExecutions metric shows actual concurrency. You can set alarms when it approaches the reserved limit.

Provisioned Concurrency is designed to eliminate cold starts. It initializes a specified number of execution environments ahead of time, so they are ready to process requests immediately. When a request arrives, it is served by one of the pre-warmed environments, resulting in consistent low latency.

How it works internally: - When you set Provisioned Concurrency to, say, 50, Lambda creates and maintains 50 execution environments that are fully initialized (including any code outside the handler, such as database connections or SDK clients). - These environments are kept warm and ready. Each environment can handle one request at a time (concurrency). - If the actual concurrency exceeds the provisioned level, additional environments are created on-demand (with cold starts) up to the function's reserved or unreserved concurrency limit. - Provisioned Concurrency is billed per second for the provisioned environments, even if they are idle. - You can schedule Provisioned Concurrency using Application Auto Scaling with a target tracking policy or scheduled scaling.

Key values and defaults: - Provisioned Concurrency can be set independently of Reserved Concurrency. - You can set Provisioned Concurrency to any value up to the function's reserved concurrency (if set) or the regional limit. - Provisioned Concurrency is applied per function version or alias. You cannot set it on $LATEST. - You can use Application Auto Scaling to automatically adjust Provisioned Concurrency based on utilization (e.g., keep 70% of reserved concurrency provisioned).

Configuration: - AWS Console: Function > Versions/Aliases > Select version/alias > Actions > Configure Provisioned Concurrency. - AWS CLI: aws lambda put-provisioned-concurrency-config --function-name my-function --qualifier PROD --provisioned-concurrent-executions 50 - CloudFormation: ProvisionedConcurrencyConfig property on AWS::Lambda::Version or AWS::Lambda::Alias.

Verification: - AWS CLI: aws lambda get-provisioned-concurrency-config --function-name my-function --qualifier PROD returns Allocated and Available provisioned concurrency. - CloudWatch metrics: ProvisionedConcurrencyExecutions and ProvisionedConcurrencyUtilization.

You can use both controls together. For example:

When a function has no Reserved or Provisioned Concurrency, it can still scale rapidly. AWS Lambda has a burst concurrency limit per region that varies by account and region. The default burst is between 500 and 3000 concurrent executions per minute, depending on the region. This allows functions to handle sudden spikes but is not guaranteed. For predictable scaling, use Reserved and Provisioned Concurrency.

When a function is throttled:

An online retailer uses Lambda to process checkout requests. The checkout function must handle flash sales with sudden traffic spikes. Without concurrency controls, the function might be throttled if other functions (e.g., image processing) consume all regional concurrency. The team sets Reserved Concurrency to 500 to guarantee capacity for checkout. They also set Provisioned Concurrency to 300 on the PROD alias to eliminate cold starts for the first 300 concurrent users. During a flash sale, traffic peaks at 450 concurrent requests. The first 300 are served without cold starts; the remaining 150 experience a slight delay as new environments are initialized. The function stays within its 500 limit, and no requests are throttled. Auto-scaling adjusts Provisioned Concurrency based on utilization, reducing cost during off-peak hours. Misconfiguration: if Reserved Concurrency is set too low (e.g., 200), the function would throttle at 200, causing failed checkouts and lost revenue.

A financial services company ingests stock market data via Kinesis Streams and processes it with a Lambda function. The function must maintain low latency to avoid data backlogs. The team sets Provisioned Concurrency to 100 on the function alias to keep environments warm. They also set Reserved Concurrency to 100 to prevent other functions from starving this pipeline. Because the data volume is predictable, they use scheduled scaling to increase Provisioned Concurrency to 200 during market hours and reduce to 20 overnight. This optimizes cost while ensuring performance. A common mistake: forgetting that Provisioned Concurrency must be set on a version or alias, not $LATEST. If set on $LATEST, the configuration is silently ignored, leading to unexpected cold starts.

A SaaS platform runs dozens of microservices as Lambda functions. One function, responsible for user authentication, is critical and must never be throttled. The team sets Reserved Concurrency to 50 for auth, leaving 950 for other functions. They also set Provisioned Concurrency to 30 on the auth function's PROD alias to ensure fast logins. However, a misbehaving image-resizing function starts consuming 800 concurrent executions due to a bug, leaving only 150 for the remaining functions. The auth function is unaffected because its 50 are reserved. Without Reserved Concurrency, the auth function would have been starved. This illustrates how Reserved Concurrency provides isolation. The team also monitors ConcurrentExecutions per function and sets alarms to detect anomalous consumption.