Since its launch, AWS Lambda has revolutionized application execution through its serverless computing model, enabling developers to run code without managing underlying servers, thus simplifying operational burdens. Initially, Lambda functions were deployed primarily as .zip packages, which limited their use in complex scenarios, especially when handling large dependencies or specific runtime requirements.

However, with the evolution of cloud computing and the popularity of containerization, AWS Lambda introduced support for container image (Open Container Initiative - OCI compliant packaging) deployment in 2020. This significant update allows developers to use familiar Docker tools and workflows to package and deploy Lambda functions, greatly expanding Lambda's scope and flexibility. With this support, containerized web applications can seamlessly migrate to a serverlesss environment, leveraging Lambda's inherent advantages like automatic scaling, built-in high availability, and pay-as-you-go pricing, without additional engineering effort to adapt to new tools or development workflows.

Before starting, register an AWS account.

AWS Lambda's support for container images is not just a new feature in its functionality set; it represents a strategic convergence in AWS's cloud service landscape. This convergence aims to bridge the long-standing gap between serverless and containerized deployments, allowing Lambda to reach a broader developer community—especially those already invested in container workflows and tools. This evolution acknowledges that while serverless offers significant operational benefits, containers provide familiarity and control preferred by many developers or required by specific workloads. This convergence also signals that the future of cloud computing may no longer be a strict choice between serverless and containers, but rather how to leverage the strengths of both for hybrid architectures and smoother transition paths.

Additionally, support for container images directly addresses a key psychological and practical barrier for container developers considering Lambda. By allowing them to continue using familiar Docker tools and workflows, AWS significantly reduces the cognitive load and retraining costs for developers learning a new paradigm. This means developers can leverage their existing Dockerfiles, build processes, and even local test environments with minimal Lambda-specific adjustments, making the transition to serverless less daunting and more attractive. This strategy accelerates serverless adoption among a large developer base that might have hesitated due to perceived complexity or the need to abandon existing container investments. It fosters a more inclusive ecosystem where diverse development preferences coexist within the serverless paradigm.

Understanding AWS Lambda's Core Programming Model

At the heart of AWS Lambda is its unique programming model, which defines how application code interacts with the Lambda service. Understanding this model is crucial for container developers, as it differs from the interaction patterns of traditional container applications (typically long-running processes or web servers).

"Lambda Magic": A Simple Contract Between Application and Service

AWS Lambda's programming model can be understood as a clear and simple contract between application code and the Lambda service. The core of this contract lies in how the application interacts with the Lambda service to receive requests and send responses. The key mechanism to implement this contract is the Lambda Runtime API. This API provides a standardized way for applications to fetch event data and report execution results to the Lambda service. Developers can view a container instance as a long-running process that repeatedly checks for events to process, executes the corresponding work, and notifies the Lambda service of the result.

This "simple contract" is more than an operational detail—it's a fundamental design principle that decouples applications from underlying infrastructure. By standardizing input/output mechanisms (events), Lambda abstracts away underlying infrastructure and even specific runtime environments. This abstraction is vital for application portability. For example, an adjusted entry point to run a businesslogic.sh script outside Lambda demonstrates that core business logic is largely independent of Lambda's execution environment, as long as the contract (event handling) is met. This allows developers to focus on business logic implementation without getting entangled in serverless platform complexities. This decoupling eases migration to Lambda (especially for containerized apps, as core logic remains unchanged) and potentially eases migration out if business needs change. It promotes a modular architectural style where the compute environment is a replaceable component, not a tightly coupled dependency.

Event-Driven Nature and Execution Environment

AWS Lambda is fundamentally an event-driven system. All compute operations, including container instance startup and code execution, are triggered by events. Lambda supports event sources from hundreds of AWS services, such as messages from Amazon SQS queues, HTTP calls from Amazon API Gateway or Amazon Elastic Load Balancing, etc.

In Lambda's execution model, a container instance processes at most one event at a time but can handle multiple events sequentially during its lifecycle. When an event arrives, Lambda's orchestrator assigns it to an initialized and idle container instance; if none are available, Lambda starts a new container instance to process the event. To optimize performance and reduce cold starts, Lambda may retain the container for future events after a single execution. If concurrent events surge, Lambda launches multiple container instances in parallel until it reaches the configured function or account concurrency and burst limits.

