Why AWS Lambda Container Images Time Out After a New ECR Deploy and How to Prevent Cold Starts

Learn why AWS Lambda container images time out after a new ECR push: cold starts, image pulls, heavy init. Get fixes: proper timeouts, smaller images, warmups.

When a container-based AWS Lambda suddenly starts timing out right after you push a new ECR image, it’s tempting to blame configuration or code regressions. Yet the root cause can be far more mundane: the platform is busy pulling and bootstrapping your fresh image, and your invocation simply runs out of time.

What the failure looks like

Consider the following invocation trace. The function has a 300-second timeout, and nothing appears in the application logs before the platform kills the run.

2025-07-14T08:51:28.206+09:00 START RequestId: 24e982ca-5161-4f02-82d7-0bd94d289fc5 Version: $LATEST

2025-07-14T08:56:28.255+09:00 2025-07-13T23:56:28.254Z 24e982ca-5161-4f02-82d7-0bd94d289fc5 Task timed out after 300.05 seconds

2025-07-14T08:56:28.255+09:00 END RequestId: 24e982ca-5161-4f02-82d7-0bd94d289fc5

2025-07-14T08:56:28.255+09:00 REPORT RequestId: 24e982ca-5161-4f02-82d7-0bd94d289fc5 Duration: 300048.73 ms Billed Duration: 301192 ms Memory Size: 128 MB Max Memory Used: 119 MB Init Duration: 1191.06 ms

The error points to a timeout, not a memory exhaustion issue. The default Lambda timeout is 3 seconds, so this configuration has already been increased to 300 seconds.

Why this happens after deploying a new ECR image

Updating the container image invalidates the previous code. When the next invocation arrives, the Lambda service places your function on an arbitrary host in the platform. That host has no prior knowledge of your just-pushed image, so it must pull it in full from ECR, without relying on any layer cache. Only after the download completes does the runtime launch your image. If your image or application performs heavy startup work—such as fetching dependencies or initializing a JVM—those tasks run before your handler sees the event. The function becomes ready only after all of that completes.

All invocations until the first Lambda instance is running will all be delayed by cold start behavior.

This entire sequence is the classic cold start path for container images. If it takes longer than your configured timeout, the service terminates the attempt with a 300-second timeout error. AWS documents this cold start latency and the associated messages in its Lambda runtime environment docs, and similar scenarios are discussed in community answers such as this and this. Official guidance on cold start latency is available here.

What to do about it

There are several viable levers to reduce the impact. You can increase the timeout if your workload tolerates it. You can reduce image size so pulls from ECR complete faster. You can decrease startup-time work inside the image by trimming dependencies or simplifying initialization. You can also consider changing language to one with faster startup in your context. Once the image has been pulled and an instance is warm, subsequent invocations should execute normally, and the first few invocations may time out and be retried until the image is cached on the host. If you deploy a new image, the cycle repeats because the previous image is invalidated.

In one reported case, invoking the function every 10 minutes prevented the problem from recurring, which aligns with the idea that regularly exercised functions avoid extended cold starts while they remain warm.

Why this matters for engineering teams

Container image Lambdas give you packaging control, but they shift some cold start costs onto the first invocations after deployment. If a critical path relies on immediate responsiveness right after a release, a long image pull or heavyweight initialization can turn into user-visible timeouts. Understanding that the platform may need to download your image and run one-time startup tasks before handling events helps you plan safe timeouts, sensible image sizes, and acceptable warm-up behavior.

Takeaways

If you observe 300-second timeouts immediately after publishing a new container image to ECR and updating a Lambda, assume cold start behavior rather than a memory constraint. Keep timeouts appropriate for image pulls and startup work, streamline the container and its initialization, and expect that the very first invocations after a fresh image push can be delayed or retried until the image is cached. If continuous availability is required immediately post-deploy, account for this window in your release and traffic strategies. For deeper background, review the AWS documentation on cold start latency and the referenced explanations.