EP179: Cost optimization on Amazon ECS and AWS Fargate

In this episode of the AWS LATAM Podcast I talked with David Ugarte, a solutions architect at AWS, about how to optimize costs when running containers on Amazon ECS and AWS Fargate. It’s something I see daily in my role as a Technical Account Manager: small decisions about sizing, scaling, and pricing model that, added up, have a big impact on the monthly bill.

This article captures and organizes what we covered in the episode. If you’d rather listen, the players are above. The episode is in Spanish.

First, some context

Amazon ECS is a container orchestrator: you take a containerized application — a Docker container — and deploy it to the cloud as a backend service. Fargate is the ECS option that lets you do this without managing servers, that is, in a serverless way: you don’t administer the underlying instance, AWS handles that.

On that foundation, the conversation followed the Cloud Financial Management framework, the AWS strategy for managing cloud finances. The idea is simple in structure: first identify where costs come from, then optimize them.

Visibility: knowing where costs come from

You can’t optimize what you don’t measure. The starting point is two tools:

Cost Explorer: available in the AWS console, it gives you a graphical interface to visualize and understand costs by service and by account. For ECS, from the services menu you pick Elastic Container Service, and in the dimension you can use Linked Accounts to see which accounts consume the service, or the usage type to know how many vCPUs and GB of memory your tasks consume.
Cost and Usage Report (CUR): for deeper analysis. It publishes detailed usage reports to an S3 bucket, and then, via Amazon Athena, you can run SQL-style queries to reach whatever level of detail you need.

Tagging: business context on top of costs

Cost Explorer becomes far more useful when resources are tagged. In ECS you can tag tasks, services, task definitions, clusters, and so on.

The recommendation is to define a tagging strategy before you start: tag all the resources of a workload with things like the application name, the project it belongs to, the environment (production, development), and the cost center. With that you can filter by tag and know exactly how much a specific project or application costs, which enables better chargeback reporting back to the business units.

Right-sizing: matching tasks to what they actually use

The cost of ECS on Fargate depends directly on how much vCPU and how much memory your applications consume. That’s why the first technical saving is to size things well.

The method: go to Amazon CloudWatch, and in the ECS metrics section review the real CPU and memory usage of your deployed tasks. With that historical information, adjust the task definition to the size they really require — no more, no less.

Auto Scaling: paying according to demand

Once you know the real requirements and have adjusted the task definition, Service Auto Scaling lets you define a minimum and a maximum number of running tasks.

The benefit is clear with workloads that vary throughout the day. If your application has little traffic at night, Auto Scaling reduces the number of tasks to the minimum during that period; when users arrive during the day, it scales up and adds tasks up to the maximum you defined. That way the infrastructure follows real demand and you pay accordingly.

Fargate vs. EC2: where the cost difference lies

The pricing model sounds similar to EC2, but there are two key differences:

Payment granularity: with EC2 you pay for the full size of the instance you choose, and it’s your responsibility to get as close as possible to what you need. With Fargate you only pay for the vCPU and memory the task consumes during the time it’s running.
Operational cost: managing instances has a cost. With EC2 you can access the instance, but it’s also your responsibility to administer and patch it. With Fargate you don’t have access to the instance, and AWS takes on that management.

Pricing options: On-Demand, Savings Plans, and Spot

With the technical side covered, the commercial options come next:

On-Demand: the default and most common price. You pay for resources only during the time you use them. Ideal when you don’t want to commit to anything.
Savings Plans: if you’re going to use compute for an extended period (from one to three years), you can get up to a 50% discount off the On-Demand price in exchange for a usage commitment.
Spot: you use compute capacity available in the Region and Availability Zone, with up to a 70% discount off the Fargate price. The trade-off is that AWS may reclaim that capacity with two minutes’ notice, so your applications must tolerate interruptions. It fits very well with stateless containers: a container can shut down and be recreated with no impact on users.

A note on the number: the 70% applies to Fargate Spot. If instead of Fargate you run ECS on EC2 instances, you can use EC2 Spot, which goes up to a 90% discount off the EC2 On-Demand price — in exchange for managing the instances yourself. They’re two distinct options with different figures.

Details that slip through: load balancers

Two specific recommendations that often go unnoticed:

Share the load balancer across multiple ECS services. Many customers use one load balancer per service, which inflates costs unnecessarily.
Detect orphaned load balancers. Ones that were created and are no longer used still generate cost on the monthly bill.

To dig deeper

If you want to put this into practice, two workshops I recommended in the episode:

Well-Architected Labs — covers the pillars of the Well-Architected Framework, including cost optimization.
ECS Workshop — to dive into the features and options of Amazon ECS.

And to keep up with new releases, the AWS Blog and What’s New with AWS. If you have a support plan, remember you can always open a ticket for help on this or any other topic.