AWS Lambda Concurrency | Reserved Vs Provisioned.

 

Reserved Concurrency" and Provisioned Concurrency are two related but different AWS Lambda features that control how many concurrent executions the function can have and its “warmed up” posture.

Here’s twtech breakdown:

1. Reserved Concurrency

• Purpose:
  Guarantees a certain number of concurrent executions for twtech Lambda function and limits the maximum concurrency it can use.
• How it works:
• When you set Reserved Concurrency to N, AWS ensures your function can always run up to N concurrent instances, no more.
• This also prevents other functions from using those slots.
• If concurrency hits that number, further requests are throttled.
• Use case:
• Guarantee availability for critical functions.
• Prevent a function from consuming all concurrency and starving others.

2. Provisioned Concurrency

• Purpose:
  Keeps a number of Lambda environments pre-initialized and ready to run without cold starts.
• How it works:
• When twtech sets Provisioned Concurrency to M, AWS pre-warms M Lambda instances and keeps them running.
• Requests that fit within M capacity have no cold start latency.
• Requests beyond M but under the function's concurrency limit still run, but may cause cold starts.
• Billing impact:
• twtech pays for the pre-warmed instances, even if idle.
• Use case:
• Functions with strict latency requirements (e.g., APIs, real-time processing).

Key Differences

Feature	Reserved Concurrency	Provisioned Concurrency
Main Goal.	Limit & guarantee max concurrency.	Eliminate cold starts
When charged.	Only when function executes.	Always for provisioned instances, plus execution time
Affects other functions.	Yes, by reserving capacity.	No, unless you also set reserved concurrency
Cold starts.	Still possible.	Avoided for provisioned requests

twtech can combine them (Reserved & Provisioned):

• Set Reserved Concurrency to cap usage and ensure capacity for that function.
• Enable Provisioned Concurrency for part or all of that reserved capacity to remove cold starts.

When twtech sets Provisioned Concurrency to M for an AWS Lambda function, here’s what actually happens:

Step-by-Step Behavior

1. AWS Pre-Warms M Instances
• AWS immediately spins up M separate execution environments (containers) for your Lambda function.
• Each one loads:
• The Lambda runtime (e.g., Python, Node.js, Java)
• twtech code
• Any dependencies from /opt or layers
• The init phase (Init) is completed ahead of time, so requests start execution instantly.
2. Always Running
• Those M environments stay alive, idle but ready, until twtech changes the number or disable provisioned concurrency.
• Even if no requests come in, AWS bills twtech for keeping them warm.
3. Handling Requests
• First M concurrent requests → handled instantly (no cold start).
• Requests beyond M → either:
• Use on-demand concurrency (may cause cold starts).
• Or, if twtech has set Reserved Concurrency, they may be throttled.
4. Billing Impact
• twtech pays per-second for keeping those M environments provisioned.
• twtech also pay for request execution on top of that.

Example

If:

• M = 5
• twtech Lambda is invoked 10 times at once:

Request #	Instance Source	Cold Start?
1 → 5	Provisioned pool	❌ No
6 → 10	On-demand (if allowed)	✅ Possible

 NB:

• In the context of AWS Lambda's Provisioned Concurrency, "M" typically represents the number of provisioned concurrency units (execution environments) twtech wants to allocate to its function.