Regarding the timeout after 300 seconds aka 5 minutes:
The default timeout for Lambdas is 3 seconds, so I guess you already adjusted this.

Without any knowledge about the container image you're building/using, I strongly suspect that the container image hits some kind of cold start situation, which exceed the 5 minutes timeout.

Found answers/explanations for similar cases here and here, although they don't match exactly.

So what's happening on AWS side when you update the image can be described like this:

• Previous code/image is invalidated

• Scheduling of the Lambda happens on an arbitrary server in the Lambda-hosting platform in AWS.

• The new server has no knowledge about the previous image, so it needs to download it in full from ECR (no layer caching).

• When the image is downloaded, it's executed. Does your image/application contain a lot of startup tasks? Like download dependencies, JVM starting, ...? All of this happens now.

• Then, finally, the Lambda is ready to serve the event that it triggered from the start.

This process takes time - and is generally described as "cold start". See this for a more detailed description in which situations cold starts can be especially annoying. TL;DR: All invocations until the first Lambda instance is running will all be delayed by cold start behavior.

AWS docs around this topic can be found here. It even describes your exact error messages.

There are different ways to approach this. You can increase timeout, reduce image size, reduce image startup dependencies, change language, and more. Probably all of them are worth a separate question...
But hopefully, I was able to explain what you are seeing and get you on the right track.