How to Effortlessly Deploy FastAPI on AWS Lambda

Effortlessly Deploy FastAPI on AWS Lambda

Modern app development is all about moving fast, scaling smart, and reducing operational overhead. If you’re still managing FastAPI apps on EC2, you’re likely dealing with patching, manual scaling, and paying for idle time — not ideal. That’s exactly why we made the move to AWS Lambda.

In this post, we’ll show you how we migrated a FastAPI app from EC2 to AWS Lambda, using Docker containers and Amazon ECR. This setup allows you to deploy FastAPI on AWS Lambda without worrying about the 250MB ZIP limit — thanks to Lambda’s support for container images up to 10 GB, it’s perfect for apps with heavy ML dependencies.

If you’re looking to streamline your deployments, save costs, and fully embrace serverless with AWS Lambda, this guide is for you.

Why Migrate from EC2 to Lambda?

On EC2, you launch virtual machines (instances) and manage everything: selecting AMI, configuring security, installing software, scaling groups, and patching the OS. If traffic spikes, you must manually add instances or set up autoscaling. You also pay for every second an EC2 is running, even if idle. In contrast, Lambda is fully serverless: it automatically scales your code up and down with demand, and you only pay for the compute time you actually use. This can save costs for bursty workloads. It also frees you from OS maintenance and patching.

FeatureEC2Lambda
ScalingManual (or configure Auto Scaling)Automatic built-in scaling
BillingPay for running instances (even idle)Pay per invocation/compute time; idle = $0
ManagementYou must configure, patch, and manage serversFully managed by AWS; no server maintenance

Challenges with FastAPI on Lambda

Running FastAPI on Lambda isn’t plug-and-play. Here are key hurdles:

  • ASGI Compatibility: FastAPI uses ASGI, while Lambda expects WSGI. Use Mangum to bridge the gap.
  • Deployment Size Limit: Lambda’s ZIP limit is 250 MB unzipped. For apps with heavy libraries (e.g., NumPy, TensorFlow), use Docker + ECR (up to 10 GB).
  • Timeout Constraints: Lambda caps execution at 15 minutes. For long-running tasks, consider Step Functions, SQS, or Fargate.

With these in mind, FastAPI runs well on Lambda using the right tools and architecture.

Solution: Use Lambda Container Support with Amazon ECR

To bypass the 250 MB ZIP limit and support large dependencies, deploy your FastAPI app as a Docker container via Amazon ECR. Lambda now supports container images up to 10 GB, perfect for ML-heavy apps.

Why It Works:

  • Local Testing: Run and debug with docker run before deploying.
  • Versioning: Tag images in ECR for easy rollbacks and updates.
  • Portability: Use the same container across Lambda, ECS, or any Docker runtime.
  • Seamless AWS Integration: IAM-secured, ECR-connected, and Lambda-ready.

For ML APIs with bursty workloads, this setup is scalable and cost-effective—no need to manage EC2 infrastructure.

What is Amazon ECR?

Amazon Elastic Container Registry (ECR) is AWS’s managed Docker image registry. It offers secure, scalable storage for container images with fine-grained IAM access controls.

You can:

  • Push/pull images using Docker or AWS CLI
  • Tag images for versioning
  • Seamlessly integrate with Lambda, ECS, EKS, and EC2

ECR makes it easy to manage and deploy containerized FastAPI apps across AWS.

Step-by-Step Deployment: FastAPI on Lambda Using Docker Image from ECR

This step-by-step process helps you deploy a FastAPI application to AWS Lambda using a Docker image stored in Amazon Elastic Container Registry (ECR). This approach provides flexibility in packaging dependencies, runtime, and OS-level customizations.

Prerequisites

  • AWS CLI installed and configured (aws configure)
  • Docker installed and running
  • Sufficient IAM permissions for ECR, Lambda, and role creation
  • A working Dockerfile and FastAPI app
  • (Optional) GPG and pass for secure local credential storage

Step 1: Configure AWS CLI

Run this in your terminal:

aws configure

You’ll be prompted to enter:

  • AWS Access Key ID
  • AWS Secret Access Key
  • Default region name (e.g., us-east-1)
  • Default output format (e.g., json)

This sets up AWS credentials on your machine.

Optional: Secure Credentials with GPG + pass

1. Generate a GPG key:

gpg --full-generate-key
  • Select: Option 1 (RSA and RSA)
  • Set: Key size: 4096
  • Specify: Expiry: 0 (no expiration) or e.g., 1y
  • Provide: your name and email
  • Create: a passphrase

2. Find your GPG key ID:

gpg --list-keys

Copy the key ID (it looks like a long alphanumeric string).

3. Initialize pass:

pass init <YOUR-GPG-ID>

Now you can securely store AWS credentials using pass.

Step 2: Create an ECR Repository

aws ecr create-repository --repository-name my-lambda-repo

Note the repository URI from the output (e.g., 123456789012.dkr.ecr.region.amazonaws.com/my-lambda-repo).

Step 3: Build and Push Docker Image to ECR

1. Authenticate Docker to ECR:

aws ecr get-login-password --region us-east-1 | \
docker login --username AWS --password-stdin <your-account-id>.dkr.ecr.us-east-1.amazonaws.com

2. Build your Docker image:

docker build -t my-lambda-image .

3. Tag the image:

docker tag my-lambda-image:latest <your-ecr-uri>:latest

4. Push to ECR:

docker push <your-ecr-uri>:latest

Replace <your-ecr-uri> with the full repository URI noted earlier.

To update the image later (after code changes):