This event-driven scaling model represents a major paradigm shift from traditional container orchestration. Instead of provisioning and managing a cluster of always-"online" (and potentially idle) containers, Lambda dynamically scales compute instances (containers) per event. This leads to an efficient "pay-for-value" pricing model—you pay only when code executes, minimizing resource waste. For container developers, this means shifting from managing cluster capacity to focusing purely on application logic and event handling, offloading complex scaling logic to AWS. Container reuse is a key optimization balancing "pay-per-event" with performance, helping mitigate cold starts. This model is ideal for spiky, unpredictable workloads, offering superior cost-effectiveness and operational simplicity compared to always-online container clusters. It encourages developers to think in terms of statelessness and event handling, critical for highly scalable and resilient distributed systems.

What Does Containerized Lambda Solve?

The introduction of containerized Lambda aims to overcome the inherent limitations of traditional Lambda deployments, providing developers with greater flexibility and capabilities to handle a wider range of application types.

Breaking Deployment Package Size Limits (250MB vs. 10GB)

Traditional AWS Lambda functions deployed via ZIP archives have a maximum uncompressed deployment package size of 250MB. This limit is a significant bottleneck for applications needing to include large machine learning models, complex dependency libraries, or numerous third-party libraries. For example, large ML models often exceed hundreds of megabytes, and complex applications may have multiple dependencies that can't fit within the package size limit.

In contrast, Lambda container image support allows deployments up to 10GB in size. This substantial increase enables Lambda to easily host large ML models, applications with multi-layered complex dependencies, and scenarios requiring extensive custom software and binaries. For instance, a 10GB ML model for email fraud detection, which was unfeasible with standard ZIP deployments, becomes achievable with containerized Lambda.

Flexibility in Runtime and Dependency Management

Traditional Lambda has specific limitations on supported programming runtimes (e.g., Node.js, Python, Java, Go), posing challenges for applications needing non-supported runtimes (like Rust, Elixir) or manually bundled complex dependencies. Additionally, applications requiring system libraries or binaries not natively provided by Lambda face difficulties.

Lambda containerized deployment solves these issues entirely. It allows developers to "Bring Your Own Runtime," packaging any programming language's runtime and all necessary dependencies directly into the container image. This eliminates the complexity of manual bundling and enables applications to include specific system-level tools or libraries not provided by Lambda's native environment. This support for arbitrary runtimes breaks Lambda's constraints on language and library choices, allowing more existing applications to migrate "as-is."

OS-Level Customization Capabilities

AWS Lambda's traditional execution environment doesn't allow modifications to the underlying operating system, impacting applications that need specific software, libraries, system tools, custom security configurations, or OS-specific processing tools.

With containerization, developers can include required OS-level customizations in their container images—such as installing specific Linux packages, configuring environment variables, or running custom startup scripts—to meet the application's unique environmental needs.

Optimizing Cold Start Times

AWS Lambda functions experience a "cold start" when invoked for the first time after long inactivity, causing additional latency that increases response times for latency-sensitive applications and creates performance bottlenecks in functions with heavy dependencies.

By optimizing container images, developers can significantly reduce cold start times for faster initialization and improved performance. For example, using Docker's multi-stage builds reduces image size, speeding up Lambda container function activation. AWS provides optimized base images preconfigured with the runtime environment and basic system dependencies needed for Lambda event handling, simplifying setup and helping reduce cold start times.

AWS Account Registration

Before using AWS services, you need an AWS account.

1. Open the official website and create an account: Open the AWS official website and click the "Create User" button in the top right to create a new account.
2. Verify your email address: Enter the email address for the account, click "Verify Email Address," and enter the verification code from your email.
3. Set a password: After verification, enter the password for the new user.
4. Enter personal information: Fill in the corresponding personal details.
5. Provide account information: A Visa card is typically used.
6. Identity verification: Confirm the entered information, choose SMS verification, select your region, and complete SMS verification.
7. Select a support plan: Choose based on your needs (e.g., "Basic Support - Free" for personal development).
8. Complete registration and log in: Click "Complete Registration" and wait for AWS verification. Once verified, log in to the AWS Management Console.

