A quick rundown at Amazon ECS Capacity Providers

We have seen the Amazon ECS service in detail under a couple of previous articles. In this article, we will be discussing the Capacity Provider feature of the ECS service.

What are the Capacity Providers?

As you must be aware, Amazon ECS Clusters leverage EC2 or Fargate compute in the backend to run the container tasks. Before CPs, ECS was conceptualized as infrastructure first! That means you need to have infra ready before you can run the tasks. If you see the ECS’s functioning, you have to create ASG, run the desired count of instances in ASG, and then run the tasks in ECS.

With the concept of Application first, Capacity Providers came into existence. CPs are managers of infrastructure. Basically, they are providing and managing the compute capacity for running tasks in the cluster. So, you need not run instances before running tasks. You can run the tasks even if there is no infra provisioned in the cluster and when CPs detects tasks are awaiting compute to run, they will provision compute (EC2/Fargate). They work in both ways: scale out and scale in.

CPs responds to the service/application’s requirement and mange compute capacity automatically.

Types of Capacity Providers

There are two types of capacity providers offered –

1. For ECS using EC2:
   • A capacity provider will be a logical entity grouping ASG of EC2 and setting for managed scaling, termination protection.
   • It is recommended to create a new ASG to use in this capacity provider. You may use the same launch config/template from the existing ECS ASG.
2. For ECS using FARGATE:
   1. Amazon offers FARGATE and FARGATE_SPOT capacity providers.
   2. There are reserved and can not be created or deleted. You can directly associate them with your cluster.

Why should I move from Launch type to Capacity Providers?

All this capacity provider hype leaves many of us to the very question. Why? So let me jot down few reasons why you should consider moving to capacity providers than using launch types.

1. Out of the box autoscaling for both scale-in and scale-out actions. So, you don’t have to engineer it using the CloudWatch matrix!
2. You can start a cluster without provisioning any instances beforehand (desired capacity set to 0 in ASG)
3. Capacity will be made available to tasks when you run them by scaling out ASG. This makes sure AWS bills are light on your pocket.
4. Scale-out compute when your application takes the load and automatically scales in when load flattens. Peace of mind from management and bills!
5. You can make use of FARGATE_SPOT!
6. You can migrate existing ECS services to Capacity Providers without any downtime.

Downsides of Capacity Providers

There are few shorts in the capacity providers as well for now. They may improve in the future. A quick list as below –

1. CAP is not supported if you are using Classic Load Balancers for services in the ECS cluster.
2. CAP is not supported for blue/green deployment types for services.
3. The scale in duration is set to 15 minutes, and you can not customize it.
4. This leads to another issue: you should have EC2 idle for 15 minutes straight to get it nominated in scale-in action. Hence, scale in action is not aggressive and might not even happen in a crowded/spiking environment.
5. It also does not for fragmentation of tasks, i.e., grouping them in underutilized instances, which is another reason scale-in will not be aggressive. You can try binpack placement strategy, though, to mitigate this.
6. Once you update the service to use capacity providers, you can not update it to use EC2/previous launch type. You have to delete and re-create the service for that (includes downtime).
7. When using the capacity provider strategy, a maximum of 6 capacity providers can be provided.

That’s all for starters! We will see Capacity Providers in action in upcoming articles.