AWS Lambda Cold Starts: Real-World Cost Optimization

Note on AI usage: this blog post was initially sent in a conversation format to a friend through Signal and converted into a blog post by Claude Opus 4. The content of it was created by myself, though the wording and the blog post format is by Claude. If this doesn’t work for you, you’re free to skip it.

When working with serverless architectures, one of the key performance considerations is the cold start problem. I'll share a practical example from a housekeeping Lambda function that revealed some useful insights about balancing performance and cost in AWS Lambda.

The Setup: A Simple Housekeeping Function

I recently implemented a Lambda function that performs routine housekeeping tasks in our system. I configured it to run every 3 minutes using Amazon EventBridge (formerly CloudWatch Events). The function is configured with minimal resources - just 128 MB of memory - since the task is relatively lightweight.

Measuring Cold Start vs Warm Start Performance

After deploying the function, I collected performance metrics from CloudWatch Logs. The results showed a significant difference:

Cold Start Performance:

REPORT RequestId: 09684470-a709-4e0a-9bbf-e6b5fa67b808 
Duration: 2304.58 ms 
Billed Duration: 2305 ms 
Memory Size: 128 MB 
Max Memory Used: 104 MB 
Init Duration: 702.59 ms

Warm Start Performance:

REPORT RequestId: 09684472-c309-4e0a-9bbf-e6b5fa67b808 
Duration: 69.60 ms 
Billed Duration: 70 ms 
Memory Size: 128 MB 
Max Memory Used: 104 MB

The difference is notable: cold starts take approximately 2,300ms, while warm starts complete in just 70ms. That's a 33x performance difference.

The Bimodal Nature of Lambda Scheduling

This performance characteristic creates an interesting optimization problem. AWS Lambda keeps functions "warm" (ready to execute without initialization) for a limited time after execution - typically around 3-5 minutes, though this isn't guaranteed.

This means we have two distinct scheduling strategies:

1. Frequent Execution (Every 3 minutes): The function stays warm, executing in 70ms each time

2. Infrequent Execution (Every 1-2 hours): The function experiences a cold start each time, taking 2,300ms

Here's the interesting part: from a billing perspective, running the function 33 times with warm starts costs roughly the same as running it once with a cold start (2,300ms ÷ 70ms ≈ 33).

The Cost Analysis

Let's break down the actual costs for running this function every 3 minutes:

Monthly execution count:

• 30 days × 24 hours × 20 executions per hour = 14,400 executions per month

AWS Lambda Pricing (outside free tier):

• Compute: $0.0000133334 per GB-second

• Requests: $0.20 per million requests

Monthly cost calculation:

For compute charges:

14,400 executions × 70ms × (1s/1000ms) × 128MB × (1GB/1024MB) × $0.0000133334/GB-s 
= $0.00168 per month

For request charges:

14,400 × $0.20/1,000,000 
= $0.00288 per month

Total monthly cost: $0.00456

That's less than half a cent per month for 14,400 executions.

Key Takeaways and Optimization Strategies

The analysis reveals a fundamental characteristic of Lambda scheduling that has direct implications for cost optimization:

1. Lambda execution is bimodal: You essentially have two choices - run your function frequently enough to keep it warm (every ~3 minutes), or accept cold starts and run it infrequently. There's no middle ground that makes economic sense.

2. Cost equivalence between strategies: Due to the 33x performance difference between cold and warm starts, running a function every 3 minutes with warm starts costs approximately the same as running it every 1.6 hours with cold starts. This creates an interesting economic equivalence where you can choose based on your needs rather than cost.

3. The intermediate interval trap: The worst possible choice is to schedule your function at intermediate intervals like 15 minutes. At this frequency, the function will have gone cold between executions, so you're paying for cold starts on every run while still executing frequently. You get neither the benefit of warm execution nor the reduced frequency of accepting cold starts.

4. Practical scheduling decisions: Given this bimodal nature, your scheduling strategy should be binary:

   • If you need consistent low latency: Schedule every 2-3 minutes to maintain warm state

   • If latency isn't critical: Schedule every 1-2+ hours and accept cold starts

   • Never schedule in the 5-30 minute range unless you have a specific reason

The mathematics here are straightforward but the implications are significant. Understanding that Lambda pricing creates these two distinct optimal operating modes allows you to make informed decisions rather than picking arbitrary intervals that might seem reasonable but are actually inefficient.

Conclusion

This real-world example demonstrates a counterintuitive truth about AWS Lambda: there are really only two cost-effective ways to schedule your functions. The 33x performance difference between cold and warm starts creates a bimodal optimization landscape where intermediate scheduling intervals are economically inefficient.

The math reveals that running a function every 3 minutes (warm) costs the same as running it every 1.6 hours (cold). This cost equivalence means you should make a binary choice: either commit to keeping your function warm with frequent executions, or space them far enough apart to justify the cold start overhead. Anything in between - like the seemingly reasonable 15-minute interval - gives you the worst of both worlds.

For this housekeeping function, I chose to run it every 3 minutes to keep it warm. The decision was easy for several reasons:

First, at less than half a cent per month for 14,400 executions, the cost is negligible. But more importantly, running the housekeeping task frequently provides significant operational benefits. The more often I run it, the less work accumulates between runs, which means each execution processes fewer items. This distributes the database load more evenly throughout the day instead of creating periodic spikes. Since the task syncs user data, more frequent runs also mean users see more consistent, up-to-date information across the system.

The lesson here goes beyond simple cost optimization. Understanding the bimodal nature of Lambda execution helps you see that sometimes what appears to be "over-scheduling" is actually the optimal choice when you consider the full system impact. When the economics make frequent and infrequent execution equivalent in cost, you're free to choose based on what benefits your application and users the most.