Discover how much Fargate Spot could save you on your AWS bill with this price comparison between 100 Fargate Spot and 100 Fargate containers.

Did you know you could save money in AWS by switching from Fargate to Fargate Spot? If you’re using ECS, Fargate Spot offers significant cost reductions by using spare capacity in the AWS cloud.

But just how much could you save? AWS say up to 70%, but we’re going to put that to the test with a head-to-head price comparison between 100 Fargate Spot and 100 Fargate containers running over 24 hours.

Fargate & Fargate Spot primer

As you may already know, Fargate is AWS’s serverless container service. Serverless means AWS take care of provisioning any resources required to run your containers, reducing the complexity of setting up and maintaining your environment. You just define how much CPU and memory your container requires, and that’s it!

You can use Fargate for many different workloads, from webservers to batch processing. What’s more, it’s competitively priced:

  • $0.04048 per vCPU per hour

  • $0.004445 per GB memory per hour

Cost example: a 0.25 vCPU and 0.5 GB Fargate container running for 24 hours would cost $0.29622 (calculated as 0.04048 * 0.25 * 24 + 0.004445 * 0.5 * 24).

This in the eu-west-1 region which we’ll be using in this article. See Fargate Pricing for costs in your region.

Fargate Spot is launched

In December 2019 AWS launched Fargate Spot. This service allows you to deploy your containers as you would normally in Fargate, but benefit from savings since your containers will be running on spare AWS capacity. The important caveat though, is you’ll only get a 2 minute warning when AWS need the capacity back.

Fargate Spot, therefore, suits workloads that can tolerate interruptions. Good candidates might be websites or API servers, since they’re normally processing short-lived requests.

The pricing for Fargate Spot looks pretty good:

  • $0.01334053 per vCPU per hour

  • $0.00146489 per GB memory per hour

Comparing this with the standard Fargate pricing that’s 67% cheaper for both CPU and memory. That could make a big difference right?

Fargate Fargate Spot Fargate Spot saving
CPU $0.04048 $0.01334053 67%
Memory $0.004445 $0.00146489 67%

Cost example: a 0.25 vCPU and 0.5 GB Fargate Spot container running for 24 hours would cost $0.09762186 (calculated as 0.01334053 * 0.25 * 24 + 0.00146489 * 0.5 * 24).

Fargate & Fargate Spot price comparison

Never one to take things at face value though, I think it’s wise to put this pricing to the test. For anyone operating at scale, the savings could be significant. Let’s prove this by running a small experiment:

  1. we’ll launch 100 containers in Fargate mode

  2. we’ll launch 100 containers in Fargate Spot mode

  3. we’ll leave these containers running for a full day

  4. we’ll check the AWS bill and compare the numbers

To do this, we’ll be using AWS Elastic Container Service (ECS). This is a container orchestration service, comprising:

  • task definitions which describe your Docker container, with info such as the image name, CPU, and memory

  • tasks which are running containers using a specific task definition

  • services which manage tasks of a specific task definition, including making sure the correct number are running

Capacity provider strategy

The way you launch a container in Fargate Spot mode is by setting a specific capacity provider strategy. This strategy defines how ECS decides which of the following two capacity providers to use for your container:

  • FARGATE

  • FARGATE_SPOT

A basic strategy might be to configure 100% of your tasks launched from an ECS service to be either FARGATE or FARGATE_SPOT. You can mix it up using more complex strategies. For example, you might define a strategy that sets a minimum number of ECS tasks to launch with FARGATE and the rest with FARGATE_SPOT.

We won’t go into the fine details of all the different configurations in this article, but this is how an ECS service’s capacity provider strategy looks in the AWS Console.

This strategy means that all ECS tasks will launch in the FARGATE_SPOT mode. You can define a capacity provider strategy when creating or updating an ECS service.

Setting up an ECS environment

To run this experiment we’ll create two ECS services in an ECS cluster:

  1. fargate-service where we’ll launch 100 ECS tasks with the FARGATE capacity provider

  2. fargate-spot-service where we’ll launch 100 ECS tasks with the FARGATE_SPOT capacity provider

