4.1 EC2 Auto Scaling Policies & Elasticity

4.1 EC2 Auto Scaling Policies & Elasticity

Elasticity is the core cloud capability of dynamically acquiring and releasing compute capacity to match workload demand. Amazon EC2 Auto Scaling automates fleet provisioning to preserve application availability while eliminating over-provisioning expenses. For the AWS Certified CloudOps Engineer – Associate exam, operational engineers must master dynamic scaling policies, cooldown mechanics, machine-learning-driven predictive scaling, modern Launch Templates, and instance termination behavior.

Dynamic Scaling Policy Types

EC2 Auto Scaling provides three dynamic scaling policy types reacting to real-time Amazon CloudWatch metrics:

1. Target Tracking Scaling

Target Tracking acts like a home thermostat: the engineer sets a target value for a metric, and Auto Scaling adjusts capacity proportionally to keep the metric near that target. AWS automatically creates managed scale-out and scale-in CloudWatch alarms. Predefined metrics include:

• ASGAverageCPUUtilization: Aggregated fleet CPU load.
• ASGAverageNetworkIn / ASGAverageNetworkOut: Ingress/egress bandwidth per instance.
• ALBRequestCountPerTarget: Request volume per target in an Application Load Balancer (ALB) target group.

Target tracking also supports custom metrics that vary inversely or directly with instance counts. Engineers can optionally disable scale-in within the policy to handle spikes automatically while controlling scale-in manually.

2. Step Scaling

Step Scaling executes graduated adjustments based on the magnitude of the threshold breach. For example, an alarm on memory utilization can define:

• 60%–74%: Add 1 instance
• 75%–89%: Add 3 instances
• ≥90%: Add 6 instances (or 50% capacity)

Step scaling responds immediately without waiting for cooldowns between step breaches. While new instances boot, subsequent alarms can trigger further scale-out actions if metrics deteriorate. The configured instance warmup ensures booting instances are excluded from metric aggregations until healthy.

3. Simple Scaling

Simple Scaling executes a single adjustment (e.g., add 2 instances) when an alarm triggers. Crucially, simple scaling locks the Auto Scaling group during a mandatory cooldown period. No further scaling actions occur until the cooldown expires. Because it cannot adjust according to spike severity and delays responsiveness, simple scaling is considered legacy; AWS recommends Target Tracking or Step Scaling.

Scaling Cooldowns & Flapping Prevention

A scaling cooldown is a configurable pause (default: 300 seconds) preventing an Auto Scaling group from initiating further scaling actions before previously launched instances stabilize. Without cooldowns, flapping (or thrashing) occurs: before an instance finishes bootstrapping, metric alarms fire repeatedly, rapidly over-provisioning dozens of unneeded instances.

1. Default Group Cooldown: Configured at the Auto Scaling group level; applies to all simple scaling events and lifecycle transitions.
2. Scaling-Specific Cooldown: Configured directly on individual simple scaling policies to override the group default (e.g., a 60-second scale-out cooldown paired with a 600-second scale-in cooldown).

In Target Tracking and Step Scaling, cooldowns are replaced by instance warmup, which excludes warming instances from CloudWatch metric aggregations until ready.

Predictive Scaling with Machine Learning

Dynamic scaling is reactive: load rises, alarms fire, and instances boot. For cyclical workloads (such as morning login surges or weekly payroll processing), reactive scaling causes transient latency and HTTP 504 timeouts.

Predictive Scaling uses machine learning to analyze historical CloudWatch metrics and schedule proactive capacity ahead of demand:

• Data Requirements: Requires at least 24 hours of historical data (14 days recommended for optimal model accuracy).
• Scheduling: Recalculates forecasts daily and schedules capacity adjustments up to 48 hours in advance, launching instances minutes before projected surges.
• Modes: Forecast only (evaluates model accuracy without scaling) and Forecast and scale (actively modifies capacity).
• Hybrid Pattern: Best practice pairs Predictive Scaling with dynamic Target Tracking: predictive scaling establishes the scheduled capacity baseline, while target tracking absorbs real-time unexpected variance.

Launch Templates vs. Legacy Launch Configurations

Auto Scaling groups reference configuration blueprints to launch EC2 instances. AWS has officially deprecated legacy Launch Configurations in favor of Launch Templates:

• Versioning & Inheritance: Launch Templates support versioning (default, latest, or specific version tags) and parameter inheritance, allowing seamless rolling updates and rollbacks.
• Mixed Instances Fleets: A single Launch Template allows an Auto Scaling group to span multiple instance types (e.g., c6i.xlarge, c6a.xlarge, c7i.xlarge) and purchase models (On-Demand and Spot).
• Spot Allocation Strategies:
  • capacity-optimized: Allocates Spot instances from pools with the deepest capacity, minimizing Spot interruption probability.
  • price-capacity-optimized: Evaluates price and capacity availability to deliver high availability at lowest cost (recommended default).
  • lowest-price: Launches from the lowest-priced pools, incurring higher interruption rates.
• Security & Features: Enforces IMDSv2 (HttpTokens=required), EBS gp3 configuration, and modern Graviton instance families.

Termination Policies & Instance Scale-In Protection

When an Auto Scaling group scales in, the default termination policy evaluates instances in strict sequence:

1. AZ Rebalancing: Selects the Availability Zone with the largest number of instances.
2. Oldest Configuration: Selects instances running the oldest Launch Template version or Launch Configuration.
3. Closest to Next Billing Hour: Selects the instance running longest toward its next fractional hour.
4. Random: Chooses randomly if multiple candidates remain identical.

Engineers can specify custom policies (OldestInstance, NewestInstance, OldestLaunchTemplate, AllocationStrategy, or custom Lambda functions).

To protect non-interruptible workloads (e.g., active batch jobs or stateful connections) from termination during scale-in, engineers enable Instance Scale-In Protection at the group level or dynamically per instance via the AWS CLI (aws autoscaling set-instance-protection --protected-from-scale-in).