3.1.2.2. Auto Scaling and Scaling Policies

3.1.2.2. Auto Scaling and Scaling Policies

💡 First Principle: AWS Auto Scaling dynamically adjusts Amazon EC2 instance capacity to meet fluctuating application demand, ensuring consistent performance and high availability while optimizing costs.

AWS Auto Scaling dynamically adjusts Amazon EC2 instance capacity to meet fluctuating application demand, ensuring consistent performance and high availability while optimizing costs by scaling resources up or down automatically.

AWS Auto Scaling is a service that monitors your applications and automatically adjusts capacity to maintain steady, predictable performance at the lowest possible cost. It prevents both over-provisioning (wasting money on idle resources) and under-provisioning (leading to performance degradation).

AWS offers various scaling policies to define how Auto Scaling groups adjust capacity:

• Simple Scaling: Responds to a single CloudWatch alarm, adding or removing a fixed number of instances.
• Step Scaling: Adjusts capacity based on a set of scaling adjustments, or "steps," that vary depending on the size of the alarm breach.
• Target Tracking Scaling: (Most common) Maintains a specified target value for a metric (e.g., 50% CPU utilization) by automatically adjusting capacity. This is ideal for maintaining desired performance levels.
• Scheduled Scaling: Scales capacity based on a predictable schedule, ideal for known traffic patterns like daily peaks or weekly reports.

Key Auto Scaling Concepts:

• Dynamic Adjustment: Automatically scales capacity up/down.
• "Scaling Policies": Simple, Step, Target Tracking, Scheduled.
• Benefits: Consistent performance, high availability, cost optimization.
• Self-healing: Health checks (EC2 or ELB) make the group terminate and replace unhealthy instances. Even a fixed-size group (min = max = desired = 1) that spans subnets in several AZs gives one non-scalable instance automatic replacement, in another AZ if necessary, with no application code changes.
• Faster scale-out: If instances install software through user data at boot, every scale-out waits for the install. Bake the software into a custom ("golden") AMI so new instances start ready, or keep pre-initialized instances in a warm pool. A bigger instance type or a longer health-check grace period does not shorten the install.
• Preventing flapping: A cooldown period (default 300 seconds for simple scaling) stops the group from starting another scaling activity until the last one has taken effect. Target tracking and step scaling use instance warmup for the same purpose. Thresholds that are too close together make the group scale out and back in again and again.

Scenario: An e-commerce application configures an Auto Scaling group to add instances when average CPU utilization exceeds 70% for five minutes and remove instances when it drops below 30% for ten minutes, efficiently handling peak sales and quiet periods.

Visual: AWS Auto Scaling with Different Policies

⚠️ Common Pitfall: Using Simple Scaling for rapid, dynamic workloads. Target Tracking is generally preferred as it's more proactive and intelligent.

Key Trade-Offs:

• Proactive (Scheduled) vs. Reactive (Metric-based): Scheduled scaling is for predictable patterns. Metric-based scaling reacts to actual load. A combination is often ideal.

Reflection Question: How does AWS Auto Scaling, particularly through its various scaling policies, enable proactive and reactive scaling to balance performance with cost efficiency for applications with fluctuating demand?