Theoretical cost optimization by Amazon ECS launch type: Fargate vs EC2

This post was contributed by Julia Beck, Thomas Le Moullec, Kevin Polossat, and Sam Sanders

Customers often ask about best practices when using Amazon Elastic Container Service (Amazon ECS), in particular around the Well-Architected Framework pillar of Cost Optimization. Within this, choosing between the two different launch types, EC2 and Fargate, may be one of the biggest factors. With a price reduction of up to 50% for the Fargate launch type in 2019, and the introduction of Fargate Spot and Savings Plans, you can see substantial savings. With these considerations in mind, it can be important to understand cost efficiency patterns for the two launch types.

This blog explores the two launch types available for Amazon ECS, and compares the cost of running a fleet of ECS containers according to the EC2 and Fargate pricing pages. Note that Fargate tasks can also be orchestrated with Amazon EKS and the majority of the same considerations in this blog would apply to Amazon EKS as well. However, for simplicity, this blog solely covers the Amazon ECS deployment options and nomenclature.

It’s also important to note that, in this blog, we are making a comparison purely on a financial cost basis. Operational costs, although not included here, are an important factor, and should be included in a full cost comparison. Please refer to this blog post for specific considerations around some of these operational aspects (although the linked blog is about EKS, similar principles apply to ECS).

What are the ECS Launch Types?

Amazon ECS is a container orchestration service used to provision and manage container clusters. It allows you to quickly deploy and scale containerized workloads without having to configure, manage, and scale your own container management tool.

ECS supports two launch types: EC2, and Fargate. Container clusters can be configured using either one, or a mixture of the two, with a variety of pricing options for both launch types. With the EC2 launch type, clusters are constructed as a fleet of Amazon Elastic Compute Cloud (EC2) instances. This provides greater control over the customization of your environment. However, while you can benefit from being able to configure your infrastructure to meet your needs (such as choosing network optimized or GPU optimized instances), you are also responsible for upkeep, including patching, instance type selection, networking, and environment security of your instances.

With the Fargate launch type, you can concentrate on developing and maintaining your containerized applications, with the underlying servers abstracted. Fargate removes the need to provision and manage servers. Instead, you simply specify the resources per task, which also improves security through application isolation by design. ECS then communicates with Fargate to launch, run, and manage the containers on your behalf.

Comparative pricing

The pricing for the EC2-based launch type is fixed to the memory and capacity provisioned for a chosen instance type. You pay for a full instance regardless of how much of it is being used by the workload. In comparison, Fargate gives an alternative where pricing can often more closely match resource requirements. Fargate workloads are charged for the CPU and memory consumed for a single task, and AWS manages the allocation of these tasks on the underlying infrastructure. Up until a certain threshold, pricing specificity provided by Fargate becomes more cost effective over an EC2-based launch. However, there comes a point where managing your own EC2 fleet is more cost effective than using Fargate. Defining these boundaries is the focus of this post, but bear in mind that you are not limited to an either/or choice, you can use both simultaneously, via Amazon ECS Capacity Providers.

In this post, we will start with a theoretical comparison of the price of running an m5.8xlarge EC2 instance and the price of running a Fargate cluster with equivalent compute and memory. The m5.8xlarge general purpose instance type is a popular choice to run containers, but note that the conclusions discussed later are general, and can be applied to multiple workloads and instance families.

As outlined on the Fargate pricing page, the Fargate launch type is based on the size of the task. The amount of vCPU and memory that can be requested for a given task definition are limited by configurations supported in Fargate, and have a corresponding cost. The supported configurations are as follows:

Note here that we are assuming no over-subscription for the EC2 launch type, and that 100% utilization is possible with the EC2 based launch. This, in practice, however, is a very strong and unrealistic assumption, and would require a perfect bin-packing strategy. Read more about over-subscription and task placement strategies.

It is important to make these simplifying assumptions here because there are operating and other costs with the EC2 launch type. For example, with the EC2 launch type, you may need to put time and effort into managing the scaling of your fleet and the configuration of the machines (including instance type and size, disks, etc). In the scenario of a fluctuating load on your fleet, achieving an optimized EC2 configuration that would provide you with the cost benefits seen below might present challenges not captured in this comparison. Additionally, with the EC2 launch type, Amazon EBS storage is not included in the cost, whereas with Fargate, it is included. These points should be taken into account in a full cost comparison.

This section compares the theoretical cost of running a Fargate cluster of eight tasks to the cost of running a single EC2 instance size with the vCPU and memory capacity to run all eight identical tasks on one machine. The single instance serves for comparison purposes only; a best practice is to use multiple instances distributed across multiple Availability Zones, as having 4 m5.2xlarge would cost the same as one m5.8xlarge and would increase redundancy.

