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

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.

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
VPC
Subnets
Routing Table
Internet Gateway
Security Groups
Application Load Balancer
Target Group
Cluster
Task Definition
Service
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.


Looking for a new challenge?

  • DEMICON

    Senior Lead Cloud Solutions Architect AWS

    DEMICON • AWS Advanced Consulting Partner • Remote (Europe)
    GitLab Terraform K8s EKS Lambda Python Go
  • tecRacer

    Cloud Consultant • Machine Learning & Data Analytics

    tecRacer • Premier AWS Consulting Partner • Germany, Austria, Portugal, and Switzerland
    SageMaker Airflow Athena Redshift

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.

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.

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.

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.

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.

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.

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.

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
SLA

Become a cloudonaut supporter

Andreas Wittig

Andreas Wittig ( Email Twitter LinkedIn Mastodon )

We launched the cloudonaut blog in 2015. Since then, we have published 366 articles, 60 podcast episodes, and 58 videos. It's all free and means a lot of work in our spare time. We enjoy sharing our AWS knowledge with you.

Please support us

Have you learned something new by reading, listening, or watching our content? With your help, we can spend enough time to keep publishing great content in the future. Learn more

$
Amount must be a multriply of 5. E.g, 5, 10, 15.

Thanks to Alan Leech, Alex DeBrie, ANTHONY RAITI, Christopher Hipwell, e9e4e5f0faef, Jason Yorty, Jeff Finley, jhoadley, Johannes Grumböck, Johannes Konings, John Culkin, Jonas Mellquist, Jonathan Deamer, Juraj Martinka, Ken Snyder, Markus Ellers, Oriol Rodriguez, Ross Mohan, Ross Mohan, sam onaga, Satyendra Sharma, Simon Devlin, Thorsten Hoeger, Todd Valentine, Victor Grenu, waldensystems, and all anonymous supporters for your help! We also want to thank all supporters who purchased a cloudonaut t-shirt.