Magic beanstalk? What you need to know about AWS App Runner

Developing apps is where you create value, not managing how they’re deployed. Instead of wrangling infrastructure, why not just write your code, and let something else do the rest for you?

Cloud providers have been making this process incrementally easier over the years. And with the release of App Runner, AWS may have just made a quantifiable leap for many of their customers.

App Runner exists to take a web application, either from its source code (Node.js or Python) or a container, and deploy it into the AWS cloud. It's one of those rare times a cloud provider names their product intuitively (I’m looking at you, AWS Proton).

Beyond just deployment, it also handles securing your connection with HTTPS, managing your custom domains, scaling up your application to meet demand, and scaling it back down to save costs.

Running virtual machines, load balancers, and the like are all abstracted away. While AWS makes this all relatively easy compared to years gone by, it still takes a bit of know-how and time. With this, you can just write your code and have it up and running in minutes.

Behind the scenes, the core of App Builder is that it builds an Amazon ECS Cluster and uses Fargate to execute your containers. While that’s not revolutionary, anyone who’s tinkered with ECS will appreciate the ability to avoid it, skipping all the extra config and just saying “run this thing”.

You sacrifice some fine-grained control in some cases, such as scaling based on CPU and memory. But in most cases, you may not be as worried about those. The beauty of this service is the faster and easier you can deploy your code, the better.

One super-handy feature in App Runner is the Automated Build feature, where your application can automatically rebuild and deploy itself with the latest version of the code deployed to the source repository. While this isn’t new in the world of CI/CD, what’s remarkable here is that you don’t need to worry about CodePipeline or another tool. Just check a box, and it’ll all happen for you.

Does App Runner seem strangely familiar? It's not just you. The fundamental concepts behind this service are deeply rooted in other services from AWS and even other cloud providers.

AWS Elastic Beanstalk has been doing similar things for the last decade. And while revolutionary at the time especially, it’s always had some limitations, especially in complex scenarios. App Runner also brings in some additional features that just abstracts more of the minutiae of deployment.

One key difference between the two services is that while both App Runner and Elastic Beanstalk automate the deployment, the ongoing administration is different. In Elastic Beanstalk, you have much more control over the infrastructure once it’s deployed. That could be a necessity sometimes, but it also introduces scope for unmanaged changes. For App Runner, the service is totally managed, removing maximum administrative overhead.

Last year, AWS Copilot was released as a new command-line tool to simplify ECS deployments. And while it has a compelling niche, the lack of scaling left something yet desired. (Updated 5/21/21: AWS have since released the latest version (1.7.0) of Copilot, which natively supports App Runner, and goes a long way to bridging the gap. Thanks to Deepak Singh, VP of Compute Services at AWS, for pointing this out to us!) Others have also compared App Runner to Amazon Lightsail, but you don’t get the same level of control.

If you’re familiar with GCP, you can’t deny this is almost a dead-ringer for the ever-powerful Google Cloud Run. And you’d be right. AWS has seen a brilliantly executed idea and said: “We need this”. And so far, it seems they’ve done an outstanding job of it, with one potentially significant exception.

Like all new services, AWS App Runner seems to be missing a few useful features that could make a big difference in its adoption.

The biggest one is unlike Google Cloud Run; there is no option to ‘scale to zero’. The beauty of this feature is that if your app is receiving no traffic, you aren’t paying for it at all, and it will only startup when needed. Many production apps won’t be concerned by this feature, but for those very infrequently accessed solutions, it turns what could be a $0.05 monthly bill into $5.00.

One super curious omission is that while the code-based service repositories support GitHub (and thank goodness!), it doesn’t yet support AWS’s own CodeCommit service. To be fair, prioritising GitHub was an incredibly savvy move to support the adoption of the service, rather than bolting users to AWS products.

While interface endpoints exist to allow resources in a VPC to access and deploy to App Runner, it doesn’t look like there’s any way for apps on App Runner to access resources in a VPC. Whether this is an issue depends a lot on your application architecture.

AWS is exceptionally good at listening to their customers, hence their success, and it wouldn’t surprise me if we see a boom of new features at re:Invent 2021, or even sooner.

App Runner can make things so much easier for developers, especially for small scale projects that just don’t need the beefy bespoke infrastructure.

For an additional perspective, I had a chat with Neil Walker, the Well-Architected Practice Lead for Wolk Technology, who shared his thoughts:

“Many of our SMB clients use Elastic Beanstalk to power their production workloads. App Runner might be a more natural fit for many of them. Our SMB clients want to progress to containers but don't have the technical resources in house to support it. We can’t wait for it to become available to the Sydney region for our clients to gets their hands dirty.”

If the App Runner team can build a ‘scale to zero’ feature, developing microservices gets a whole lot more interesting. If not, I’m petitioning AWS to rename it “Magic Beanstalk”.