AWS Fargate Pricing: Cost Breakdown, Calculation, and Cost Optimization Tips

AWS Fargate allows customers to deploy containers on-demand without having to manage underlying servers or infrastructure. Customers can choose either Amazon ECS or Amazon EKS as orchestration engines to run containers on Fargate. While AWS simplifies your life by doing all the heavy lifting of provisioning and managing the underlying infrastructure, it comes at a premium.

This post aims to show the AWS Fargate pricing impact relative to a self-managed EC2 cluster. It also discusses how to estimate Fargate costs for your workloads with examples and ways to save on Fargate costs.

AWS Fargate is a serverless compute engine that allows you to run containers without having to manage servers or clusters.

When you deploy a containerized application on Fargate, you first create a task definition that specifies details, such as container images, CPU and memory requirements, networking information, etc. Fargate then takes this task definition, defines how many tasks should run, and handles the deployment and scaling of your containers for you.

Behind the scenes, Fargate uses ECS (Elastic Container Service) to orchestrate and manage the containers. ECS helps you handle container scheduling, scaling, and load balancing When a a Fargate task launches, it runs in an isolated environment with its own networking stack. This enhances security between tasks.

AWS Fargate comes with zero upfront costs and a pay-as-you-go model. You only pay for the amount of resources consumed by your containerized applications running on Amazon Elastic Container Service (ECS) or Amazon Elastic Kubernetes Service (EKS). You just need to define how much CPU resources and GB of RAM (memory resources) you would like to be available for your applications. So, you need to have an idea of ECS and EKS Fargate pricing.

AWS ECS Fargate pricing is based on several factors, which are discussed below to give a detailed breakdown of costs.

• CPU resources:

AWS charges you for each virtual CPU (vCPU) used by your workloads.

• Memory resources:

It additionally charges for the amount of GB RAM used by your workloads. The prices for CPU and memory resources vary according to operating systems and regions. For instance, the below table shows the prices for US East (Ohio) and US West (Northern California) regions.

You can check prices for all the regions here.

• Time running:

Fargate pricing is calculated from the second you start to download the container image until the ECS task or EKS pod terminates, rounding up to the nearest second. Moreover, the costs are billed per second with a one-minute minimum charge. And for Windows, the costs are billed per second with a 15 minute minimum charge.

• Storage:

AWS provides 20 GB of ephemeral storage to all Fargate tasks and pods by default. However, you need to pay for any additional storage you configure. The prices for additional storage again differ based on region.

• Additional costs:

It will incur additional costs if your container transfers data or uses other AWS services. For example, if the containers use Amazon CloudWatch Logs for logging, you will be billed for CloudWatch usage. And data transfers will be billed at the standard AWS data transfer rates.

To sum up, Fargate gives you the flexibility to separately configure CPU, Fargate memory, and other resources. So you can right-size your workloads to avoid paying for over-provisioned resources.

However, it can be difficult to estimate accurate per-hour costs due to Fargate’s pricing model. You will need a good estimate of the resources your workloads consume at different hours of the day and night, weekly, or monthly by monitoring the actual usage.

To give a simple example of how to calculate Fargate costs, you can multiply the number of tasks you want to run with the amount of vCPU and GB each task will require.

Let’s say you have a Fargate task configured with 2 vCPUs and 2 GB of RAM. The cost of running the task per hour as per US East (Ohio) pricing would be (2 * $0.04048) + (2 * $0.004445) or $0.08985. Now, let’s say you have a Fargate service running 5 of these tasks. Your cost for the Fargate service would be (5 Tasks * $0.08985) $0.44925 per hour.

Consider the below example for a detailed calculation:

Your Fargate service uses 5 ECS tasks that run for ten minutes daily for a month. Each task requires 1vCPU, 2GB memory, and 30GB storage. If you are using Linux/X86 for US East (N. Virginia) pricing, your monthly costs will be calculated as follows:

CPU charges = (number of tasks) x (vCPUs) x (price per CPU-second) x (CPU duration per day in second) x (number of days)
Monthly vCPU charges = 5 x 1 x 0.000011244 x 600 x 30 = $1.01