Each service will have a specific capacity provider strategy, ensuring that tasks are always launched in the correct way.

For the ECS task we’ll run, we can choose any Docker image as long as it’s a service that starts and stays up indefinitely (we want to maintain 100 ECS tasks per service consistently). In this case I’ve gone with NGINX, which is a load balancer service that returns a 200 OK response when you make a request to it.

In AWS ECS before you launch a task (i.e. a container) you need to create a task definition. This is how the task definition’s container definition looks in the AWS console.

The task definition must specify the CPU and memory, which can be chosen from the supported configurations of the Fargate pricing docs.

As fun as it might be to choose the beefiest configuration, I want to be able to eat this weekend so I’ll go with 0.25 vCPU and 0.5 GB memory. This is how it looks in the AWS console in the task definition details page.

Launching 200 containers

If you haven’t launched 100 containers in an ECS service before it’s pretty straightforward. You just update the service and set number of tasks to 100, then watch the magic happen.

It takes a few minutes for all the ECS tasks to start, but AWS will get there eventually.

100 ECS tasks. Count them if you like :)

You can even click on the task id to go through to the task details. This is useful if you want to know if a task is running in Fargate Spot or not.

I followed the same scaling procedure in both the fargate-service and fargate-spot-service. Here’s how the services look now.

Each service has 100 desired and 100 running tasks. Now to wait and incur some costs!

Cost analysis in Cost Explorer

Dates reported in AWS billing are based on the UTC time zone. I’m in the UK, so I left the containers running for 24 hours from midnight to midnight.

After this I went into Services > AWS Cost Explorer > Cost Explorer and created a new report by:

  • applying a filter on Service for EC2 Container Service (another name for ECS)

  • setting Group by to Usage Type

  • changing the time period to the specific day

The shows that Fargate CPU was the biggest expense, followed by Fargate Spot CPU which was much cheaper. Likewise, Fargate memory was more expensive than Fargate Spot.

Drilling into the costs, the total for all 200 containers was $34.85. Here you can see the CPU and memory values for each capacity provider.

If we do a Group by on Purchase Option we can see a direct comparison of Fargate Spot vs. Fargate.

From this I can calculate the saving:

((25.92 - 8.93) / 25.92) * 100

This shows us that Fargate Spot has saved us 66% of our costs compared with Fargate!

That’s almost exactly the same as the 67% I had calculated based on information from the Fargate pricing page alone. Awesome!

Try it yourself

Launch CloudFormation stack

Try the example from this article by clicking this button to launch a CloudFormation stack in your own account. This will create a complete environment, including:

  • a new VPC, subnets, and other networking resources

  • a task definition for the NGINX container

  • two ECS services as described in this article

    • fargate-service runs by default 1 ECS task using the FARGATE capacity provider

    • fargate-spot-service runs by default 1 ECS task using the FARGATE_SPOT capacity provider

A DesiredCount parameter sets how many tasks to start in each service. The default is 1, but if you want to ramp up to 100 tasks I’ll leave that to you!

The optional DockerHubUsername and DockerHubPassword parameters can be configured to pull the nginx image as an authenticated user. I recommend this to avoid problems with pull rate limiting that Docker Hub now has in place.

Accept all the defaults and click Next until you get to the last page. Here you need to allow these additional capabilities, then click Create stack.

The CloudFormation stack will take a few minutes to create.

Afterwards, I suggest going to Services > Elastic Container Service > default-cluster and having a look at the capacity provider strategy configured on each of the ECS services, as described earlier. You can also go into the details page of each ECS task to see if it’s running in Fargate Spot or Fargate.

Be careful not to leave this stack running too long though, to avoid unnecessary charges.

Final thoughts

You’ve seen that Fargate Spot can give you a significant cost saving of around 66% compared with Fargate. If this is a route you’re considering, bear in mind the following:

  • only use Fargate Spot for services that can gracefully handle interruptions

  • your service should be designed to respond to the SIGTERM shutdown signal within 2 minutes maximum

  • consider using a capacity provider strategy that mixes Fargate and Fargate Spot. This mitigates your risk if multiple Fargate Spot containers get terminated at the same time.