docker build -t my-fastapi-lambda .
docker tag my-fastapi-lambda:latest <your-ecr-uri>:latest
docker push <your-ecr-uri>:latest

Then go to the Lambda function → Deploy new image → Choose latest image from ECR.

Step 4: Create Lambda Function (Using ECR Image)

Via AWS Console:

  • Go to AWS Console → Lambda
  • Click Create function
  • Choose Container image
  • Fill in:
    1. Function name
    2. Select your image from ECR
    3. Choose or create an IAM role
  • Click Create function

Step 5A: Connect Lambda to API Gateway (HTTP API)

  1. Open API Gateway > Create API > HTTP API > Build
  2. Add integration → Lambda Function
  3. Set route:
    • Method: ANY
    • Path: /{proxy+}
  4. Click Next → Create & Deploy

You’ll get a public HTTP endpoint.

Step 5B: Connect via REST API (for Timeout > 29s)

Use REST API if your FastAPI Lambda needs to run for more than 29 seconds (e.g., heavy processing, media conversion, etc.).

1. Create REST API

  1. Go to API Gateway → Create API
  2. Choose REST API
  3. Select:
    • Protocol: REST
    • Endpoint type: Regional (important for custom timeouts)
  4. Click Build

2. Recreate Resources and Methods

  1. Click Actions → Create Resource
    • Example: /process
  2. Select the new resource
  3. Click Actions → Create Method (e.g., POST)
  4. Choose:
    • Integration type: Lambda Function
    • Select your existing Lambda (using the ECR image)

3. (Required) Increase Timeout Limit to 3 Minutes

API Gateway only allows 29 seconds by default. To extend it to 3 minutes, you must request a quota increase:

How to Request Timeout Increase via AWS Service Quotas

  1. Open the AWS Service Quotas Console
  2. In the search bar, type: API Gateway
  3. Click on the service: Amazon API Gateway
  4. Find this quota:
    • “Maximum integration timeout in milliseconds for Lambda function”
  5. Click on it, then choose Request quota increase
  6. Enter:
    • New value: 180000 (milliseconds = 3 minutes)
  7. Submit the request
    🕒 Approval may take from a few hours to a few days

4. Apply the New Timeout (After Approval)

Once AWS approves your quota increase:

  1. Go back to your REST API
  2. Select the method (e.g., POST on /process)
  3. Click Integration Request
  4. Scroll to Timeout field
  5. Set timeout to: 180000 (ms)

5. Deploy the API

  1. Click Actions → Deploy API
  2. Create a new stage (e.g., prod)
  3. You’ll get a new Invoke URL (your API endpoint)

Challenges Faced and Solutions

During the migration from EC2 to AWS Lambda using container images via ECR, several practical challenges arose. Below are the key issues encountered and the solutions implemented:


1. Selenium Not Working in Lambda

Problem:
Selenium-based code failed in Lambda due to missing browser binaries and dependencies.

Solution:

  • Created two files: install-browser.sh and chrome-deps.txt
  • Updated the Dockerfile to:
    • Install Chrome
    • Add all necessary dependencies
  • Ensured headless Chrome was compatible with the Lambda environment

2. File System Write Permission Errors

Problem:
Lambda has a read-only file system; attempts to write to local directories failed.

Solution:

  • Updated code to use /tmp/ directory for all write operations

3. 29-Second Timeout in HTTP API

Problem:
API Gateway’s HTTP API has a fixed timeout of 29 seconds.

Solution:

  • Migrated from HTTP API to REST API
  • Requested a service quota increase for Lambda integration timeout
  • Set timeout to 180,000 ms (3 minutes) in Integration Request

Real-World Example

Cost-Effective Scaling: Migrating the FastAPI-based ML image classification service from a 24/7 EC2 instance to AWS Lambda (via Docker and ECR) led to a 60% cost reduction, thanks to on-demand scaling and zero idle costs.

Simplified Deployment: Dockerizing the app (with TensorFlow and models) enabled a streamlined CI/CD pipeline—new code triggered image builds, ECR pushes, and Lambda updates with versioning and monitoring built-in.

Improved Developer Experience: FastAPI’s compatibility with Lambda allowed for minimal code changes and faster iteration, making it a preferred choice for high-performance ML inference APIs on AWS.

Conclusion

Migrating a FastAPI app from EC2 to AWS Lambda (via ECR) combines the best of serverless and containers. You offload infrastructure management to AWS while retaining full control over your runtime with Docker. In summary:

  • Lambda+ECR is great for event-driven, bursty workloads, especially if your app has large dependencies. It offers auto-scaling, pay-as-you-go pricing, and easy deployments from Docker images.
  • EC2 is still a good choice for long-running tasks, persistent connections, or highly predictable steady workloads. If you need custom OS configs or GPUs, EC2/ECS/Fargate may be more appropriate.
  • Weigh your needs: use Lambda for APIs and microservices that can start fast and finish within 15 minutes, and lean on EC2/ECS when you need more than that.

By migrating to serverless containers, you can achieve significant cost savings and agility. We encourage you to try container-based Lambdas for your next FastAPI project and explore AWS’s growing serverless container ecosystem!

Further Reading

  1. Skyrocket Sales: The Ultimate Guide to Recommendation Engine
  2. AI Chatbots: Discover how to reap its benefits
  3. Why companies turning to a Fractional CTO for growth?
  4. How to make your OTT users search experience lightning fast?
  5. How GenAI Boosted OTT Company Growth to New Heights?

Follow Us

Madgical@LinkedIn
Madgical@Youtube

Disclaimer

*The views are of the author and not necessarily endorsed by Madgical Techdom