● Covered by 1 source · 2 reportsMedium impact2 neutral
AWS Lambda SnapStart Now Supports Container Images, Addressing Startup Latency
Key points
- Lambda SnapStart now supports container image functions.
- Container images allow up to 10 GB, compared to 250 MB for zip archives.
- SnapStart reduces startup times to sub-second by resuming from a cached snapshot.
- This removes a trade-off for functions with large dependencies.
- Lambda functions on Managed Instances now support a 90-minute runtime limit.
- The previous runtime limit was 15 minutes.
- The runtime limit for traditional synchronous requests remains unchanged.
- Lambda's timeout increased from 5 minutes in 2014 to 15 minutes in 2018.
SnapStart Extended to Container Images
AWS has announced that Lambda SnapStart is now available for functions packaged as container images. Previously, SnapStart was limited to managed runtimes for Python, .NET, and Java. This expansion addresses a significant trade-off faced by developers using Lambda.
Addressing Packaging Limitations
Functions packaged as container images can be up to 10 GB in size, offering a substantial increase over the 250 MB limit for zip archives. However, until this update, choosing container images meant foregoing SnapStart, leading to startup times of several seconds while the Lambda environment initialized. SnapStart works by taking a snapshot of the initialized execution environment at deployment and resuming from it upon invocation, resulting in sub-second startup times.
Impact on Dependency Management
This change is particularly relevant for applications with heavy dependencies, such as those using libraries like pandas and numpy. Developers previously had to choose between the larger size capacity of container images and the faster startup times provided by SnapStart. The update removes this constraint, allowing developers to use container images for large dependencies without incurring a cold start penalty.
Developer Feedback and Previous Workarounds
The challenge of balancing dependency size and startup performance was evident in developer discussions, where teams resorted to stripping whitespace and docstrings from code to stay within the 250 MB zip archive limit. Alternative solutions, such as mounting EFS access points, were also considered to manage large libraries while retaining SnapStart. The new support for SnapStart in container images simplifies this decision for developers.
Updates
- Lambda functions on Managed Instances now support a 90-minute runtime limit.
- The previous runtime limit was 15 minutes.
- The runtime limit for traditional synchronous requests remains unchanged.
- Lambda's timeout increased from 5 minutes in 2014 to 15 minutes in 2018.
✨ This summary was generated by AI from the outlets' reporting listed below. It is not independently verified and may contain errors — check the original sources. How BrevFeed works →
The daily brief
One email each morning: the day's tech stories, clustered across outlets and summarized. No account needed.
One email a day. Unsubscribe in one click, any time.
Today's brief
Spend a few minutes, get the whole day. Every topic's top stories in one hands-free rundown — listen, watch, or read the transcript.
▶ Play today's brief
New every morning, and the back catalogue is archived by date.
Primary sources
GitHub serverless/serverlessHow outlets covered it
AWS Lambda now supports a 90-minute runtime limit for functions on Managed Instances, a six-fold increase from the previous 15-minute limit. This change allows Lambda to handle longer-running workloads like media processing, financial calculations, and AI inference without workarounds.
AWS has extended Lambda SnapStart functionality to functions packaged as container images, which previously only supported managed runtimes. This change eliminates the startup latency penalty for Lambda functions that use container images to accommodate large dependencies, allowing them to achieve sub-second cold start times.