TL;DR
If your Lambda connects to a database or has strict latency requirements, set Provisioned Concurrency to at least match your baseline traffic. Cold starts on VPC-connected Lambdas can exceed 10 seconds—enough to timeout API Gateway requests.
The Problem
A client's payment processing API was throwing intermittent 504 timeouts. Not constantly—just enough to frustrate users and trigger alerts at 3am. The Lambda function worked perfectly in testing. Logs showed successful executions. So why the timeouts?
The culprit: cold starts on a VPC-connected Lambda running Java.
Why Cold Starts Hurt
When Lambda spins up a new execution environment, it needs time to:
- Download and extract your deployment package
- Initialize the runtime (JVM startup for Java)
- Create VPC network interfaces (ENI attachment)
- Run your initialization code
For a Python function outside a VPC, this might take 200-500ms. For a Java function inside a VPC connecting to RDS? We measured 8-12 seconds.
API Gateway's default timeout is 29 seconds, but their upstream load balancer was configured for 10 seconds. Cold starts were exceeding that threshold.
The Fix
Provisioned Concurrency keeps a specified number of execution environments warm and ready. No cold starts for requests that hit these pre-initialized instances.
# AWS CLI - set provisioned concurrency
aws lambda put-provisioned-concurrency-config \
--function-name payment-processor \
--qualifier prod \
--provisioned-concurrent-executions 10
We analyzed their CloudWatch metrics, found baseline concurrency of 5-8 during business hours, and set provisioned concurrency to 10. Cold start timeouts dropped to zero.
What It Costs
Provisioned concurrency isn't free. You pay for the provisioned capacity whether it's used or not—roughly $0.000004167 per GB-second. For a 1GB function running 10 instances 24/7, that's about $108/month.
Compare that to the cost of 3am pages, customer complaints, and engineering time debugging intermittent failures. For production workloads with latency requirements, it's usually worth it.
Pro tip: Use Application Auto Scaling to adjust provisioned concurrency based on schedule or utilization. Scale up during business hours, down overnight.
When to Use It
Consider provisioned concurrency when you have:
- VPC-connected functions (ENI attachment adds seconds)
- Java, .NET, or other heavy runtimes
- Strict latency SLAs (sub-second response requirements)
- Spiky traffic patterns that trigger frequent cold starts
- Functions that initialize database connection pools
One More Thing
Provisioned concurrency only helps with cold starts. If your function is slow because of inefficient code or downstream dependencies, warm instances won't help. Always profile first, then optimize.