The "Simple Contract" Between Application and Service

To illustrate, consider a low-level Bash script example. The following Dockerfile defines the container environment and specifies the entry point:

FROM public.ecr.aws/amazonlinux/amazonlinux:2023
RUN yum install -y jq tar gzip git unzip
RUN curl -Ls "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" \
    && unzip awscliv2.zip \
    &&./aws/install
ADD entrypoint.sh /entrypoint.sh
ADD businesslogic.sh /businesslogic.sh
ENTRYPOINT ["/entrypoint.sh"]

This Dockerfile is based on the Amazon Linux 2023 image, installs necessary tools, and adds entrypoint.sh and businesslogic.sh scripts to the image. entrypoint.sh serves as the container's entry point, implementing interaction logic with the Lambda Runtime API.

Runtime API and Environmental Constraints

While flexible, the Lambda container environment has specific constraints developers must understand to ensure correct operation and optimization:

• Read-only file system: Containers run with a read-only root file system; the /tmp directory is the only writable path, providing 512MB to 10,240MB of temporary storage. This enforces stateless application design, with any persistent data stored in external services (e.g., Amazon S3, DynamoDB).
• Resource configuration: A container's compute power is configured via memory parameters, with CPU capacity allocated proportionally.
• Privilege restrictions: Privileged containers aren't supported, and GPUs can't be exposed.
• Execution lifecycle: The execution lifecycle of container instances is artificially limited and not part of Lambda's "contract." Developers shouldn't assume containers will survive long.
• Operating system and architecture: Only Linux-based container images are supported, and images must target a single architecture (ARM or x86).

The following entrypoint.sh script is the core of the Lambda container, implementing the interaction loop with the Lambda Runtime API:

