When should a team use reserved concurrency, provisioned concurrency or SnapStart in Lambda?
A practical guide to choosing the cheapest Lambda setup that still keeps peak traffic responsive. It explains when to cap concurrency, when to pre-warm execution environments, and when SnapStart can reduce startup delay for supported Java runtimes.
On this page
Why it mattersThe optionsChoose wellTrade-offsSafeguardsNext stepsIn short
- Reserved concurrency limits and protects capacity, and AWS does not charge extra for it.
- Provisioned concurrency reduces latency by keeping environments pre-initialised, but it adds cost.
- SnapStart can reduce cold starts for supported Java runtimes, but it has runtime-specific limits and troubleshooting considerations.
- The cheapest option is not always the best option if slow starts harm checkout, sign-in or API responsiveness.
- A sensible choice starts with the user journey, then works back to the concurrency setting that matches it.
If Lambda is part of your stack, the hard part is rarely getting it to work. The harder part is keeping it fast enough at busy times without paying for more capacity than the business needs.
AWS gives you three different levers, but they solve different problems. Reserved concurrency protects capacity. Provisioned concurrency pre-initialises execution environments so requests are ready sooner. SnapStart reduces startup time for supported Java managed runtimes by restoring from a snapshot instead of starting from scratch.
The right choice depends on what you are trying to control: spend, peak latency, or risk to other workloads. This article keeps that decision practical.
Start with the business problem, not the feature
The question is not which Lambda setting is best in general. It is which setting gives you acceptable speed at the lowest sensible cost for your workload.
For a founder or product team, that usually means balancing three things. First, customer experience: will the app feel responsive when traffic spikes? Second, cost: are you paying to keep capacity ready when most requests are quiet? Third, operational safety: could one busy function starve another or overload a downstream system?
What each option is actually for
Reserved concurrency
Sets a concurrency limit for a function and reserves capacity for it. AWS says it can protect critical functions or downstream resources, and it does not add a separate charge.
Provisioned concurrency
Pre-initialises execution environments so they are ready to respond immediately. AWS recommends it for interactive workloads where lower, more predictable latency matters, and it does add cost.
SnapStart sits in a different category. It is not a general capacity limit. It is a startup optimisation for supported Java managed runtimes. AWS says it resumes new execution environments from a persisted snapshot, which can reduce cold-start latency when Lambda scales up.
How to choose the cheapest setup that still feels fast enough
- 1
Map the user journey
Start with the paths where delay matters most. A checkout action, login flow, search request or customer-facing API usually matters more than a background job. If a short delay would not change the user’s decision, you probably do not need to pay for the fastest option.
- 2
Decide whether you are solving protection or latency
If the main issue is one function consuming too much capacity, reserved concurrency may be enough. If the issue is startup delay at peak traffic, provisioned concurrency is the closer fit. If your runtime is supported and startup time is the only problem, check SnapStart first.
- 3
Estimate the cost of being ready
Provisioned concurrency can make interactive systems feel more consistent, but it means you pay for readiness. That is useful when slow starts are business-critical, but it may be wasteful for traffic that can tolerate a little delay.
- 4
Check runtime and deployment constraints
SnapStart is available for Java managed runtimes and has operational constraints. AWS documents troubleshooting areas such as publish-time initialisation and snapshot creation issues, so it is worth validating before you rely on it.
- 5
Test the worst minute, not the average day
A setup that looks cheap on paper can still fail under load. Measure the slowest acceptable response under a realistic spike, not just the average request during quiet hours.
The trade-offs are real, and they matter
What you gain
Reserved concurrency gives you a straightforward way to protect important functions. Provisioned concurrency gives you more predictable latency for user-facing traffic. SnapStart can reduce the time it takes a new execution environment to become ready, at least for supported Java runtimes.
What you give up
Reserved concurrency can throttle a function if the limit is too low. Provisioned concurrency costs more because capacity is pre-initialised. SnapStart only applies in certain runtime conditions and needs careful testing before production use.
- Reserved concurrency is good for protection, but it is not a latency fix by itself.
- Provisioned concurrency is a cost decision as much as a performance decision.
- SnapStart can help, but only if your runtime and deployment model support it.
- The cheapest option is the one that meets the service level you actually need, not the one with the lowest headline cost.
In practice, many teams start with the cheaper control and move up only if the user experience proves it is necessary. That is sensible. But the reverse can also be true: if a public-facing workflow is already slow at peak, under-investing in responsiveness can cost more in lost confidence than the capacity bill would have cost.
Ways this goes wrong
0 of 5 complete
A common mistake is to treat cost as the only variable. In reality, latency risk and operational risk matter too. If one function becomes too successful, it may crowd out other work. If one dependency is fragile, faster requests can still expose bottlenecks. Reserved concurrency can help with the first problem, but it does not solve the second on its own.
A practical decision sequence for your team
| If the main concern is | Start with | Why |
|---|---|---|
| Protecting a critical function from being crowded out | Reserved concurrency | It sets a boundary and helps keep other workloads or downstream systems from being overwhelmed. |
| Reducing cold starts for an interactive workload | Provisioned concurrency | It keeps execution environments pre-initialised so requests are ready sooner. |
| Reducing startup delay on supported Java runtimes | SnapStart | It restores environments from a snapshot instead of initialising from scratch. |
- Start with the user journey that feels slowest or riskiest.
- Use reserved concurrency when you need a cap or a safety boundary.
- Use provisioned concurrency when latency matters enough to pay for readiness.
- Check SnapStart if you run a supported Java runtime and startup delay is the main issue.
- Measure peak behaviour, not just average behaviour, before deciding the setup is ‘cheap enough’.
About the author
Nixim Team, Product Engineering
Practical guidance from Nixim on building software, working with AI and running dependable cloud systems.