AWS SOCI lazy loading cuts container startup times for Lambda Managed Instances by up to 70%

AWS has added lazy loading for container images on Lambda Managed Instances, a capability it announced on October 28, 2026 and says can shorten function startup times by up to 70 percent. A hands-on walkthrough published on dev.to explains how the mechanism works and, just as usefully, where its rough edges are.

How the lazy loading works

The feature builds on SOCI, short for Seekable OCI, an open-source AWS project licensed under Apache-2.0. SOCI does not modify your image. Instead it generates a companion index that records, for every file, which layer it sits in and at what offset. With that index available, Lambda retrieves single files from ECR on demand instead of downloading and unpacking the entire image before an execution environment can start.

Operationally, you push the image and the SOCI index to ECR together under a dedicated tag. That tag points to an image index holding exactly two entries: the ordinary image manifest and the SOCI index. Point the function at that tag, and Lambda enables lazy loading automatically when you publish the version, with no further configuration, according to the dev.to article.

The format requirements are strict, though. Lambda accepts only a SOCI index v2, inside an image index with exactly two entries, and supports single-architecture images only. Building the index requires the SOCI snapshotter, a containerd extension typically driven through nerdctl, which the article says needs a Linux machine with containerd.

When it pays off

Container images are a common route for shipping Lambda payloads that exceed the roughly 250 MB ZIP package limit: machine learning libraries, models, PDF tooling, entire runtimes. Those images routinely reach several gigabytes. On Managed Instances, the full image has to be downloaded and unpacked on every new instance, not just at publish time but also whenever the capacity provider adds instances as load rises.

Much of that data is never read. The dev.to example is built around exactly that pattern: a book recommendation service whose image carries language models for German, English, French and Spanish, while each invocation touches only one of them. Lazy loading pays off most for large images where each function needs only a slice of the contents.

The init-phase caveat

Files your initialization code reads are fetched during initialization. Anything first touched inside the handler is pulled in during the invocation itself, making that request correspondingly slower. The article notes, citing AWS documentation, that Lambda never downloads the remainder of the image in the background. That leads to the main coding rule: import every library and open every file in the init phase, so invocation durations stay consistent.

Where Managed Instances fit

SOCI lazy loading applies only to Lambda Managed Instances, the execution model in which functions run as containers on EC2 Nitro instances inside your own account rather than in Firecracker microVMs on the shared Lambda fleet. A capacity provider defines the VPC, subnets, security groups, architecture, permitted instance types and a vCPU ceiling. Publishing a version prompts Lambda to launch instances, three by default spread across Availability Zones, plus three execution environments before the version counts as active.

The trade-offs differ from standard Lambda in several ways, per the dev.to comparison: environments serve several concurrent invocations instead of one at a time, billing is EC2 pricing plus a 15 percent management fee, and instances do not scale to zero, which suits steady, predictable traffic better than spiky workloads. For Node.js, initialization runs once per worker thread, so a large model held in memory is duplicated per thread, and state shared by concurrent requests in the same thread must be treated as read-only.

Why it matters

Cold-start cost for large container images has been a persistent tax on Lambda workloads that depend on heavy libraries and models. Starting a function while its image is still streaming, with AWS claiming up to 70 percent faster startup, directly reduces that tax, and it matters most during scale-out events when many instances would otherwise pull the same multi-gigabyte image simultaneously. The limits are real, though: the benefit applies only to Managed Instances, a pay-for-capacity model with different pricing and scaling semantics, and the strict two-entry image index format plus the init-phase discipline make this an optimization you design for rather than a switch you flip. Teams already running high, predictable Lambda container workloads stand to gain the most.