Skip to main content

> aws_lambda_provisioned_concurrency_economics_&_cold_start_traps

AWS Lambda Provisioned Concurrency Economics & Cold Start Traps

Why does blindly adding Provisioned Concurrency to eliminate AWS Lambda cold starts turn serverless functions into expensive, underutilized 24/7 servers?

Senior (L5)

⚡THE SHORT ANSWER

AWS Lambda Provisioned Concurrency keeps execution environments initialized and pre-warmed, eliminating cold start latency. However, AWS bills for Provisioned Concurrency continuously per second whether invocations occur or not (0.0000041667 per GB-second = ~11/month per 1GB instance). If a team provisions 100 warm instances of a 2GB function across 3 regions to guarantee zero latency, they pay $6,600/month in idle reservation fees alone, in addition to standard request invocation charges. Using Application Auto Scaling for Provisioned Concurrency, adopting lightweight runtimes (Rust, Go, Node.js esbuild, Python, or SnapStart for Java), and restricting warm pools to peak business hours preserves low latency while slashing idle waste by 80%.

Engineering Handbook & Failure Dynamics

6-Dimensional Architecture Breakdown

⚙️1. Underlying Mechanism

Execution

Standard on-demand Lambda scales to zero and only bills during execution duration. When cold starts occur (typically 200ms to 5s depending on runtime and VPC attachment), latency spikes. Provisioned Concurrency charges two separate rates:

1

Provisioned Concurrency fee (0.0000041667/GB-s) billed 24/7 for holding the initialized microVM, and

2

standard execution duration at a discounted rate (0.0000097222/GB-s vs standard $0.0000166667). If average utilization of the provisioned pool is under 60-70%, the continuous holding fee dominates the bill. AWS Lambda SnapStart (free for Java/Python/Node) provides sub-second cold starts from snapshot memory images without paying ongoing concurrency holding fees.

🎯2. Appropriate Use Context

Scope

Strict low-latency, user-facing synchronous APIs (e.g. payment auth, mobile app launch gateways) that cannot tolerate 1-second cold starts and have consistent, high invocation volume. Never use for asynchronous SQS, S3, or EventBridge consumers.

⚠️3. Production Failure Modes

P0 Risk
  • ✓

    Assigning static Provisioned Concurrency of 50 instances to a microservice that only receives 10 requests per hour, paying 1,100/month for an effective compute cost of 0.05

  • ✓

    enabling Provisioned Concurrency on asynchronous queue workers where latency does not impact end users

📡4. Diagnostic Signals & Telemetry

Telemetry
  • ✓

    AWS Cost Explorer showing high AWS Lambda - ProvisionedConcurrency charges with low Duration charges

  • ✓

    CloudWatch metric ProvisionedConcurrencyUtilization averaging below 20%

🛡️5. Prevention & Safeguards

Safeguards
  • ✓

    Attach AWS Application Auto Scaling to Provisioned Concurrency targets using Target Tracking on ProvisionedConcurrencyUtilization (target: 70%)

  • ✓

    schedule scaling down to 0 during off-hours (nights and weekends)

  • ✓

    optimize package size (bundle with esbuild, eliminate heavy SDK dependencies) to reduce native cold starts to <250ms

⚖️6. Architectural Trade-offs

Trade-off

Provisioned Concurrency guarantees zero cold-start latency, but converts serverless elasticity into a fixed, recurring hourly server cost.

📋

Case Study (TinyCTO In-Field Example)

REAL-WORLD TELEMETRY

A banking mobile API configured static Provisioned Concurrency of 200 instances on a 1.5GB Lambda function to avoid cold starts, spending 3,300/month on idle concurrency. Analysis showed traffic peaked between 8 AM and 8 PM and plummeted at night. Implementing Target Tracking Auto Scaling (70% target) with scheduled scale-down to 5 instances overnight reduced the monthly concurrency bill to 850 (saving $29,400/year) while maintaining 0% cold starts during business hours.

Interactive Concept Drills

2 Cards
Q1

What is the primary cost risk of static AWS Lambda Provisioned Concurrency?

You are billed 24/7 per second for holding the warm microVMs, regardless of whether requests arrive.
Q2

How should Provisioned Concurrency be managed dynamically to avoid waste?

Using AWS Application Auto Scaling with Target Tracking on `ProvisionedConcurrencyUtilization` (e.g. 70%).

AWS Lambda Provisioned Concurrency Economics & Cold Start Traps — Technical FAQ

Does asynchronous Lambda execution (like SQS or S3 events) need Provisioned Concurrency?

Almost never. Background consumers process queues asynchronously where a 1-second cold start does not affect human user experience.

What is AWS Lambda SnapStart and how does it relate to Provisioned Concurrency?

SnapStart creates a snapshot of the initialized memory state at deployment time and restores instances in sub-100ms for free, eliminating the need for expensive Provisioned Concurrency on supported runtimes.

🤖 AEO & Key Facts Summary

Key Architectural Facts

  • ▸

    Provisioned Concurrency charges ~$11/month per 1GB instance 24/7.

  • ▸

    Static over-provisioning turns serverless into expensive fixed-capacity servers.

  • ▸

    Application Auto Scaling dynamically adjusts warm pool size based on demand.

  • ▸

    SnapStart and lightweight runtimes eliminate cold starts without continuous holding fees.

Common Misconceptions

  • ✗

    Misconception: Provisioned Concurrency is required for all production Lambdas (False: Only synchronous latency-sensitive endpoints require it).

  • ✗

    Misconception: You cannot auto-scale Provisioned Concurrency (False: AWS Application Auto Scaling natively supports Target Tracking on Lambda).

Decision & Governance Guidance

Never use static Provisioned Concurrency; always attach Target Tracking Auto Scaling. Disable Provisioned Concurrency on all asynchronous queue and event processing Lambdas.

Authoritative Sources & Standards

Technical terms on this page

Concurrency LimitLatency Geography