Functions vs Containers: The Serverless Landscape • Marcia Villalba & Julian Wood

Lambda functions can now use container images up to 10GB instead of the traditional 256MB zip limit, enabling support for larger dependencies and ML models

Container images in Lambda leverage intelligent caching across functions and customers, resulting in faster cold starts compared to traditional zip packages in many cases

Developers can use familiar Docker tooling and workflows for local development and testing of Lambda functions using container images

Container images must be stored in Amazon ECR and need to follow Lambda’s event-driven model - not all container workloads are suitable (e.g. long-running processes over 15 minutes)

Base images are provided by AWS for managed runtimes (Node.js, Python, Java etc.) but custom runtimes allow bringing any Linux-based runtime

Lambda implements “lazy loading” for container images, only pulling required layers when needed rather than downloading the entire image

Container image support enables better portability, immutability and organizational control over runtime environments compared to traditional Lambda deployments

No code changes required when migrating existing Lambda functions to container images if using managed runtimes

Cold starts impact only synchronous workloads where clients wait for responses - async processing is less affected

Container images should still follow Lambda best practices around stateless execution and 15-minute runtime limits