In December 2020, AWS released a new feature for Lambda service : Lambda now support containers images. As Danilo Poccia explain, “if you’ve invested in container tooling for your development workflows, it’s not easy to use the same approach to build applications using Lambda.”

Container image support is a all new way to design your architecture, pushing back service limits :

• If classic lambda max size is only 50 Mo, lambda with containers push it to 10 Go
• You can run your Lambda with the runtime of your choice. How sexy is a Lambda running Symfony as backend ? AWS also release a tool called Runtime Interface Emulator : to work with Lambda, your images must implement the Lambda Runtime API. You can also use AWS provided images
• Lambda workspace is no longer read-only.

This feature revolutionizes the way Docker images are executed on AWS. With this update, there is no longer a requirement for an EKS Fargate cluster. Now, you can seamlessly run Docker images on-demand without the need to consider setting up a cluster. This simplifies the process and allows for more flexibility in utilizing Docker images on AWS.

Demonstration

I’m a Serverless framework fan, and I use it for this part. All sources are available on Github.

Developpers using Serverless will be familiar with the following file : https://gist.github.com/jeremychauvet/4e568fb9364b14c1e7963af7934aa188#file-serverless-yaml

As you can see, few things only changed with container support :

• Lambda layers are no longer used. Dependencies must be included inside your Docker image, for example with a requirements.txt parse with Dockerfile
• Block ECR is all new : Serverless will build and push your image on ECR (Elastic Container Registry, aka AWS Docker Hub). You can specify name and path.
• After days of tests, I’ve not notice a significant change on cold start duration.