AWS Container Orchestration 2: App Runner vs ECS Fargate
Introduction
I previously wrote about AWS App Runner and how it is an amazing tool for application deployment. How it makes deployment of containers and applications easy and smooth, with little or no DevOps and deployment knowledge needed. In this article, I shall compare App Runner and ECS Fargate.
Both technologies have a lot of things in common; they both do not require any server setup or configurations. This article will try to explain the different workings of the technologies, draw their similarities and differences, and suggest when to use which over which. As I have mentioned in my previous LinkedIn post, no technology or service is perfect, we use them based on what they were built for. Without further ado let us get right into comparing AWS App Runner with Amazon ECS Fargate.
I did a similar article here; where I compared EKS and ECS, the same format shall be used in this comparison with some extras. To ride on what was done before. We shall not be going through the basics again because that has been done here for AppRunner and here for ECS.
In this article, we shall be making a comparison between these two container orchestration AWS services as we have done in the past, where we compared Amazon EKS to Amazon ECS.
Why Compare?
Solutions Architects and DevOps engineers can find it hard to choose between AWS technologies mostly when it looks like both technologies look very similar and do almost the same thing. They are caught between which to use. Comparing both technologies will help hasten this decision because it summarizes the similarities and differences between both technologies and makes it easier for the architect or engineer to choose what is more appropriate for their project.
Comparison Metrics
Certain metrics shall be used to explicitly compare both services to give us a more transparent view of each of the services. This is the list of metrics that shall be used to compare both services:
- Components
- Ease of Deployment
- CD integration
- Observability
- Cost
- Components
Components
This criteria compares the components that both services are made up of, and what it needs to run a container in its smallest unit.
App Runner: We can say for free that App Runner has no components that determine how it runs. All that is needed to deploy an application in App Runner is to follow the wizard steps for configuring a service. Configurations such as service name, compute requirements, image configuration (though it supports ECR-based images), environment variables, and more are all done via JSON CLI configuration. But it does not require you to understand these things to deploy and run a container in AWS App Runner.
ECS: From the previous comparison of ECS vs EKS. ECS is made up of different components that need to be configured to successfully deploy an application. These components are:
- Cluster
- Task Definition
- Task
- Service
Each component has a unique contribution to making a container run in an ECS setup. It requires understanding each of these components to be able to deploy and run an application in Amazon ECS Fargate.
Ease of Deployment
This criteria will compare the steps taken to make a deployment and compare the difference between App Runner and ECS Fargate.
App Runner: It has a wizard that allows you to automatically connect your Git repo to the App Runner service and automatically builds and deploys the application into the App Runner service. This wizard contains parameters such as deployment name, resources needed (CPU, Memory), environment variables, and more. The same wizard can be used for container and non-container-based applications. For Docker-based workload, it will require that the image is stored in an ECR public or private registry before it can be deployed. When the application is deployed successfully, AppRunner generates a custom URL from which the application can be accessed and available for use. Any new changes will require an image update which will automatically re-deploy the service. When the deployment is successful, it means the application changes have been applied.
ECS Fargate: Every deployment requires a task JSON configuration called a Task Definition. This defines all the parameters needed for the deployment. From the resources needed (CPU, Memory), to the name of the service environment variables and everything the service needs to run appropriately. A service or task is created from the task definition, the service is attached to an AWS Load Balancer (Classic, Application, or Network) before it is accessible over the internet. Any new changes require a new task definition to be created and the tasks where the service is running must be updated. Unlike App Runner, the components ECS Fargate needs to run are other AWS services.
CD Integration
In Continuous Delivery integration, we are trying to compare how well each service integrates with a CD service as AWS CodePipeline.
App Runner: AppRunner does not have any CD integration out of the box. CI/CD tools such as Github Actions, and Gitlab CI can be used to automate deployment to AppRunner. However, the challenge with the setup is that App Runner does not give proper feedback on the status of the deployment whether it was successful or failed. Although AppRunner manages rollback on its own, meaning that when a successive deployment fails prior to a successful deployment, Apprunner is able to revert to the last working deployment.
ECS: This has integration with the CI/CD tools mentioned in AppRunner and an even deeper integration with CodePipeline and CodeDeploy. When CodeDeploy is used to manage deployment for ECS, it is able to track the status of a deployment and manage the rollback of that deployment on ECS. ECS also has a circuit break feature of not allowing a successive failed deployment to receive traffic, instead, it keeps it pending and allows traffic only to the previous successful deployment.
Observability
How easy is it to observe the status of a deployed application? How easy is it to view logs, and metrics and integrate traces?
App Runner: Observability in AppRunner is more out of the box with little or no configuration (this applies to metrics and logs). Although all the backend infrastructure is Amazon Cloudwatch. AppRunner has a mini-interface that makes it easy to see the logs and metrics without necessarily going to Cloudwatch Console. But for a more advanced log search, the user might need to jump over to CloudWatch to do that. Traces in App Runner require code integration and configuration with Amazon X-Ray. It also has some interesting service metrics; such as Request Count, and HTTP response count as shown in the following screenshot.
ECS: Very similar to App Runner, ECS uses Amazon Cloudwatch as its backbone for logs and metrics storage. Similar to App Runner it gives a mini-interface for viewing logs, and metrics. The observability dashboards in ECS are a little less than App Runner. Request Count and HTTP response count are more on the Load Balancer metrics which requires navigation to the Load Balancer console dashboard to view these metrics. Amazon X-Ray can be integrated into ECS, in the same way it is integrated into App Runner.
In both cases, no extra configuration is required to get application logs and infrastructure metrics (CPU, Memory, and Disk).
Cost
Which is more expensive and which is more affordable? For this to be fair, we shall use the same specification to compare the cost of running AWS App Runner and Amazon ECS. The specification we shall use is 1GB of RAM and 1vCPU.
App Runner:
Compute Cost:
- vCPU: $0.064 per vCPU-hour
- Memory: $0.007 per GB-hour
Provisioned Container Instances: This includes the base cost for having the service running, even if no requests are being processed.
Request Cost: There are additional charges based on the number of requests your service handles and the amount of data processed.
Example Calculation for 1 Month
Assuming the service runs continuously for a month (30 days), the cost would be calculated as follows:
vCPU Cost: 1 vCPU * 24 hours/day * 30 days/month * $0.064/vCPU-hour = $46.08
Memory Cost: 1 GB * 24 hours/day * 30 days/month * $0.007/GB-hour = $5.04
Total Monthly Cost: $46.08 (vCPU) + $5.04 (Memory) = $51.12
ECS:
Amazon ECS Fargate pricing is based on the amount of vCPU and memory resources consumed by your containerized applications. The pricing is as follows:
Compute Cost:
- vCPU: $0.04048 per vCPU-hour
- Memory: $0.004445 per GB-hour
Example Calculation for 1 Month
Assuming the service runs continuously for a month (30 days), the cost would be calculated as follows:
vCPU Cost: 1 vCPU * 24 hours/day * 30 days/month * $0.04048/vCPU-hour = $29.11
Memory Cost: 1 GB * 24 hours/day * 30 days/month * $0.004445/GB-hour = $3.20
Total Monthly Cost: $29.11 (vCPU) + $3.20 (Memory) = $32.31
This ECS cost excludes the cost of a load balancer which is required if the service is over HTTP and needs to be accessed. AWS Load balancer cost ranges from $16 to $18 per month. This will make the total cost range from $48 to $50.
Conclusion
The goal is to show the similarities and differences between these two, and also show they both have their strengths and weaknesses. Sometimes, when you need to quickly deploy a Docker image, without managing everything end-to-end; AWS App Runner takes the lead. But, if you need to be in control of the nitty-gritty components, and still maintain Serverless, then Amazon ECS Fargate wins in that scenario.