Memory charges = (number of tasks) x (memory in GB) x (price per GB) x (memory duration per day in second) x (number of days)
Monthly memory charges = 5 x 2 x 0.000001235 x 600 x 30 = $0.22

Ephemeral storage charges = (number of tasks) x (additional ephemeral storage in GB) x (price per GB) x (memory duration per day by second) x (number of days)
Monthly ephemeral storage charges = 5 x 10 x 0.0000000308 x 600 x 30 = $0.03

Monthly Fargate compute charges: $1.26 ($1.01 + $0.22 + $0.03)

AWS also has a pricing calculator named AWS Cost Calculator that you can use to chalk out estimates for your serverless project.

What if we told you that you could get a greater ROI on your Fargate implementation? Yes! AWS offers two ways for businesses to save costs with Fargate, which we will discuss below. We will also discuss best practices you can employ to save Fargate costs by optimizing Fargate usage, better workload management, and eliminating wasted resources.

AWS introduced Fargate Spot to reduce costs with Fargate. It offers cheaper rates because your container workloads will run on the spare capacity available in AWS. The only drawback is that you will get only two minutes after AWS notifies you that it needs the capacity back.

Therefore, Fargate Spot can suit fault-tolerant or interruption-tolerant workloads and website or API servers as they normally process short-lived requests. It is also ideal for parallelizable workloads such as image rendering, Monte Carlo simulations, or genomic processing.

Moreover, you can configure your Fargate services strategically in the capacity provider to improve cost-efficiency. For instance, you can specify a minimum number of tasks that should run at all times on regular Fargate containers. And then add tasks to run on Fargate Spot when spare capacity is available. Fargate Spot automatically scales up or down as per the availability.

You can also have multiple capacity providers as shown below. Let’s say if you want to run six copies of a container, you can distribute half of them to Fargate on-demand and the other half to Fargate Spot instances.

Below is a comparison between on-demand Fargate pricing and Fargate Spot pricing for the US West (Northern California) region.

For instance, Vanguard saved thousands of dollars on Amazon ECS and Fargate bills after adopting Fargate Spot on a large scale. Its applications can automatically run on available spare capacity without any interference from development teams. As a result, it reduced unit costs by 50%.

Another option from AWS to save costs are AWS Savings Plans. It offers lower prices compared to on-demand rates with a flexible pricing model. With Savings Plans, you commit to a specific amount of compute usage measured in $/hour for a one-year or three-year period.

In exchange, the plans will automatically apply to your Fargate usage and allocate resources regardless of instance family, size, OS or tenancy, or region. So you can shift your workloads from EU (London) to EU (Ireland) at any time and automatically with the Savings Plans.

Moreover, you can choose to pay in part or pay the full amount upfront to get an additional discount. Overall, you can reduce your Fargate costs up to 66% with compute savings plans. The percentage of savings may vary depending on your commitment term, region, and payment option.

Below is a comparison between on-demand pricing and Compute Savings Plans pricing for AWS Fargate (US West Northern California region).

Simform helped an online automotive information platform achieve cost and performance optimization using AWS Fargate Spot and Savings Plans. Compared to Fargate pricing, it saved nearly 30% of costs with Fargate Spot. And later, the company also started using Savings Plans with the motivation of not being bound to a particular instance type or region. Thus, it saved a hundred thousand dollars in less than a year due to Savings Plans and Amazon EC2 Spot Instances.

Too often, applications are built with arbitrary configurations used for a Fargate task. It results in overprovisioning for the Fargate task and unnecessary charges. Thus, right-sizing your resources can help optimize Fargate usage and reduce costs.

You can conduct load testing for applications running on Fargate to understand how task configurations perform under a given load scenario. It helps you fine-tune the vCPU, memory allocation, and Fargate autoscaling policies for the tasks in a way that balances performance and costs. You can also use CloudWatch or AWS’s cost explorer to gain insights into Fargate usage and costs.

It is another tool to ensure that clusters (an ECS cluster is a logical grouping of tasks/services) are not scaling unnecessarily to optimize Fargate costs. Similar to right-sizing resource configurations, you can fine-tune Fargate autoscaling in Fargate service configurations for cost optimization.