The eight tasks running on this instance will use only a proportion of its capacity, depending on the size of the tasks. This post will refer to this proportion of the EC2 resources being used as CPU Reservation Rate for compute, and Memory Reservation Rate for memory, calculated as follows:

• Memory reservation rate = (number of tasks * memory per task) / (memory available for EC2 instance)
• CPU reservation rate = (number of tasks * vCPU per task) / (vCPU available for EC2 instance)

On each of the following graphs, for a given memory and vCPU reservation rate, the y-axis refers to the percentage by which Fargate is more cost optimized than EC2. If above zero, Fargate is more cost optimized than EC2, if less than zero, the opposite is true. Calculations were performed across the full range of compute values supported for Fargate task definitions (0.5 vCPU, 1 vCPU, 2 vCPU, and 4 vCPU), with their corresponding memory configurations:

Taking the first bar on the left as an example, Fargate has a 87% saving over an EC2 equivalent, when the EC2 memory and vCPU reservation rate are at 6.25% and 12.5% respectively. At the other extreme, when the EC2 is fully utilized, the EC2 launch type sees over 20% price savings.

As can be seen, the advantage of Fargate launch types decreases as the compute and memory usage approaches the capacity of the instance. For steady-state, predictable workload levels that use a higher proportion of the instance CPU and memory, EC2 can be a more cost-effective choice, as it is possible to simply select the instance type for which tasks can optimally use the available resources.

For highly dynamic workloads where right-sizing and scaling EC2 infrastructure introduces the risks of under/over-provisioning, the flexibility in cost and operation provided by Fargate would be beneficial.

Further pricing option

For sustained, predictable tasks, a highly utlilized EC2-based launch could help to optimize costs, since the instance type best suited for the required task capacity can be selected at a lower cost than Fargate with the same capacity. So far, however, we have only looked at on-demand offerings. Savings Plans can further reduce the costs required for maintaining a continuous workload using both EC2 and Fargate by committing to a certain level of compute usage for either 1- or 3-year periods. We will explore how Savings Plans impact the two launch types next. Note that the same savings plan applies to both EC2 and Fargate; customers don’t need to subscribe to different savings plans.

This diagram shows the difference between Savings Plans for EC2 and Savings Plans for Fargate pricing with 3-year Savings Plans full upfront discounts. With reserved compute capacity and higher CPU utilization, the percentage by which EC2 is more cost optimized is greater than without Savings Plans. In circumstances where a set level of compute can be predicted, leveraging the cost reductions through Savings Plans can further optimize costs for EC2 launch types.

For architectures that are designed resilient to interruptions, Spot instances can be valuable in additionally reducing the price of up to 70% of on-demand alternatives. Read more about using Spot to run your ECS tasks.

Above is the price difference of running the same eight-task workload using Spot pricing for both launch types. We took the spot pricing values at a single point in time, but note that since Spot pricing varies depending on long-term trends in supply and demand, the results may slightly differ in each case. When compared to the on-demand pricing, the threshold shifts again, this time in favor of Fargate-based workloads. Thus, in cases where workloads are fault-tolerant, leveraging the greater savings through Fargate Spot can further optimize costs. However, rather than viewing the choice between launch types as an either-or selection, it could be valuable to use their complementary cost contributions together.

Comparison across pricing

This graph shows a correlated view of the pricing differences between the Fargate and EC2 launch types with the different pricing options, for different memory reservation rates. As can be seen, the difference by which Fargate is more cost optimized is irrespective of the pricing plan, but differences become even more pronounced when the memory and CPU reservation rates increase. This means that, for whatever pricing plan we choose, the same conclusions seen above apply: the greater the capacity utilization of the instance, the more cost effective the EC2-based launch. However, you still benefit from further cost optimization by choosing the best pricing model for your workload.

Conclusion

In this post, we discussed the theoretical cost comparison between the two ECS launch types: Fargate and EC2. We stated the advantage of using EC2 when you can maximize cluster utilization, and the benefits of using Fargate when cluster utilization falls under certain thresholds. However, design decisions made must often also manage the tradeoff between cost and other pillars, or technical requirements. For example, the Performance Efficiency pillar could highly benefit from the EC2 launch type decision because of the several configuration possibilities (e.g. disk type, GPU). Conversely, customers can extract higher value by using AWS Fargate and optimizing around the Operational Excellence pillar, regardless of raw costs considerations. By letting container best practices guide your architectural decisions, you can implement a level balance between these pillars. As a result, the choice between one or both launch types would be highly dependent on the use case.