Mohammad Shaker
← Back

Disable Lambda SnapStart: $500-600/month Savings

·cost-optimization

Disable Lambda SnapStart: $500-600/month Savings

Context

AWS Lambda cold starts cause latency spikes when functions haven't been invoked recently. For our Flask application running on Lambda, cold starts added 2-3 seconds of latency while the Python runtime initialized, dependencies loaded, and the application bootstrapped. This affected approximately 1% of requests.

AWS SnapStart promised to eliminate this problem by creating snapshots of initialized Lambda functions and restoring them in under 500ms. The feature looked promising on paper, so we rolled it out across our production environment to evaluate its impact.

The Experiment

Before SnapStart:

Lambda Cold Start (Traditional)
┌──────────────────────────────────────┐
│ Request arrives                      │
│ ├─ Initialize Python runtime (1.5s)  │
│ ├─ Load dependencies (0.8s)          │
│ ├─ Initialize Flask app (0.5s)       │
│ └─ Execute request (0.2s)            │
│ Total: ~3.0s                         │
└──────────────────────────────────────┘

Impact: 1% of requests experience 3s delay
Cost: Standard Lambda pricing

After SnapStart Enabled:

Lambda Cold Start (SnapStart)
┌──────────────────────────────────────┐
│ Request arrives                      │
│ ├─ Restore snapshot (0.3s)           │
│ └─ Execute request (0.2s)            │
│ Total: ~0.5s                         │
└──────────────────────────────────────┘

Impact: 1% of requests experience 0.5s delay
Cost: Standard Lambda + SnapStart fees

The cold start improvement was real: 3 seconds reduced to 500ms, an 83% reduction. But we needed to evaluate the cost.

Cost/Benefit Analysis

After one month of production usage with SnapStart enabled, we reviewed the CloudWatch billing data:

Monthly Cost Breakdown
┌──────────────────────────────────────┐
│ Lambda Invocations:     $1,200       │
│ Lambda Duration:        $800         │
│ SnapStart Charges:      $550         │
│ Data Transfer:          $150         │
│ ────────────────────────────────     │
│ Total:                  $2,700/month │
└──────────────────────────────────────┘

The critical question: Was $550/month justified to improve 1% of requests?

Impact Analysis:

  • Total requests/month: ~50 million
  • Cold start frequency: 1% = 500,000 requests
  • Latency savings per cold start: 2.5 seconds
  • Cost per improved request: $550 ÷ 500,000 = $0.0011
  • User perception: Most users never noticed cold starts

User Impact Assessment: Our analytics showed that users experiencing cold starts didn't correlate with increased bounce rates or decreased session duration. The 99% of users experiencing warm starts (200-300ms response times) represented the majority user experience.

Furthermore, our mobile apps implement retry logic and loading states that masked the cold start delay from user perception.

The Decision

We ran the cost/benefit calculation:

Decision Matrix
┌──────────────────────────────────────┐
│ SnapStart Cost:      $550/month      │
│ Cold Start Freq:     ~1% of requests │
│ User Impact:         Minimal         │
│ Alternative:         Provisioned      │
│                      concurrency:     │
│                      $120/month       │
│ ────────────────────────────────     │
│ Decision:            DISABLE          │
└──────────────────────────────────────┘

SnapStart was solving a problem that didn't significantly affect our users. We decided to disable it and invest the $550/month savings elsewhere.

Implementation

Disabling SnapStart was straightforward:

serverless.yml changes:

# Before
functions:
  main:
    handler: src.lambda_handler.handler
    snapStart: true  # ENABLED
    memorySize: 1024
    timeout: 30

# After
functions:
  main:
    handler: src.lambda_handler.handler
    # snapStart: true  # DISABLED
    memorySize: 1024
    timeout: 30

We deployed the change during a low-traffic period and monitored CloudWatch metrics for 48 hours:

Monitoring Results:

  • Cold start frequency: Unchanged at ~1%
  • P50 latency: 210ms (no change)
  • P95 latency: 450ms (no change)
  • P99 latency: 2.8s (up from 0.5s for cold starts)
  • Error rate: 0.02% (no change)

The P99 latency increase was expected and only affected the 1% of requests experiencing cold starts. User-facing metrics showed no degradation.

Alternative Optimizations Considered

Instead of paying $550/month for SnapStart, we explored cheaper alternatives:

1. Provisioned Concurrency

Cost: $120/month for 2 instances
Benefit: Zero cold starts during peak hours
Tradeoff: Only covers 16 hours/day

We evaluated this but decided that even peak-hour cold starts weren't impacting user experience enough to justify $120/month.

2. EventBridge Warmup

Cost: $150/month for keep-alive pings
Benefit: Reduced cold start frequency
Tradeoff: Wasteful invocations

We had this running previously but disabled it as part of broader cost optimization efforts (covered in Post 8.5).

3. Lambda Consolidation

Cost: $0 (architectural change)
Benefit: Shared warm runtimes
Tradeoff: Engineering effort

We implemented this optimization separately (covered in Performance post 5.2), consolidating 4 Lambda functions into 1 thin function. This reduced cold start frequency by 75% at zero cost.

Results

Cost Savings:

  • $550/month saved by disabling SnapStart
  • $6,600/year annual savings

User Impact:

  • 99% of users: No change in experience
  • 1% of users: Additional 2.5s delay on cold starts
  • Overall user satisfaction: No measurable change

Key Learnings:

  1. Measure user impact, not just technical metrics. Cold starts were technically slow, but users didn't notice or care.
  2. Cost/benefit analysis is crucial. A 83% technical improvement isn't valuable if users don't benefit.
  3. Focus optimization budget on high-leverage areas. $550/month could fund better database optimizations affecting 100% of requests.

When SnapStart Makes Sense

SnapStart isn't a bad feature—it just wasn't right for our use case. It makes sense when:

  1. Cold starts affect >10% of requests - High cold start frequency justifies the cost
  2. Latency-sensitive applications - Sub-second response time requirements
  3. Synchronous user interactions - Direct user-facing API calls where every millisecond matters
  4. High-value transactions - E-commerce checkout, financial transactions where latency causes abandonment

For us, a content delivery platform with asynchronous operations and 99% warm starts, SnapStart was over-engineering.

Conclusion

We rolled out Lambda SnapStart, measured its impact, and made a data-driven decision to disable it. The $550/month savings were reallocated to database query optimizations that improved 100% of requests instead of 1%.

This case study demonstrates the importance of measuring real-world impact rather than chasing theoretical performance improvements. Not every AWS feature makes financial sense for every workload.

Final Metrics:

  • Cost reduction: $550/month ($6,600/year)
  • User experience: No measurable degradation
  • Decision framework: Cost/benefit analysis over technical perfection

Commits: b41f8a6, 6fa2370 Related Posts: Performance Post 5.1 (Lambda SnapStart Rollout), Cost Post 8.2 (Lambda Cost Investigation)