Explanation
Why the waste happens and who it affects.
When SnapStart is enabled on Python or .NET functions, each of these versions retains a cached snapshot, generating ongoing charges. Over time, accumulated unused versions can significantly increase spend without delivering any business value. This problem compounds in environments with high deployment velocity or many functions.
Billing model
The pricing dimensions that drive this cost.
For Python and .NET managed runtimes, Lambda SnapStart charges a cache fee for every published function version with SnapStart enabled. The fee depends on allocated memory, has a 3-hour minimum, and keeps accruing while the version exists, even if it is no longer invoked. Each restore from a snapshot is also charged. On Java managed runtimes SnapStart has no additional cost, and Lambda deletes a Java version's snapshot after 14 days without an invocation.
How to detect
4 checks to find it in your estate.
- Review the number of published Lambda versions with SnapStart enabled on Python and .NET runtimes across accounts
- Assess whether older versions are still being invoked or if they remain idle but cached
- Correlate Lambda costs with the number of SnapStart-enabled versions retained in each environment
- Check for environments with frequent deployments where unused versions may accumulate
How to fix
4 ways to remove the waste.
- Delete unused Lambda function versions with SnapStart enabled to eliminate unnecessary cache charges
- Implement version lifecycle management practices in CI/CD pipelines to automatically clean up old versions
- Retain only the most recent versions required for rollback or audit purposes
- Monitor the number of SnapStart-enabled versions per function and enforce limits to prevent sprawl
Documentation
Vendor references for pricing and configuration.