Scheduled autoscaling: You can implement it using the scheduled scaling configuration that is available in both ECS and AWS Fargate. For instance, you can set up a schedule for Fargate services to stop running during off-business hours and weekends. It can be highly cost-effective to have an automated schedule in place to scale down services and back up when developers are working with the services.

Moreover, you can also leverage task scheduling if you have Fargate tasks operating in a batch processing architecture pattern. You can run tasks on a cron-like schedule or write your own custom scheduler.

Other types of scaling offered by AWS Fargate are:

Target tracking: It is when you increase or decrease the number of tasks run by your services based on a target value for specific metrics. For example, you might want to target 75% CPU utilization for a CPU-intensive service and have a target tracking configuration to maintain the metric

Step scheduling: It is when you increase/decrease the number of tasks in a Fargate service based on a set of scaling adjustments. Also called step adjustments, they vary based on the size of the CloudWatch alarm breach

However, a particular scaling policy may work well for one service but not another. Thus, it should be viewed on a case basis for maximum efficiency.

Tagging your Fargate or ECS resources can give increased visibility into your workloads. You can tag services, task definitions (describes docker containers with information such as the docker image name, CPU, memory), tasks, clusters, and container instances. You can potentially uncover running resources that otherwise you may have not known about. Or it can also help identify orphaned resources that result in unnecessary charges and contribute to cloud waste.

Thus, tagging enables you to allocate costs optimally and easily search/identify resources for your containerized applications. Without tagging, it is challenging to manage containers, the entire infrastructure, and costs in a systematic manner as it is spread across different teams, products, business units, and environments. Moreover, it helps implement programmatic infrastructure management actions (like scale in) and define fine-grained resource-level permissions.

You can also monitor the tagged resources through the AWS Billing and Cost Management console. It can help manage costs better and evaluate the breakdown of your costs or resources.

Container-based applications running on Amazon ECS using Fargate or EC2 typically require exposure to both internal and external clients in the AWS cloud. Such architectures increase operational complexity as well as costs.

However, with Multiple Load Balancer Target Group support for ECS, you can attach multiple target groups to a single ECS service running on Fargate or EC2. (Target groups are used for routing requests to one or more targets when using load balancers.) It allows you to maintain only one service instead of two to serve traffic from internal and external load balancers. As a result, it simplifies infrastructure code and reduces Fargate charges.

The above-mentioned cost optimization tips aren’t suitable for a one-size-fits-all approach. You must review each best practice individually for your specific workloads to find the right one. And rather than an either-or selection, you can mix up the strategies so they complement each other and contribute to cost reductions collectively.

Lastly, you can achieve both cost-efficiency and improved performance if you choose the right Fargate use cases. When it comes to pricing, whether Fargate is the best choice for you or not is subjective to the use cases and what you are optimizing for. If you want to hand off container infrastructure management to AWS with Fargate, the following use cases can be a good fit if you want optimized performance with cost-efficiency.

• Workloads that have little or no idle time, since Fargate applies 1-minute minimum charges
• Large workloads optimized for low overhead: If you have large clusters to manage, it can be challenging to ensure all are patched, secured, and updated to the latest Docker version. Fargate launch type works great for eliminating the overhead of cluster management and cluster scaling.
• Small workloads with occasional bursts: Fargate can be a great choice if your workloads are small but burst during the day and have low traffic at night. You can right-size your Fargate configurations and auto-scaling policies accordingly to save cost.
• Tiny/microscale workloads that need small test environments can do better with Fargate since EC2 instances are too powerful for such workloads and will not be fully utilized
• Batch workloads that consist of periodic tasks that run for one hour or other occasional jobs

Businesses need to consider several factors when choosing a particular service (in this case, AWS Fargate), such as performance, ease of development, pricing, scalability, security, etc. If it checks most of your boxes, including your use case, you can always optimize AWS Fargate pricing with the techniques discussed in the blog.

Simform is an Advanced AWS Consulting Partner helping businesses build robust applications in AWS while reaping the benefits of cloud and serverless in a cost-efficient way. If you need further assistance making the right technology choices that align with your business goals, speak to our experts today and get a free consultation for your serverless application project.