Fargate vs. App Runner

What’s the simplest way to run containers on AWS? My first relevant container workload was running on a fleet of EC2 instances managed by ECS. Maintaining and scaling the needed EC2 instances was wasting a lot of my time. So I got very excited when AWS announced Fargate, a managed compute layer for ECS. Deploying a web application with ECS and Fargate felt quite simple to me. But then, I discovered App Runner, which adds another layer of abstraction and lifts the developer experience to a new level.

Simplicity

This is a typical architecture for a web application running on ECS and Fargate. The following figure shows the networking configuration, a load balancer, as well as different parts of the ECS service.

Compare that with the resources you need to configure to deploy a web application on App Runner, illustrated in the following figure.

I want to make the difference even more apparent. Here is a comparison of the AWS resources needed to host a web application with ECS + Fargate or App Runner.

I want to highlight that App Runner is not a tool that creates and manages all the resources needed for ECS + Fargate in the background. Instead, App Runner provides an abstraction designed for developers looking for a way to deploy their web application with ease.

How is that possible? Where does the simplicity of App Runner come from? This certainly does not cover all but the majority of today’s use cases.

Scenarios

App Runner focuses on a single scenario: a web application answering incoming HTTP requests synchronously. The strong focus creates a simple solution, somewhat atypical for AWS.

ECS and Fargate support a wide variety of scenarios. For example, your application needs to generate a weekly report for thousands of customers based on a complex database query. You cannot achieve that with App Runner but with ECS and Fargate.

So, the simplicity of App Runner limits the possible use cases.

Scaling down to 0

Our industry often overemphasizes web-scale applications. Although, there are a lot of applications out there with low traffic by a manageable number of users. App Runner shines in this application area because it allows scaling down to 0.

App Runner monitors the number of concurrent requests. In case the application receives more than 100 concurrent requests per running container, App Runner will scale out by launching a container. Of course, App Runner scales down the number of containers as well. That’s a behavior you can achieve with ECS and Fargate by configuring scaling policies as well.

However, if your application does not receive any requests, App Runner will first scale down to the minimum number of containers, which is one by default. Next, App Runner will pause the running container. App Runner will start the paused container without any noticeable delay for the user as soon as a request comes in. While a container is paused, there are no costs for the CPU. You only pay for the memory during this phase.

Being able to scale down to 0 significantly reduces costs for applications with low traffic and idle periods.

Pricing

Comparing the costs for two AWS services is tricky. But I will do my very best.

Let’s compare the costs per vCPU and GB to get started. As shown in the following table, you are paying a premium of about 58% when using App Runner compared to ECS + Fargate.

However, there are a few details to consider.

First, traffic to an ECS service typically flows through an ALB or NLB. You have to pay for the data processed by the load balancer. App Runner does not charge for the processed traffic.

Second, Fargate does provide spot pricing with a discount of up to 70% compared to the on-demand price listed above.

Third, App Runner comes with the ability to scale down to 0, as discussed in the previous section.

With this in mind, we will compare costs between ECS + Fargate and App Runner next. If you want to model an example yourself, feel free to use my calculator (see Google Sheet: Cost Estimation: Fargate vs. App Runner).

Imagine a web application used by a handful of accountants to analyze the cash flow of their company weekly. The application requires 1 vCPU and 2 GB memory. As the application is not business-critical, we decide to run a single container only. Also, we are not expecting more than 1 GB of traffic. The application does not receive requests 95% of the time.

The following table shows that running the workload on App Runner is significantly cheaper than running on ECS + Fargate. That’s because of the idle period of 95% and a small number of containers.

Next, picture the web application providing an internal social network for an organization with 1,000 employees. The application is used during business hours, therefore idling 40% of the time. The application requires 1 vCPU and 2 GB per container and scales from 1 to 2 containers based on load. We are expecting 400 GB of traffic per month.

The following table shows that the costs are almost the same for ECS + Fargate and App Runner in this scenario. That’s because the idle period decreased, and the maximum number of containers increased compared to the previous example.

One more scenario to provide a fair comparison between the costs for ECS + Fargate and App Runner: imagine a popular blog on all things AWS. The web application requires 2 vCPU and 4 GB memory per container. We configure scaling from 2 to 6 containers based on load and expect 1,000 GB of traffic. As the blog gets traffic from around the world, the web application idles 5% of the time.

In this example, the calculation looks quite different. App Runner is significantly more expansive than ECS + Fargate.

In summary, when deciding between ECS + Fargate and App Runner, estimating the costs for the concrete scenario is necessary. App Runner is generally more cost-effective for small workloads with long idle periods.

Networking

ECS + Fargate are first-class citizens in a VPC. Each task -1 or multiple containers- launches with an ENI (Elastic Network Interface) attached. Therefore, traffic from and to containers flows through the VPC. For example, a container can connect with an RDS Aurora database, as shown in the following figure.

In contrast, App Runner provides a public HTTPS endpoint for each service. It is also worth noting that by default, an App Runner service is running in a public VPC owned by AWS. So it is possible to connect your container to public endpoints such as S3, DynamoDB, or 3rd party APIs. But it is impossible to connect to an RDS database in your VPC.

However, AWS recently announced the possibility of connecting your App Runner service with your VPC. It works a lot like VPC connectivity for Lambda. App Runner creates an ENI within every subnet you choose for the service.

Besides that, a VPC endpoint is available for the App Runner service. Using such an endpoint gives you the chance to connect to App Runner without letting traffic flow through the Internet. However, be warned that the App Runner service is still accessible from the Internet.

This brings me to a feature that App Runner is missing. There is no way to control incoming traffic. There is no way to restrict access to the public ServiceUrl. The ability to create private App Runner services only accessible from a VPC, for example, by using PrivateLink, would enable many use cases. Also, support for AWS WAF is a must.

Service Maturity

AWS announced App Runner in May 2021. Therefore, it is no wonder that some important functions are still missing. When reviewing the service recently, I’ve calculated a service maturity score of 5.7 (on a scale from 0 to 10, where 10 is a very mature service). Check out my review of App Runner if you are interested in the details. In summary, I’d not recommend App Runner for business-critical workloads at the moment.

Compared to App Runner, ECS and Fargate have been around for years and are ready for production.

Summary

App Runner convinces through simplicity. Also, App Runner’s capability to scale down to 0 is a crucial advantage for small workloads. On the other hand, ECS + Fargate is a production-ready and flexible solution. I’ve summarized more details in the following table.