Provisioned Concurrency transition: balancing cost and performance for low‑traffic Lambda functions

Balancing Cold Starts and Cost

To determine the optimal Provisioned Concurrency (PC) level for low-traffic functions with occasional bursts, you should analyze the ProvisionedConcurrencyUtilization metric in Amazon CloudWatch. The goal is to set a baseline that covers your minimum expected concurrent requests while allowing Application Auto Scaling to handle the bursts.

1. Determining Optimal Concurrency Levels

Rather than guessing a static number, use a data-driven approach based on your p99 latency requirements:

• Analyze Peak Concurrency: Review the ConcurrentExecutions metric during your burst windows.
• Calculate the "Cold Start Tolerance": Determine how many requests can afford a cold start without violating your SLA. If your SLA allows 5% of requests to have higher latency, you only need to provision for the 95th percentile of concurrent traffic.
• Baseline vs. Burst: Set your minimum PC to the lowest concurrency level seen during "active" periods to ensure the most frequent users avoid cold starts, leaving the remaining burst capacity to on-demand scaling.

2. Programmatic Toggling and Scaling Patterns

Since PC is a static configuration, you cannot "toggle" it instantaneously without a propagation delay. Instead, use these two patterns:

• Scheduled Scaling: If bursts occur at predictable times (e.g., every Monday at 9 AM), use Application Auto Scaling with a scheduled action to ramp up PC 15–30 minutes before the event and scale back to zero afterward.
• Target Tracking: Implement a Target Tracking scaling policy based on ProvisionedConcurrencyUtilization. This automatically adjusts the PC count to maintain a specific utilization percentage (e.g., 70%), reducing costs during idle periods.

3. Safeguards and Monitoring

To prevent over-provisioning and ensure SLA compliance, implement the following:

• CloudWatch Alarms: Create an alarm on ProvisionedConcurrencyUtilization. If utilization stays below 10% for several hours, trigger a notification to manually lower the baseline.
• Concurrency Limits: Set a Reserved Concurrency limit on the function. This acts as a safety ceiling to prevent a recursive loop or unexpected spike from scaling PC (and costs) beyond your budget.
• Latency Tracking: Monitor the Duration metric specifically for requests that exceed the PC limit. This identifies exactly when on-demand cold starts are impacting your users.

Verification Command

You can verify and update your provisioned concurrency via the AWS CLI to test your scaling logic:

aws lambda put-provisioned-concurrency-config \
    --function-name your-function-name \
    --qualifier your-alias-or-version \
    --provisioned-concurrent-executions 5

Missing Diagnostic Detail: Are your traffic bursts predictable (time-based) or reactive (event-based)? This determines whether Scheduled Scaling or Target Tracking is the more cost-effective choice.