You Can Run Containers on AWS Amplify Now
Tags: aws
Published: 2020-12-11 14:24:37

---
title: You Can Run Containers on AWS Amplify Now
published: true
description: AWS just added the easiest way to deploy long running serverful code alongside a serverless architecture.
tags: AWS
slug: amplify-serverless-containers
cover_image: https://d2908q01vomqb2.cloudfront.net/0a57cb53ba59c46fc4b692527a38a87c78d84028/2020/12/10/Artboard-Copy.png
---

The second week of [AWS re:Invent](https://reinvent.awsevents.com/) brought a surprise major announcement from the AWS Amplify team: **You can run Docker containers as AWS Amplify APIs now**!!!

The main Achilles heel of migrating to serverless architectures is having to relearn and rewrite traditional serverful code. With [the new Amplify Serverless Containers](https://aws.amazon.com/blogs/mobile/zero-effort-container-deployment-for-graphql-and-rest-apis-and-web-hosting-with-amplify-cli/), it is now possible to deploy code in stateful Docker containers with the *exact same workflow* as the rest of Amplify CLI.

```bash
# example of the new CLI workflow, see docs for details
# Amplify CLI version 4.39+

$ amplify init # if you're setting up new Amplify project

$ amplify configure project
 > Do you want to enable container-based deployments? Yes

$ amplify add api

Please select from one of the below mentioned services: REST
? Which service would you like to use 
  API Gateway + Lambda 
❯ API Gateway + AWS Fargate (Container-based) 
```

For the first time, this opens up the possibility of running **Rails, Django, Laravel**, or any other traditionally serverful APIs *seamlessly* alongside a serverless architecture. If it fits in a Docker container, you can run it! This thus unlocks the full capabilities of their respective ecosystems. 

Emphasis on *seamless* integration: this means that frontend and mobile developers don't need to go to 9 months of cloud school (having to learn the details of VPC, subnets, NACLs, IAM policies, SSL generation, continuous deploy, cost optimization, etc) just in order to get a containerized API up and running on AWS.

This, to me, is a big deal for a number of interrelated reasons:

- **Long Running Code**: AWS Lambda functions are limited to 15 minutes. If I need to run longer tasks, like video conversion or batch processing, I would have to jump out of my existing workflow and use a completely different set of tools. Now, I can run Rails + [Sidekiq](https://github.com/mperham/sidekiq) or [Flask + Celery](https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-xxii-background-jobs) with just an industry standard `docker-compose.yml`. Because Amplify's Serverless Containers feature uses AWS Fargate, we may in future have the option of vertically scaling system resources as needed, beyond the traditional [resource constraints] (https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html) of AWS Lambda.
- **Access Entire Ecosystems**: Libraries and frameworks that were written for serverful paradigms typically become useless when shifting to serverless/Jamstack architectures, requiring yet another learning curve and search for tools. Now you are free to mix and match them - anything that runs in a Docker container is fair game (and *everything* runs in a Docker container!)
- **Incremental Migration**: This also means that it is no longer a heavy lift to move existing apps and codebases to a serverless/Jamstack architecture. As long as you can separate your UI layer from your API layer, you are now able to host your UI on [Amplify Console](https://aws.amazon.com/blogs/aws/amplify-console-hosting-for-fullstack-serverless-web-apps/), and your APIs as a REST or GraphQL service with API Gateway + AWS Fargate.
- **Easy Access to other [Amplify categories](https://docs.amplify.aws/cli/start/workflows#amplify-category-add)**: because this plugs right into the Amplify API category workflow, this means that your code inside your containers get all the same benefits of Amplify APIs like easy authentication with Amazon Cognito and easy access to Amplify-managed resources like [Storage](https://docs.amplify.aws/cli/storage/overview), [Functions](https://docs.amplify.aws/cli/function), [GraphQL](https://docs.amplify.aws/cli/graphql-transformer/overview) and more. Because networking is handled for you, you can *even talk to other containers* - the default `docker-compose.yml` example in the CLI shows how you can make an Express (JS) app interoperate with a Flask (Python) app!

So, yeah. I think this is awesome - You can run basically anything on AWS Amplify now - meaning that you spend less time wrangling infrastructure and more time writing valuable features. Don't take my word for it, see [Ant Stanley](https://twitter.com/IamStan/status/1337088737243783174?s=20) (organizer of Serverless Days and overall cloud expert):

{% twitter 1337088737243783174 %}

P.S. for those who are making comparisons with AWS CDK, note that [this capability was actually made with CDK](https://twitter.com/undef_obj/status/1337217826436747266?s=20) - it solves a higher level problem than CDK.