Which invocation frequency makes Provisioned Concurrency cost‑effective for sporadic Lambda traffic?

Question

Goal
Determine the break‑even invocation rate for a low‑traffic Lambda function where Provisioned Concurrency (PC) becomes cheaper than on‑demand execution, taking into account current pricing, cold‑start penalties, and ARM‑based Graviton2 cost reductions.
Constraints

Invocations < 100 per day, highly irregular.
Function memory 512 MB, Java 11 runtime.
Cold‑start latency 50–500 ms.
On‑demand pricing: $0.20 per 1 M requests + $0.00001667 per GB‑ms.
PC pricing: $0.0000041667 per GB‑hour per instance + $0.20 per 1 M requests.
Graviton2 reduces per‑ms cost by ~20% and cold‑start times by ~30 %.

Uncertainty
There is no official calculator that maps these numbers to a specific invocation frequency threshold, and SnapStart may alter the trade‑off but is not supported with PC.
Questions

At what daily invocation count does Provisioned Concurrency become cheaper than on‑demand for a 512 MB Java 11 function on Graviton2, given the current pricing and typical cold‑start latency?
Does enabling SnapStart for the same function shift this break‑even point, and if so, by how much?
Can AWS Compute Optimizer provide a reliable estimate of the break‑even invocation rate for sporadic traffic, or is manual benchmarking required?

Tasadduq Burney · Answer

Break-even first
With the pricing you listed and a single provisioned instance, Provisioned Concurrency is cheaper than on-demand for essentially any non-zero traffic on a 512 MB function. The daily fixed PC cost is 0.5 GB × 24 h × $0.0000041667/GB-hour ≈ $0.00005 per day plus $0.20 per 1 M requests. On-demand cost is per invocation: 0.5 GB × (execution ms + cold-start ms) × $0.00001667/GB-ms, with Graviton2 reducing the per-ms rate ~20% and cold-start ~30% in your assumptions.
Even a very short Java 11 invocation accrues more than $0.00005 in compute once cold-start is included. The model therefore shows a crossover at ~1 invocation per day for a single reserved instance. If you must reserve a minimum concurrency quota, e.g. ≥5 instances, the daily fixed cost is ~$0.00025. That raises the practical break-even to roughly 5–10 invocations per day depending on execution length.
Confirmed facts vs model assumptions
Confirmed: Provisioned Concurrency charges per GB-hour for the reserved capacity and the same $0.20 per 1 M requests as on-demand. SnapStart is not supported with Provisioned Concurrency, so enabling SnapStart cannot be combined with PC and does not shift the PC cost model.
Likely, not confirmed: the ~1 invocation per day crossover depends on execution duration and the actual cold-start you observe. The research brief treats Graviton2 as ~20% cheaper per ms and ~30% faster cold-start. Those are directional assumptions, not measured for your function. AWS pricing and minimum concurrency quotas can change, and PC often has a minimum reservation that makes the fixed cost higher than the single-instance math.
Steps to verify for this case

Compute daily PC cost: 0.5 × 24 × 0.0000041667 + invocations/1_000_000 × 0.20.
Compute daily on-demand cost: invocations × 0.5 × (avg_execution_ms + avg_cold_ms) × 0.00001667 × 0.8 for Graviton2.
Compare the two values across your observed invocation count range <100 per day.
Check the Lambda console Cost Explorer with Provisioned Concurrency selected and input your invocation count and average duration to view the cost breakdown.

One missing diagnostic that changes the recommendation
Average warm execution duration in ms for your Java 11 function. Break-even is highly sensitive to execution time, not just cold-start. Provide the measured p50/p95 execution duration and the actual reserved concurrency you can configure.
SnapStart and Compute Optimizer
SnapStart is not compatible with Provisioned Concurrency. Enabling SnapStart for the same function does not shift the PC break-even point, and cold-start reductions from SnapStart cannot be counted in the PC cost model.
AWS Compute Optimizer does not provide a reliable invocation-rate break-even for sporadic Lambda traffic. It can flag over-provisioned concurrency, but manual benchmarking of duration and cold-start is required for a cost decision at <100 invocations per day.

Which invocation frequency makes Provisioned Concurrency cost‑effective for sporadic Lambda traffic?

Goal

Constraints

Uncertainty

Questions

1 answer

Break-even first

Confirmed facts vs model assumptions

Steps to verify for this case

One missing diagnostic that changes the recommendation

SnapStart and Compute Optimizer

Your perspective belongs here.

0 question comments