A scaling group manages instances that share the same application requirements and instance types. It lets you quickly scale out your cluster and dynamically adjust instance counts based on business demand, helping reduce costs.
Why use a scaling group
-
Rapidly scale out for high availability
Quickly scale out your service cluster by adding instances to increase capacity and handle traffic.
-
Manage costs
Because traffic is not always at peak, Auto Scaling aligns resources with actual demand and removes unneeded instances, reducing costs.
Scaling solutions
Solution 1: Maintain a fixed number of instances
-
Use cases: Maintain high availability for a cluster that does not require scaling.
-
How it works: Enable instance health check and configure the Expected Number of Instances for the scaling group.
When instance health check is enabled, the scaling group automatically removes unhealthy instances. If the number of instances falls below the expected count, Auto Scaling triggers a scale-out to maintain a fixed number of healthy instances.
-
Example
If you want to maintain a cluster of 10 healthy service instances, set the Expected Number of Instances to 10. The scaling group will automatically trigger scaling activities to maintain 10 healthy instances.
Solution 2: Scheduled scaling
-
Use cases: Handle predictable, recurring changes in business workloads.
-
How it works: Create a Scheduled Tasks for the scaling group to automate scale-out and scale-in events.
The scheduled task triggers a scale-out when resource demand is high and a scale-in when demand is low. For a complete guide, see Scale ECS instances on a schedule.
-
Example
For example, if traffic increases at 7:00 PM and decreases at 1:00 AM daily, you can create two scheduled tasks.
-
Handle traffic spikes: Set up a scheduled scale-out task for 7:00 PM. Every day at 7:00 PM, the task adds instances to increase the cluster's capacity.
-
Handle traffic lulls: Set up a scheduled scale-in task for 1:00 AM. Every day at 1:00 AM, the task removes instances to improve resource utilization and reduce costs.
-
Solution 3: Threshold-based scaling (CPU, memory utilization, etc.)
-
Use cases: Respond to sudden, unpredictable workload changes by triggering scaling when a resource metric crosses a defined threshold.
-
How it works
Event-triggered task
You can set up an Event-triggered Tasks for your scaling group. When a resource metric crosses a specified threshold, an alarm triggers a scaling activity.
Target tracking rule
You can create a Target Tracking Scaling Rule to keep a resource metric for your scaling group at or near a target value.
Example
For an ECS scaling group, you can create a target tracking scaling rule that sets the target for average CPU utilization at 80%. Auto Scaling will automatically add or remove instances to keep the group's average CPU utilization at or near 80%.
-
Comparing the two methods
-
Event-triggered tasks offer greater flexibility and customization. You can control exactly how many instances to add or remove when an alarm is triggered, and you can define different scaling responses for various resource utilization tiers.
-
Target tracking scaling rules are simpler to configure. You only need to define the target value for a metric, and Auto Scaling handles the rest.
-
Solution 4: Custom scaling (manual scaling)
If these solutions do not meet your needs, you can create a custom scaling solution.
You can trigger scaling activities by manually executing a scaling rule or by changing the number of instances in a scaling group. For a complete guide, see Manually scale ECS instances with one click.
Manual scaling supports API calls. You can write your own programs to call the API and build a custom scaling solution tailored to your business.
Solution 5: Predictive Scaling
Scaling groups can forecast future resource demand and scale automatically.
Configure a prediction rule and run it in forecast-only mode to assess accuracy. If the forecast meets your needs, enable Predict and Scale. The prediction rule then automatically creates scheduled tasks based on the forecast to scale the group. For details, see View the effect of a predictive scaling rule.
Usage notes
Before using a scaling group, ensure your application supports scaling out.
Consider whether adding instances affects your cluster's business operations.
-
Data consistency
If databases run on the instances being scaled, scaling out can cause data inconsistencies. To avoid this, deploy your database independently so all instances share a single database, making your services stateless.
-
Data security
Instances in a scaling group are created and released automatically. Back up any data stored on these instances to ensure its security.