{"id":18281,"date":"2020-04-09T18:23:30","date_gmt":"2020-04-09T09:23:30","guid":{"rendered":"https:\/\/www.skyarch.net\/blog\/?p=18281"},"modified":"2025-12-09T14:14:00","modified_gmt":"2025-12-09T05:14:00","slug":"aws-ecs-cluster-auto-scaling","status":"publish","type":"post","link":"https:\/\/www.skyarch.net\/blog\/en\/aws-ecs-cluster-auto-scaling\/","title":{"rendered":"[AWS ECS] Cluster Auto Scaling"},"content":{"rendered":"

This new capability offered by AWS improves the cluster scaling experience by increasing the speed and reliability of cluster scale-out<\/em>, giving the user control over the amount of spare capacity maintained in the cluster, and automatically managing instance termination on cluster scale-in<\/em>.<\/p>\n

Previously, the workaround to have ECS Cluster Auto Scaling enabled is to create CloudWatch Alarms<\/em>\u00a0connected to the ECS Cluster CloudWatch Metrics<\/em>\u00a0(e.g., MemoryUtilization<\/em>, CPUUtilization<\/em>) and then integrate those alarms in the Auto Scaling Group<\/em> of the ECS Cluster. With this, you will have to manage the number of EC2 instances you add or remove every time the alarms you set are triggered. You can read more on that here<\/a>.<\/div>\n

Capacity Provider<\/h2>\n
Going back to the new ECS Cluster Auto Scaling, to enable it, you will need to create the new ECS resource type called Capacity Provider<\/strong>. A Capacity Provider<\/em> can be associated with an EC2 Auto Scaling Group (ASG)<\/em>. Through an ASG<\/em> will an ECS Cluster have the optimum number of container instances, without creating additional CloudWatch Metric Alarms<\/em>\u00a0nor specifying the number of EC2 instances in case of scale out or in.<\/div>\n
<\/div>\n
In particular, Capacity Provider<\/em> uses Managed Scaling<\/strong> that utilizes an automatically-created scaling policy on the ASG<\/em>, and a new scaling metric (Capacity Provider Reservation<\/em>) to manage the optimum number of instances in the cluster; and in addition, Managed instance termination protection<\/strong> which enables container-aware termination of instances in the ASG<\/em>\u00a0when scale-in happens.<\/div>\n

Creating Capacity Provider and ECS Cluster<\/h3>\n
To create a Capacity Provider<\/em>, you will need an ASG<\/em> first. An ASG<\/em> can be created through the AWS console<\/em> or AWS CLI<\/em>. You may also opt to using the AWS SDK<\/em>. An ASG<\/em>, in turn, requires Launch Configuration <\/em>so this needs to be created first.<\/div>\n
<\/div>\n
In the AWS console, ASG<\/em> and Launch Configuration<\/em> sections can be found in the EC2<\/em> console. Using CLI<\/em>:<\/div>\n

Launch Configuration:<\/h4>\n
aws autoscaling create-launch-configuration --cli-input-json <launch-config-json> --user-data <user-data-txt-file><\/pre>\n
Auto Scaling Group:<\/h4>\n
aws autoscaling create-auto-scaling-group --auto-scaling-group-name <asg-name> --cli-input-json <asg-config-json><\/pre>\n
Capacity Provider:<\/h4>\n
aws ecs create-capacity-provider --cli-input-json <capacity-provider-config-json><\/pre>\n
Now you can finally create the ECS Cluster<\/em>\u00a0equipped with Capacity Provider<\/em>:<\/div>\n
aws ecs create-cluster --cluster-name <cluster-name> --capacity-providers <capacity-provider-name> --default-capacity-provider-strategy capacityProvider=<capacity-provider-name>,weight=1<\/pre>\n
Note: You need not to create a Launch Configuration<\/em> and an ASG<\/em> if you create the ECS Cluster<\/em> using the EC2 Linux + Networking<\/em> template. They are handled by AWS in the background. All you have to do is create a Capacity Provider<\/em> and connect the pre-configured ASG to it. This is NOT possible if you create an EMPTY cluster.<\/strong><\/div>\n
<\/div>\n
Fargate and EC2 ECS Launch Types Comparison<\/h2>\n
In this section, Fargate<\/em> (A)<\/span><\/strong> and EC2<\/em> ECS launch types with (B)<\/span><\/strong> and without (C)<\/span> Capacity Provider<\/em><\/strong>\u00a0are compared.<\/div>\n
Setup<\/h3>\n
Three clusters are prepared, one each for the three launch types. All of them use the same task definition and container definition for the service.<\/div>\n
<\/div>\n
<\/div>\n
(A)<\/span> in the first place does not need any EC2 and container instance configuration as it is managed by AWS.<\/div>\n
<\/div>\n
<\/div>\n
For (B)<\/span>, launch configuration<\/em> and ASG<\/em>\u00a0created when the ECS Cluster was created are utilized. Capacity Provider<\/em>\u00a0was added with Managed Scaling<\/em>\u00a0option enabled.<\/div>\n
<\/div>\n
<\/div>\n
Additional configurations are needed for (C)<\/span> such as CloudWatch Metric Alarms<\/em>\u00a0mentioned earlier. One (1) EC2 instance is added every time the alarm is triggered.<\/div>\n
<\/div>\n
<\/div>\n
Twenty (20) tasks are fired through updating the service definition (i.e., Number of tasks = 20<\/em>).<\/div>\n
Speed<\/h3>\n
(A)<\/span> is the fastest in launching the 20 tasks as most of its resources are handled and optimized by AWS.<\/div>\n
<\/div>\n
<\/div>\n
\"Fargate<\/a><\/div>\n
<\/div>\n
As shown in the image, it only took ~2 minutes for the 20 tasks to be launched and the service to reach a steady state.<\/div>\n
<\/div>\n
<\/div>\n
(B)<\/span> comes in second which took ~11 minutes to do the same job.<\/div>\n
<\/div>\n
\"EC2<\/a><\/div>\n
As seen, the service repeatedly failed to place the remaining tasks due to insufficiency in memory of the available container instances (EC2 instances). ASG<\/em> through the Capacity Provider<\/em>\u00a0fired the necessary number of additional EC2 instances to accommodate the remaining tasks.<\/div>\n
<\/div>\n
<\/div>\n
(C)<\/span> is the slowest of the three mainly because it depends on the cluster's CPUUtilization<\/em> and MemoryUtilization<\/em>\u00a0metric alarms. Also, since only 1 instance is added every alarm trigger, it took time for the optimum number of EC2 instances to be fired.<\/div>\n
<\/div>\n
\"EC2<\/a><\/div>\n
It took ~28 minutes for (C)<\/span> to reach a steady state. This can be further improved by tweaking the CloudWatch Alarms<\/em>\u00a0thresholds and\/or the number of instances fired each alarm trigger.<\/div>\n
Zero Scale<\/h3>\n
(A)<\/span> and (B)<\/span> can both scale out from zero. For (C)<\/span>, however, it needs at least one container instance for the CloudWatch Metrics<\/em>\u00a0to record data; only then can it decide whether to add more instances or not.<\/div>\n
References<\/h2>\n
    \n
  • https:\/\/aws.amazon.com\/blogs\/compute\/building-blocks-of-amazon-ecs\/<\/li>\n
  • https:\/\/aws.amazon.com\/about-aws\/whats-new\/2019\/12\/amazon-ecs-capacity-providers-now-available\/<\/li>\n
  • https:\/\/aws.amazon.com\/blogs\/aws\/aws-ecs-cluster-auto-scaling-is-now-generally-available\/<\/li>\n
  • https:\/\/aws.amazon.com\/blogs\/containers\/deep-dive-on-amazon-ecs-cluster-auto-scaling\/<\/li>\n
  • https:\/\/github.com\/aws\/containers-roadmap\/issues\/76<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
    This new capability offered by AWS improves the cluster scaling experience by increasing the speed and reliabi…<\/p>\n","protected":false},"author":128,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_locale":"en_US","_original_post":"https:\/\/www.skyarch.net\/blog\/?p=18281","footnotes":""},"categories":[20],"tags":[1019,102,303,1018],"class_list":{"0":"post-18281","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-aws","7":"tag-autoscaling","8":"tag-aws","9":"tag-ecs","10":"tag-fargate","11":"en-US"},"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.skyarch.net\/blog\/wp-json\/wp\/v2\/posts\/18281","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.skyarch.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.skyarch.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.skyarch.net\/blog\/wp-json\/wp\/v2\/users\/128"}],"replies":[{"embeddable":true,"href":"https:\/\/www.skyarch.net\/blog\/wp-json\/wp\/v2\/comments?post=18281"}],"version-history":[{"count":5,"href":"https:\/\/www.skyarch.net\/blog\/wp-json\/wp\/v2\/posts\/18281\/revisions"}],"predecessor-version":[{"id":30073,"href":"https:\/\/www.skyarch.net\/blog\/wp-json\/wp\/v2\/posts\/18281\/revisions\/30073"}],"wp:attachment":[{"href":"https:\/\/www.skyarch.net\/blog\/wp-json\/wp\/v2\/media?parent=18281"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.skyarch.net\/blog\/wp-json\/wp\/v2\/categories?post=18281"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.skyarch.net\/blog\/wp-json\/wp\/v2\/tags?post=18281"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}