All Posts 
Blog Post
This blog post is part of a continuing series aligned with the AWS Well-Architected Framework. In this post, we’ll explore AWS Fargate in the context of operational excellence, performance efficiency, and cost optimization — three pillars of the Well-Architected Framework.
In a nutshell, Fargate enables you to focus less on servers and more on your core applications — helping to scale faster, reduce human error, and enable consistent responses to events. What’s more, it uses automation effectively in container orchestration to address capacity requirements. Let’s look at Fargate in more detail to answer some key questions.
Image 1. Amazon ECS vs. AWS Fargate architecture. (Source: AWS)
So what is AWS Fargate?
- AWS Fargate is a technology for Amazon ECS and Amazon Elastic Container Service for Kubernetes (Amazon EKS) that allows you to run containers without having to manage servers or clusters. It is a container orchestration solution that makes it easier to deploy, manage, and scale containerized applications.
How is it different from current ECS-EC2 or AWS Lambda?
- Fargate is AWS technology to run containers and it can be orchestrated by ECS. It eliminates the need to manage the infrastructure to run a containerized application. There are some key differences in pricing and scalability.
Pricing
- ECS charges for the underlying resources provisioned to support your application. So if you provision two m4.xlarge EC2 instances for running your containerized application, you’ll be charged for them.
- Fargate charges based on the memory and CPU required to run a task as well as the time that the task runs, by second and a minimum of 1 minute. If you launch complementary resources, (e.g. load balancer), you’ll be charged for that as well.
- Lambda is similar to Fargate in that you are charged by memory and CPU utilized, as well as compute time. This service is more limited but removes completely the need to support all infrastructure, worrying only about the application code. You are charged for every 100ms that your code executes and the number of times your code is triggered. You don’t pay anything when your code isn’t running.
Scalability
- ECS helps you scale your application by configuring an Auto Scaling Group, which is the conventional way to set an auto scale policy for your EC2’s. Also, you can use AWS Automatic Scaling Service. In terms of performance, when you scale your ECS service, you have to wait until a new EC2 instance is deployed to launch a new task in that instance.
- Fargate manages that part for you. It has its own fleet of EC2’s ready for your tasks to be launched, so you can provision tens or tens of thousands of containers in seconds.
- Lambda automatically scales your application by running code in response to each trigger. Your code runs in parallel and processes each trigger individually, scaling precisely with the size of the workload.
What’s the motivation to move to Fargate?
- Easy management —no clusters to manage.
- Seamless scaling —you can launch tens or tens of thousands of containers in seconds.
- Agility —you gain agility by focusing on designing and building your applications instead of managing the infrastructure that runs them.
- Security —you can assign different security groups to each task, which gives you more fine-grained security.
How much time is required to shift from current ECS-EC2 to Fargate?
- Migrating a containerized application that is currently orchestrated by AWS ECS to Fargate can appear to be a fairly simple task since Fargate sits on top of the ECS API, just managing your EC2’s for you.
- However, the reality is a bit different. When you decide to make the shift, be aware that changes are needed to various application layers (described below). You’ll need to make changes to:
- Task definitions
- Service definitions
- Cluster infrastructure
- CI/CD pipeline
- So this is not a trivial migration — you’ll need to restructure your application(s), so scope the time (a couple of days to a few weeks or more depending on app size), and have the knowledge to perform the correct changes without compromising the application.
What are the cost and performance advantages between ECS and Fargate?
- We made some calculations between a classic ECS deployment and Fargate deployment to compare cost charges that you can expect in a real-world example. The original scenario consists of:
- ECS cluster with 342 running tasks
- 26 container instances of type m4.xlarge
- Instances come with 4vCPUs and 16GB of memory each and cost $0.2 per Hour.
- We’re assuming the values remain constant during the month (for calculation purposes), and we’re using the usage percentages from the screenshot below:
Image 2. ECS-EC2 cluster used for calculations.
ECS cost
To calculate the cost of a classic ECS cluster you just need to calculate the monthly charge of the EC2 container instances being provisioned. We did this pretty easily since AWS provides a handy calculator where you just input the values and it gives you the results:
$3,806.40 $/month for an ECS-EC2 cluster
Fargate cost
Fargate charges for provisioned memory and CPU for the tasks, so first we calculated the total amount used for each resource:
Memory in use: 26 instances * 16GB * 46.95% utilization = 195.312GB CPU in use: 26 instances * 4vCPU * 1.29% utilization = 1.3416vCPU
So with CPU, you have the lowest usage, so we gave each task 0.25vCPU, which is the minimum, and for memory, we used 0.58GB, which is not a valid parameter but we can get really close by mixing 1GB and 0.5GB tasks to get close to the used memory value.
* Assumed configuration for tasks: 0.25vCPU & 1GB
Monthly CPU charges:
342 tasks * 0.25vCPU * 0.00001406 $/s * 2,592,000s = $3,115.92
Monthly memory charges:
342 tasks * 1GB * $0.00000353 * 2,592,000s = $3,129.22 342 tasks * 0.5GB * $0.00000353 * 2,592,000s = $1,564.61 342 tasks * 0.58GB * $0.00000353 * 2,592,000s = $1,814.95
We made calculations with 1GB and 0.5GB per task as well, and the values are shown above. We used the 0.58GB calculation to get the total charges for this deployment type:
Total charges:
$3,115.92 + $1,814.95 = $4,930.87
| Scenario | ECS | Fargate |
|---|---|---|
| Use case with a real client implementation | 3,806.40 $/month | 4,930.87 $/month |
We can see that Fargate, calculating only on the used resources, is still more expensive than a normal ECS cluster with underutilized resources. It represents almost a 30% increment in cost for a similarly-sized cluster.
What are the constraints of Fargate?
- Container definition:
- LogConfiguration — If you’re using Amazon CloudWatch logs you have to set awslogs-stream-prefix for the setting to work.
- Task definition:
- Network Mode: For Fargate launch types, you can specify awsvpc only. The none, bridge, or host option won’t work for Fargate launch types.
- Define ‘Memory’ at ‘task level’.
- Define ‘Cpu’ at ‘task level’.
- Service:
- The launch type on which to run your service must be FARGATE.
- Network Configuration: It turns out that FG services must run on awsvpcnetwork configuration.
- Define ‘Memory’ at ‘task level’.
- Roles: In this case should be set to service-linked roles.
- TargetGroup:
- TargetType must be IP. By default is instance. The registration type of the targets in this target group. Valid values are instance and ip. The default is instance.
- Access to the underlying EC2 instances is not possible.
- Your container ports in a single task definition file need to be unique.
- Links are not allowed as they are a property of the “bridge” network mode.
What are the scenarios where Fargate is most beneficial?
- Fargate can be used with any type of containerized application. However, this doesn’t mean that you will get the same benefit in every scenario. Fargate would be most beneficial for organizations that need to reduce the time from development to market (faster idea-to-cash).
- Another use case for Fargate is for faster scalability in existing environments. You could have a mix of EC2 and Fargate services to make the provisioning of new tasks faster for peak usage in shorter periods of time and still get lower costs with the EC2 services.
What are scenarios where Fargate may not be the best choice?
- If you require greater control of your EC2 instances to support compliance and governance requirements, or broader customization options, then use ECS without Fargate.
How can the nClouds team help?
- The nClouds team has broad and deep experience with cloud implementations on AWS and can help create a smooth migration of applications from ECS to Fargate, or whatever your cloud migration and container requirements are. As an AWS Authorized Well-Architected Partner we will design, build and manage a solution with operational excellence, performance efficiency, cost optimization, security, and resilience.
Let’s get well architected!
1 AWS Fargate – Run Containers Without Having To Manage Servers or Clusters
https://aws.amazon.com/fargate
2 EC2 Instance Pricing – Amazon Web Services (aws)
https://aws.amazon.com/ec2/pricing/on-demand/
3 AWS Fargate Pricing – Run Containers Without Having To Manage Servers or Clusters
https://aws.amazon.com/fargate/pricing/
