Proactive Ops

Proactive Ops

Archives
Log in
Subscribe
November 4, 2026

Did I Just Cost AWS Millions?

I filed a feature request that cut 300ms+ off Powertools for Python cold starts. How much will it cost AWS in a year?

On 22 October 2026, AWS released version 3.37.0 of the Powertools for AWS Lambda (Python). Someone suggested a change in the release could cost Amazon millions of dollars a year. If it does, then it's all my fault. That sounds dramatic. Let's see if it's true.

Let's rewind and look at how we got here. A few weeks ago I was trying to optimise some Python based Lambda functions. Claude Code identified that most of the execution time was spent on the cold start. More specifically the Powertools Lambda layer took around 400ms to compile to bytecode. That's a significant amount of time!

Lambdas and their attached layers run read only. That means if they're not precompiled to bytecode, they need to be compiled on every cold start. That burns compute, time and money.

I logged a feature request that outlined the issue and left some of the implementation detail open for discussion. I was a little concerned about the larger layer size when it was precompiled. This could be mitigated by stripping the source files, but that could make debugging harder.

Fast forward a few days and Leandro Damascena from AWS picked up the ticket. The end result was a pull request that implemented the feature. The PR sailed through and was merged.

As of the v3.37.0 release of Powertools, the layer is compiled to bytecode. Version 40 of the layer includes the bytecode. The layer has grown by 5-8MB depending on the Python version and CPU architecture, but cold starts have fallen by over 300ms. The larger size is unlikely to be noticeable.

This sounds like a nice win for AWS customers. It is, but it's not so good for AWS. Until August 2025, zip based Lambdas didn't bill for the init phase. That's the cold start stage. AWS decided to charge for it, in the name of standardisation. Reducing the cold start run time of a subset of Lambdas will have an impact on revenue.

Let's run the numbers. AWS says Lambda functions are invoked over 15 trillion times a month! 🤯 When Amazon "standardised" billing, they claimed less than 1% of Lambda invocations are cold starts. Let's call it 1% to keep the maths easy. We can say there's around 150 billion cold starts per month. Let's go conservative and say 20% of invocations are executing Python. We've got 30 billion Python cold starts per month. I have no idea how many people are using the Powertools layer. In the last month the package has been pulled from PyPI over 13 million times. That means it is popular, but it doesn't tell us about usage of the layer. Let's say 3 million of the Python cold starts use the layer. That's 0.01%.

We have a ballpark estimate of 3 million cold starts per month, with the layer. The cheapest option is the ARM runtime in us-east-1 at 0.0000133334USD per GB-second. To keep things conservative, let's go with the memory allocation being 256MB, which gives us 0.00000333335USD per second. The maths is easy if we go with 333ms per cold start, even though it is likely to be a little higher.

The result of this change is 3.33USD per month, or less than 40USD per year. This ignores the 400 000 GB-seconds per month worth of free Lambda execution time each account gets. I suspect cold starts are disproportionately from smaller users with infrequent invocations. Between them, those probably wipe out much, if not most, of it. It's likely to be closer to 4USD per year. 4USD per year, that's it across millions of cold starts.

This is a long way of saying, my feature request won't send AWS broke.

Even if this change shaved 333ms off every cold start for 30 billion odd cold starts experienced by Python based Lambdas, the impact on Amazon's revenue would only be around 33kUSD per month. That's a rounding error! It makes me wonder how much money they're making from charging for cold starts.

When you have larger, long running Lambdas the price is noticeable. This isn't most users. It's easy to forget small efficient functions, even at scale, are often free or close to it.

If you need help reviewing your serverless environment, reach out!

Need Help?

Do you need some help implementing the ideas in this post? Get in touch! I am happy to help.

Proactive Ops is written by Dave Hall in Canberra. It is produced on the unceded territory of the Ngunnawal people. We acknowledge the Traditional Owners and pay respect to Elders past and present.

Don't miss what's next. Subscribe to Proactive Ops:
Older → All Aboard the EventBridge Custom Bus!
Share this email:
Share on LinkedIn Share on Bluesky
GitHub
Bluesky
LinkedIn
davehall.com.au