Applications that run in the cloud feel just like trying to predict the weather. Traffic can be calm and controllable, then all of a sudden, there's a storm of user activity, causing your application to lag and struggle. For teams using AWS Fargate, the unpredictability of user activity can cause either a performance bottleneck or, even worse, high-cost overruns from over-provisioning resources.
Fargate Autoscaling helps solve this. Fargate Autoscaling is like a smart thermostat for containerized applications, as it automatically regulates the resources that are allocated to your application. Learning how to implement Fargate Autoscaling appropriately allows you to keep your application highly available and responsive while also keeping your AWS Fargate costs to a minimum.
In this article, I will walk you through everything you need to know, from the most advanced Fargate concepts and deployment strategies to the beginner level.
What Is Fargate Autoscaling?
Fargate Autoscaling automatically adjusts the number of running tasks in Amazon ECS in response to demand. It can be compared to retailers hiring more cashiers. During busy times, extra cashiers are added to serve customers; during quiet times, the extra cashiers are sent home. Something similar takes place when tasks are added/removed. Fargate Autoscaling scales automatically.
Fargate Autoscaling consists of three key AWS services working together:
Amazon ECS: The container orchestration service where you define and run your Fargate services.
Amazon CloudWatch: A Monitoring service responsible for collecting various metrics, including memory and CPU utilization of the Fargate tasks.
Application Auto Scaling: CloudWatch metrics are used by this service to implement the defined scaling policies.
The key concepts to understand are:
Tasks: Individual instances of your containerized application running on Fargate.
Desired Count: This refers to the number of active tasks the ECS service aims to maintain. This number can be adjusted to scale the service automatically.
Minimum and Maximum Capacity: This refers to the fixed limits set by the user, corresponding to the number of running tasks. The limits help control scaling tasks to avoid a service from scaling down to zero or regaining tasks without control.
Scaling Policies: The rules that define when and how to perform scaling actions.
Benefits of Fargate Autoscaling
Automating your container scaling isn't just a technical convenience; it delivers tangible business value:
Improved Performance: During sudden traffic spikes, autoscaling launches new tasks to handle the increased load, ensuring your application remains fast and responsive for users.
Reduced Operational Overhead: Your team is freed from the manual, often stressful, task of monitoring and adjusting capacity. This lets them focus on innovation rather than firefighting.
Enhanced Resiliency: If a task fails, ECS automatically replaces it. Autoscaling adds another layer of resilience by ensuring the service always has enough tasks to meet demand, even during partial failures.
Better Cost Efficiency: This is the largest overall benefit. Autoscaling during low demand prevents resource waste, thereby protecting application profitability. The automated scaling of Fargate ties costs to direct application demand.
Faster Deployment Pipelines: With hands-off scaling logic, your deployment process becomes simpler and more reliable. You can push new code without worrying about manually adjusting your service's capacity.
How Fargate Autoscaling Works
While there are many variables involved in the mechanics behind Fargate Autoscaling, the provided steps are the most essential, allowing for the most accurate configuration. Fargate Autoscaling does the following:
Metric Collection: Performance metrics from the tasks in your ECS service are gathered via CloudWatch at a constant rate.
Alarm Trigger: You set specific CloudWatch Alarms which are tied to these metrics. For example, if CPU usage is at or above 75% for two periods of 60 seconds, or if memory usage is below 30% for a cooldown period, alarms can trigger actions. You can set custom alarms too, for example, if an SQS queue is above 1000 messages, an alarm will trigger an action. Each of these alarms is tied to specific scaling actions/rules.
Policy Execution: When an alarm is triggered, a scaling policy is executed, which you previously set up in Application Auto Scaling.
Desired Count Adjustment: The scaling policy has Application Auto Scaling to either increase or decrease the desired count for tasks in your ECS service.
Task Launch or Termination: After that, ECS receives the updated desired count and launches new Fargate tasks or terminates existing ones to match it.
Target Tracking vs. Step Scaling Policy
There are two main types of scaling policies you can use:
Target Tracking Scaling: This is the most straightforward and most used method. You choose a metric (e.g. average CPU utilization) and define a target, say, 70%. The Application Auto Scaling does all the heavy lifting by adding/removing tasks to keep the metric at target (or as close as possible). This is akin to programming a thermostat.
Step Scaling: This method gives you more granular control. You specify certain steps that adjust the task count based on the size of the alarm breach. For example, if the CPU is 70-80% add a task, but if it exceeds 80%, add 3 tasks. This comes in handy for applications that have very particular scaling requirements.
How to Configure Fargate Autoscaling
To enable Service Auto Scaling while creating or updating a service in the Amazon ECS console, follow these steps on the Set Autoscaling page:
Refer to this article on how to create an ECS Cluster:
Choose the option Configure Service Autoscaling to modify your service’s desired count.
In the Minimum number of tasks field, enter the lowest number of tasks you would like Service Auto Scaling to retain.
In the Desired number of tasks field, enter the number of tasks you consider optimal for Service Autoscaling.
Set the highest number of tasks you would like Service Auto Scaling to have in the Maximum number of tasks.
In the IAM role for Service Auto Scaling, choose ecsAutoscaleRole.
In the Automatic task scaling policies section, select Auto Scaling Policy.
Proceed to complete the remaining steps in the wizard to finalize the creation or updating of your service.
Common Mistakes and How to Avoid Them
Auto-scaling is very effective, but improper configurations can lead to issues. Some common mistakes are:
Scaling on the Wrong Metric: Scaling on the CPU won't help very much if your app is memory-bound. Using CloudWatch Container Insights will help you understand your application's resource profile.
Setting Max Tasks Too Low: If you cap your maximum tasks too low, your app may fall over when you get a large enough traffic spike.
Aggressive Scaling and Thrashing: If cooldown periods are too short or if your scaling thresholds are too sensitive, the service can get stuck in a loop of scaling up and down, referred to as thrashing.
Deleting Managed CloudWatch Alarms: The CloudWatch alarms created by Application Auto Scaling are managed by the system. If you manually delete them, your autoscaling will break.
IAM Role Misconfigurations: Ensure the ecsAutoscaleRole has the required permissions to modify your ECS service and interact with CloudWatch.
Cut Your AWS Fargate Costs with Pump
Although AWS Fargate Autoscaling adjusts according to your real-time traffic, it does not help with lowering your operational costs from AWS Fargate. If spending on Fargate is a concern, implementing costs-optimization strategies is a must.
You can seamlessly integrate your AWS account into Pump without requiring any engineering effort. You can achieve a cost savings of 10-60%. Here's how it works:
AI-Powered Commitments: Our system intelligently tracks your Fargate resource consumption and automatically buys and manages AWS Savings Plans and Reserved instances on your behalf. This gives you a better discount without the risk of over-committing.
Group Buying Power: Individual companies have a certain limited spend on AWS that determines the pricing tier that AWS charges. Pump consolidates the spending of hundreds of companies, thus enabling volume discounts. As a result, you get additional savings, which we pass on to you.
Waterfall Coverage: If the holder of a Reserved Capacity is not using it, our "waterfall" efficiently reallocates the unused capacity to companies that require it, thus enabling collective maximization of potential savings.
The best part? You can free to use.
Conclusion
Fargate Autoscaling is fundamental to the deployment of contemporary resilient and cost-effective apps on AWS. It streamlines processes, optimizes performance, and eliminates costs incurred from capacity that is not being utilized. I hope this guide has helped you learn everything you need to know about Fargate Autoscaling, so you can create a self-scaling system that offloads the menial work from your team to focus on higher-value work.
Are you looking to enhance the cost savings from your Fargate utilization even further? Our AI-powered platform can help you significantly reduce your Fargate costs. Sign up for Pump for free to get started.
