Tackling AWS Lambda Deployment Challenges: Overcoming Size Limitations with ECR and Docker

In one of our recent projects, we faced a significant challenge deploying AWS Lambda functions using the Serverless framework. The issue stemmed from exceeding the 250 MB unzipped deployment size limit for AWS Lambda functions by 100 MB after integrating the Plotly library. This library was critical for creating candlestick charts based on client-provided data, making it indispensable for the new functionality.

The Initial Problem

Our deployment pipeline was already nearing the 250 MB limit due to existing Python dependencies. Adding Plotly increased the size to 350 MB. To make matters worse, the pipeline was tightly coupled with an S3 bucket and multiple triggers, making any changes to the deployment process potentially disruptive.

Exploring Potential Solutions

1. AWS Lambda Layers

Initially, we explored AWS Lambda layers to reduce the deployment size. Layers enable shared dependencies to be uploaded separately and attached to multiple Lambda functions. However, this solution had two critical drawbacks:

• Size Limitation: AWS enforces a 50 MB compressed size limit per layer, which was insufficient for our combined dependencies.

• Increased Complexity: Splitting dependencies across multiple layers introduced additional complexity and raised maintainability concerns in the long run.

2. AWS Elastic Container Registry (ECR) and Docker

After further research, we identified AWS Elastic Container Registry (ECR) as the ideal solution. ECR allows you to store and manage Docker container images, bundling all code, dependencies, and runtime configurations into a single image. This approach bypassed the size constraints of traditional Lambda deployments.

The Breakthrough: Implementing ECR and Docker

1. Creating the Docker Image

We created a Dockerfile to package the Lambda function's code and dependencies, including Plotly, into a container image. This ensured all libraries were included without worrying about size constraints.
The final container image was pushed to an ECR repository for storage.

2. Updating the Deployment Process

The deployment process was updated by modifying the Serverless framework configuration to use the container image instead of a ZIP package. Specifically, we changed the package.type to Image.

Since AWS does not allow changing the package type of an existing Lambda function, we had to:

• Delete the existing stack.

• Remove all associated log groups and streams.

• Redeploy the stack with the new configuration.

3. Streamlining Future Deployments

To simplify and automate future deployments, we created a deploy.bat script. This script automated:

• Building the Docker image.

• Pushing it to the ECR repository.

• Linking the Lambda function to the updated container image.

Key Outcomes

1. Overcoming Size Limitations

By leveraging container images, we bypassed the size constraints of Lambda ZIP packages and layers, enabling scalability and flexibility for future updates.

2. Maintaining Pipeline Stability

The new solution allowed us to deploy the Lambda function without disrupting the existing pipeline or compromising functionality.

3. Improved Developer Efficiency

The automated deployment script significantly reduced complexity for new developers, improving team productivity and reducing the learning curve.

Lessons Learned

This experience underscored the importance of adaptability and the value of leveraging AWS services to their fullest potential. Challenges like this push us to explore innovative solutions, ultimately refining our processes and enhancing our ability to deliver high-quality results.

Posted by Fezul Hasan on 18th Jan, 2023
Sunil finds his forte in defining software architectures. With over 15 years of experience in the industry, he has contributed to several leading projects.