Explanation
Why the waste happens and who it affects.
For Python and .NET functions, high-traffic workloads can trigger frequent snapshot restorations, multiplying costs. Slow initialization code inflates the Init phase, which is billed as normal duration. Leaving many published SnapStart versions active adds further cost, because Python and .NET functions pay a caching charge for every active version, and both caching and restore charges scale with configured memory. Together, these factors can cause SnapStart to deliver higher spend without proportional benefit.
Billing model
The pricing dimensions that drive this cost.
Lambda charges are based on requests and execution duration, multiplied by allocated memory. SnapStart introduces additional billing factors:
- Snapshot caching
- For Python and .NET, each function version published with SnapStart enabled incurs a cache charge per GB-second for as long as the version remains active, with a 3-hour minimum. Java managed runtimes have no additional SnapStart charge.
- Snapshot restorations
- For Python and .NET, each time a function instance is restored from a snapshot, a restore charge is incurred based on memory size.
- Init phase billing
- Initialization code runs when a version is published, and again whenever Lambda re-runs it to apply runtime and security updates to snapshots, and is billed as normal duration.
How to detect
4 checks to find it in your estate.
- Review whether frequent traffic bursts are driving high restoration activity and associated costs
- Evaluate whether function initialization logic is lengthy, leading to increased charges in the Init phase
- Identify published SnapStart-enabled versions that are no longer invoked but still incur caching charges
- Assess whether SnapStart is delivering latency improvements that justify its incremental costs
How to fix
5 ways to remove the waste.
- Implement concurrency controls to reduce excess restorations during high traffic bursts
- Optimize function initialization to minimize Init phase duration by loading only essential dependencies
- Use runtime hooks (supported for Java, Python, and .NET) to prepare code before the snapshot is taken or re-initialize state after restore
- Delete unused SnapStart-enabled function versions, since for Python and .NET each active version keeps incurring caching charges
- Right-size memory allocation, since SnapStart caching and restore charges both depend on the memory configured for the function
Documentation
Vendor references for pricing and configuration.