How does Lambda handle host resource usage (RAM/disk/network) when scaling concurrency with large container images (~1GB)?

Hola,

I agree with the other answers here: AWS doesn't really publish the host-level details for this. You can find docs on Lambda concurrency and scaling. Still, not on things like host placement, exactly how image cache is shared across hosts, or a formula like "a 1 GB image means fewer execution environments per host." That's probably by design. Lambda is a managed service, so AWS can keep changing its internals without forcing customers to design around them.

That said, I wouldn't think of a 100-concurrency burst as "Lambda pulls the full 1 GB image 100 separate times." As Brettski-AWS mentioned, Marc Brooker's "On-Demand Container Loading in AWS Lambda" paper is probably the best public explanation of what's going on under the hood: https://www.usenix.org/conference/atc23/presentation/brooker

There's also an arXiv copy here: https://arxiv.org/abs/2305.13162

The important idea from that paper is that Lambda doesn't treat container startup like a normal Docker host pulling and unpacking a whole image before anything can run. The image is turned into a block-device-style filesystem, split into chunks, and loaded on demand as the function actually reads those parts of the image. Those chunks can come from cache close to the worker, a wider AZ-level cache, or S3 behind the scenes.

So, for the image-loading question, I'd answer: probably not independent full-image pulls in the usual container sense. Each concurrent invocation still runs in its own execution environment, so each can read from its own mounted filesystem. But that doesn't mean each microVM has to download the entire image or pull every layer by itself. The published design is built around lazy loading and cache reuse.

For the host bottleneck question, I don't think there's a public answer like "RAM is always first" or "network is always first." From the customer side, the meaningful controls are still the normal Lambda controls: memory size, ephemeral storage, reserved concurrency, provisioned concurrency, account concurrency limits, the function scaling rate, and what your code actually does during init and invoke.

AWS documents Lambda scaling behavior here: https://docs.aws.amazon.com/lambda/latest/dg/scaling-behavior.html

At the time I'm writing this, Lambda documents that a function can scale by up to 1,000 new execution environments every 10 seconds, subject to account concurrency and other limits.

AWS documents Lambda memory configuration here: https://docs.aws.amazon.com/lambda/latest/dg/configuration-memory.html

Memory is still important because each concurrent request needs its own execution environment, and Lambda allocates CPU in proportion to the configured memory. But image size and runtime memory use are different things. A 1 GB image can run fine in a 512 MB function if the running process only needs that much memory. A much smaller image can still run out of memory if the app loads a lot into RAM.

For cold starts, I also wouldn't assume "twice the image size means twice the cold start," especially with Lambda's on-demand loading model. What matters more is what your function touches during startup. If your init path only needs a small part of the image, a large image may not hurt as much as you'd expect. If your app imports a large dependency tree, scans files, loads models, or reads many assets during init, then the image contents can absolutely affect cold start time.

The practical things I'd check are:

• Keep the init path small. Don't load large models, dependency trees, font packs, static assets, or other bulky files during init unless every invocation needs them immediately.
• Use AWS Lambda base images where possible, since common base content is more likely to benefit from Lambda's optimizations and caching.
• Put the code that changes most often toward the end of the Dockerfile so you don't keep invalidating large base layers on every build.
• During burst testing, watch Init Duration, total duration, Max Memory Used, throttles, and concurrency. Those numbers will tell you more than image size alone.
• If you're seeing a real production bottleneck, open an AWS Support case with the image size, memory setting, init duration, concurrency target, burst-test results, and any throttling or errors. They can examine service-side behavior that public docs don't expose.
• If you need predictable control over host placement, local disk behavior, image pull behavior, or instance sizing, Lambda may not be the right abstraction. ECS, EKS, or Fargate will give you more control over those details.

Lambda's design shouldn't treat each concurrent execution as a full image pull, but AWS doesn't expose enough host-level details to predict the exact RAM, disk, or network bottleneck from image size alone. I'd use the Brooker paper to understand the design, but I wouldn't treat it as a customer-facing service contract.

Thanks,

James

Based on the available documentation, Lambda's scaling behavior focuses on concurrency limits and scaling rates rather than the specific host-level resource mechanics you're asking about. Here's what is documented:

Concurrency Scaling Behavior: Lambda scales by allocating execution environments at a rate of up to 1,000 additional execution environment instances every 10 seconds (or 10,000 requests per second every 10 seconds) per function. This scaling rate is a function-level limit, meaning each function scales independently. When your function receives increasing requests, Lambda scales at the fastest rate available up to your account's concurrency limit. If requests arrive faster than your function can scale or if maximum concurrency is reached, additional requests fail with a throttling error (429 status code).

Execution Environment Behavior: When you first invoke a function, Lambda creates an instance of the function and runs its handler. When the function returns a response, it stays active to process additional events. If you invoke the function again while the first event is being processed, Lambda initializes another instance, allowing concurrent processing. As more events arrive, Lambda routes them to available instances and creates new instances as needed.

What's Not Documented: The specific questions you're asking about—image layer caching mechanisms across concurrent microVMs on the same host, per-host capacity bottlenecks related to image size, and whether cold start latency scales linearly with image size under burst load—are not covered in the available public documentation. These implementation details about host-level resource sharing, disk I/O patterns for container image layers, and the internal architecture of how Lambda manages container images across concurrent executions are not publicly disclosed.

For workloads requiring specific control over compute resources and scaling behavior, you might want to explore Lambda Managed Instances, which allows you to select specific EC2 instance types and provides more visibility into resource utilization through CloudWatch metrics at both the function and capacity provider levels. However, this still doesn't expose the low-level image caching mechanics you're asking about.

I'd recommend reaching out through the AWS Support Center if you need architecture guidance specific to your use case with large container images under high concurrency.
Sources
Understanding Lambda function scaling - AWS Lambda
Lambda scaling behavior - AWS Lambda
Elastic - Reactive Systems on AWS
re:Invent 2025 - Lambda Managed Instances: EC2 Power with Serverless Simplicity | AWS re:Post

The re:Post Agent answer is good and for a lot of the stuff you're asking (as that answer says) there is no documentation. That allows AWS to change the implementation details and improve how the service is delivered. Lambda is a managed service - it's a vast abstraction of compute (in general) so all of those things are "taken care of".

That said, you might want to look at this paper and talk from Marc Brooker where he talks about how Lambda delivers large container images quickly and at scale.

If you are experiencing issues then I'd suggest a support case is the way to go. If you want more control over how the underlying host environment is set up, then ECS or Fargate are good choices.