#!/bin/sh
set -euo pipefail
###############################################################
# Container initialization before processing invocations     #
###############################################################
echo "Installing the latest version of Hugo..."
cd /tmp
export LATESTHUGO_URL=$(curl -s https://api.github.com/repos/gohugoio/hugo/releases/latest | jq -r '.assets.browser_download_url | select(contains("Linux-64bit.tar.gz") and contains("extended"))')
export LATESTHUGO_FILENAME=$(basename "$LATESTHUGO_URL")
curl -LO "$LATESTHUGO_URL"
tar -zxvf "$LATESTHUGO_FILENAME"
./hugo version
###############################################
# Processing invocations in the container      #
###############################################
while true
do
  # Create a temporary file for headers
  HEADERS_FILE="$(mktemp)"
  # Fetch the next event (blocks until an event is available)
  EVENT_DATA=$(curl -sS -LD "$HEADERS_FILE" -X GET "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
  # Extract the request ID from headers
  REQUEST_ID=$(grep -i "Lambda-Runtime-Aws-Request-Id" "$HEADERS_FILE" | tr -d '[:space:]' | cut -d: -f2)
  ############################
  # Execute business logic   #
  ############################
  /businesslogic.sh
  ############################
  # Send the response to Lambda
  curl -X POST "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d '"statusCode": 200'
done

The entrypoint.sh script first performs one-time initialization (e.g., downloading the Hugo binary to /tmp). It then enters an infinite loop, polling the local AWS_LAMBDA_RUNTIME_API endpoint for new events via curl. Upon receiving an event, it executes the businesslogic.sh script (containing actual business logic) and notifies the Lambda service via an HTTP POST request after processing.

Example businesslogic.sh:

#!/bin/sh
set -euo pipefail
rm -rf sample-website
git clone https://github.com/${CUSTOM_GITHUB_USER}/aws-lambda-container-dev-blog
target_dir="aws-lambda-container-dev-blog/hugo-site"
/tmp/hugo -s "$target_dir"
aws s3 cp "$target_dir/public/" "s3://${CUSTOM_S3_BUCKET}/" --recursive

This example clearly separates container initialization and event handling logic.

Abstraction Layers: Runtime Interface Client (RIC) and Lambda Web Adapter

While the above Bash script demonstrates the underlying mechanism, most developers use AWS-provided abstraction layers to simplify development:

• Runtime Interface Client (RIC): AWS's open-source RIC implements low-level HTTP interactions with the Lambda Runtime API, passing event information to application functions and abstracting complex communication details. Developers can use a standalone RIC, AWS Lambda-managed base images (preinstalled with RIC), or package business logic as a ZIP file with AWS fully managing the runtime environment.
• Lambda Web Adapter: A key abstraction layer that allows traditional web applications to run on Lambda, acting as an interface between the Lambda programming model and web application frameworks. It enables deployment without major modifications to web application code.

Building and Deployment: Seamless CI/CD Integration

There are multiple ways to build Lambda-compatible container images:

• AWS Lambda Base Images: Preloaded with language-specific runtimes, RIC, and Runtime Interface Emulator (RIE) — recommended.
• AWS OS-Only Base Images: Contain Amazon Linux and RIE, suitable for compiled languages or custom runtimes (requires manual RIC inclusion).
• Non-AWS Base Images: You can use images from other container registries (e.g., Alpine Linux, Debian) but must manually include RIC.

AWS Lambda Deployment Comparison

Feature	.zip Package Deployment	Container Image Deployment
Deployment Size	250MB (uncompressed)	Up to 10GB
Runtime Support	Limited to AWS-supported runtimes	Any runtime (Bring Your Own Runtime)
Dependency Mgmt	Manual bundling, size-limited	Dependencies in container image, simplified
OS Customization	No OS-level changes	Full OS-level customization
CI/CD Integration	Custom workflows needed	Integrates with Docker-based CI/CD pipelines
Use Cases	Lightweight, standard runtimes, simple microservices	Large ML models, complex apps, custom runtimes, traditional web app migration

Regardless of the approach, images must meet core requiremants: implement the Lambda Runtime API, support a read-only file system (with /tmp writable), be readable by the default Lambda user, and be Linux-based with a single architecture.

Migrating Existing Containerized Apps to Lambda

Practical steps to migrate existing containerized applications to Lambda:

1. Local Testing: Clone the app repository, review the Dockerfile, build, and test the Docker image locally.

docker build -t my-container-app.
docker run -p 8080:8080 my-container-app

2. Port to Lambda Runtime: Define the Lambda function handler, modify the container image to interact with the Lambda Runtime API, and test the containerized Lambda function locally using the Runtime Interface Emulator (RIE).
3. Deploy to AWS: Push the built container image to Amazon Elastic Container Registry (ECR), then create or update the Lambda function via the AWS Management Console, CLI, or Infrastructure as Code (IaC) tools like AWS SAM or CloudFormation.

Dual-Pipeline CI/CD Strategy

Lambda containers integrate seamlessly with Docker-based CI/CD pipelines. A typical automated deployment architecture includes two independent CI/CD pipelines:

• Container Image Deployment Pipeline: Pulls code from the source repository, builds the container image with Docker, tags it, and pushes it to Amazon ECR.
• Lambda Function Deployement Pipeline: Triggered by an Amazon EventBridge event after the container image pipeline completes, it uses AWS SAM to build and deploy/update the Lambda application based on the new container image.

This separated pipeline design improves efficiency and flexibility, allowing image building and function deployment to occur independently.

Real-World Use Cases: Empowering Complex Workloads

Containerized Lambda greatly expands Lambda's application boundaries:

• Large ML Model Deployment: The 10GB deployment size limit makes it ideal for deploying large ML models and complex data science workloads, unfeasible with traditional ZIP deployments.
• Custom Runtimes and Complex Libraries: Supports "Bring Your Own Runtime" to deploy applications requiring non-natively supported runtimes (e.g., Rust, Elixir) or specific system libraries (e.g., image processing tools, FFmpeg).
• Traditional Web App Migration: Provides a direct path to port existing containerized web applications to a serverless environment. With Amazon API Gateway as a proxy, traditional web apps can leverage Lambda's auto-scaling without extensive refactoring.

Finally, a friendly reminder: If you decide to stop using the service, remember to disable it in the console to avoid charges exceeding the free tier.