Fargate vs. App Runner

Andreas Wittig – 20 Jul 2022

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.

Fargate vs. App Runner


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.

ECS + Fargate: VPC, Subnets, ALB, ECS cluster, task definition, service

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

App Runner: Service with public HTTP endpoint

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.

ECS + Fargate App Runner
Routing Table
Internet Gateway
Security Groups
Application Load Balancer
Target Group
Task Definition
Scaling Policy
App Runner Service

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.


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.

Fargate App Runner
Synchronous HTTP
Any TCP/UDP protocol
Asynchronous processing
Batch processing
Event processing
Synchronous HTTP

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.


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.

ECS + Fargate App Runner
vCPU $0.04048 $0.064
GB $0.004445 $0.007

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.

ECS + Fargate App Runner
Containers (Load) $2 $3
Containers (Idle) $34 $10
Load Balancer (ALB) $16
Total Costs $52 $13

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.

ECS + Fargate App Runner
Containers (Load) $43 $68
Containers (Idle) $14 $4
Load Balancer (ALB) $20
Total Costs $77 $72

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.

ECS + Fargate App Runner
Containers (Load) $411 $649
Containers (Idle) $7 $1
Load Balancer (ALB) $24
Total Costs $442 $650

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.


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.

By default, App Runner is only able to access publicly available endpoints

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.

By default, App Runner is only able to access publicly available endpoints

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.

A VPC connection enables the container to access resources within a VPC

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.

VPC Endpoints make sure traffic to App Runner does not flow through 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.


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.

ECS + Fargate App Runner
Service Maturity ⭐️⭐️⭐️⭐️⭐️ ⭐️⭐️
Simplicity ⭐️⭐️ ⭐️⭐️⭐️⭐️⭐️
Use Cases Request/Response, Batch Processing, ... Request/Response
Scaling Based on CloudWatch metric (CPU, network I/O, requests, ...) Based on requests per container
Sources Any container image registry Private/Public ECR, GitHub
Deployment Unit Container Image Container Image, Python/Node.js/Java project
Container Configurations 0.25 to 4 vCPU, 0.5 to 30 GB memory 1 to 2 vCPU, 2 to 4 GB memory
WAF + Private Endpoint
VPC Integration
Costs (Small Workloads) 💰💰 💰
Costs (Large Workload) 💰💰💰 💰💰💰💰💰💰
Scale down to 0

Andreas Wittig

Andreas Wittig

I’ve been building on AWS since 2012 together with my brother Michael. We are sharing our insights into all things AWS on cloudonaut and have written the book AWS in Action. Besides that, we’re currently working on bucketAV,HyperEnv for GitHub Actions, and marbot.

Here are the contact options for feedback and questions.