Provisioned vs Reserved vs SnapStart Concurrency: Which Lambda Control to Use When

Lambda has three concurrency controls and most teams use the wrong one for their problem. Provisioned Concurrency, SnapStart, and Reserved Concurrency each solve different problems at different costs. Using Provisioned Concurrency when SnapStart would suffice is expensive. Using Reserved Concurrency when cold starts matter leaves users waiting. Here is the decision framework.

⚡ TL;DR: Reserved Concurrency caps maximum instances (isolation, throttle protection). Provisioned Concurrency pre-warms N instances (zero cold starts, costs money). SnapStart snapshots JVM post-init (Java only, 96% of PC benefit, free). For Java: always try SnapStart first. For non-Java latency-critical APIs: Provisioned Concurrency with Auto Scaling.

The three concurrency types — what each actually does

# 1. Reserved Concurrency
# What: Maximum concurrent instances for one function
# Cold starts: NOT eliminated
# Cost: FREE
# Use: Isolate functions, prevent one function consuming all account concurrency

aws lambda put-function-concurrency \
  --function-name my-fn \
  --reserved-concurrent-executions 100
# Requests beyond 100 get 429 TooManyRequests

# 2. Provisioned Concurrency
# What: Pre-initialize N instances — always warm
# Cold starts: ELIMINATED for provisioned count
# Cost: $0.000004646/GB-hour (always running, even idle)
# 1 unit, 512MB, 24/7: $1.63/month. 10 units: $16.30/month

# 3. SnapStart (Java 11/17/21 only)
# What: Snapshot JVM after init, restore on cold start
# Cold starts: Reduced 4-8s to 100-400ms
# Cost: FREE

Application Auto Scaling for Provisioned Concurrency

# Scale PC up before peak traffic, down after — avoid paying for idle
Resources:
  PCTarget:
    Type: AWS::ApplicationAutoScaling::ScalableTarget
    Properties:
      MaxCapacity: 20
      MinCapacity: 2
      ResourceId: !Sub "function:${MyFn}:live"
      ScalableDimension: lambda:function:ProvisionedConcurrency
      ServiceNamespace: lambda

  PCPolicy:
    Type: AWS::ApplicationAutoScaling::ScalingPolicy
    Properties:
      PolicyType: TargetTrackingScaling
      ScalingTargetId: !Ref PCTarget
      TargetTrackingScalingPolicyConfiguration:
        TargetValue: 0.7
        PredefinedMetricSpecification:
          PredefinedMetricType: LambdaProvisionedConcurrencyUtilization

  # Scheduled scale-up at 8AM:
  MorningScale:
    Type: AWS::ApplicationAutoScaling::ScheduledAction
    Properties:
      Schedule: "cron(0 8 * * ? *)"
      ScalableTargetAction:
        MinCapacity: 10
        MaxCapacity: 10

Decision flowchart

# Use this decision tree:

if runtime == "java":
    try SnapStart first (free, 96% of PC benefit)
    only add PC if you need sub-200ms guaranteed
elif latency_sla_under_50ms:
    use Provisioned Concurrency + Auto Scaling
elif need_function_isolation:
    use Reserved Concurrency
elif traffic_spiky and cold_starts_are_visible:
    use Provisioned Concurrency with scheduled scaling
else:
    optimize code (lazy loading, smaller packages) before paying for PC

• ✅ SnapStart: Java 11/17/21, free, 96% of Provisioned Concurrency benefit
• ✅ Provisioned Concurrency: guaranteed warm instances for latency-critical non-Java APIs
• ✅ Reserved Concurrency: isolate functions and cap maximum parallelism
• ✅ Always add Application Auto Scaling to Provisioned Concurrency — never run static PC
• ❌ Never pay for Provisioned Concurrency without measuring cold start frequency first
• ❌ Reserved Concurrency set too low causes throttling — monitor ConcurrencyThrottles metric

Provisioned Concurrency costs 20% less on ARM64 Graviton3 — always combine them. For Java, always try SnapStart before paying for Provisioned Concurrency. Monitor cold start frequency with the CloudWatch Insights cold start query to justify the spend. Official reference: Lambda Provisioned Concurrency documentation.