Study guide
4.1 EC2 Auto Scaling Policies & Elasticity
AWS Certified CloudOps Engineer – Associate SOA-C03
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Monitoring & Observability Infrastructure
1.1 Configuring Workload Observability 1.2 CloudWatch Agent Architecture & Deployment 1.3 Metric Alarms, Anomaly Detection & Composite Alarms
2 Chapter 2: Alarms, Dashboards & Event-Driven Remediation
2.1 CloudWatch Dashboards & Multi-Account Visibility 2.2 Notification Architecture & Alarm Invocation 2.3 Amazon EventBridge Rules, Event Buses & Troubleshooting 2.4 Automated Remediation with Systems Manager & Lambda
3 Chapter 3: Performance Optimization for Compute, Storage & Databases
3.1 EC2 & Compute Performance Optimization 3.2 Amazon EBS Performance Metrics & Volume Tuning 3.3 S3 Performance Strategies & Data Transfer 3.4 Shared Storage (EFS/FSx) & Database Performance
4 Chapter 4: Compute & Database Scalability and Elasticity
4.1 EC2 Auto Scaling Policies & Elasticity 4.2 Auto Scaling Advanced Operations: Warm Pools & Lifecycle Hooks 4.3 Dynamic Scalability Through Caching 4.4 Managed Database Scaling: RDS, Aurora & DynamoDB
5 Chapter 5: High Availability, Fault Tolerance & Load Balancing
5.1 Elastic Load Balancing (ALB/NLB) Configuration & Troubleshooting 5.2 Route 53 Health Checks & DNS Failover 5.3 Multi-AZ Architecture & Fault-Tolerant Deployments
6 Chapter 6: Backup, Data Protection & Disaster Recovery
6.1 Centralized Backup Automation & AWS Backup 6.2 Database Restore Strategies & RTO/RPO Management 6.3 Storage Versioning, Replication & Immutability 6.4 Disaster Recovery Patterns & Multi-Region Resilience
7 Chapter 7: Infrastructure as Code with CloudFormation & AWS CDK
7.1 CloudFormation Foundations & Resource Modeling 7.2 Managing Stacks, Drift Detection & Change Sets 7.3 Infrastructure as Code with AWS CDK 7.4 Identifying & Remediating Deployment Failures
8 Chapter 8: Multi-Account Provisioning, Containers & Third-Party IaC
8.1 Golden Images with EC2 Image Builder & Amazon ECR 8.2 Multi-Account & Multi-Region Resource Sharing 8.3 Deployment Strategies & Container Deployments 8.4 Third-Party Automation with Terraform & Git Workflows
9 Chapter 9: Systems Manager & Event-Driven Operations Automation
9.1 AWS Systems Manager Core Management & Run Command 9.2 Systems Manager Patch Manager & Session Manager 9.3 Event-Driven Operations Automation
10 Chapter 10: Identity, Access Management & Governance
10.1 Advanced IAM Policies, Roles & Policy Conditions 10.2 Auditing Access with CloudTrail Lake & IAM Access Analyzer 10.3 Multi-Account Security: Organizations, SCPs & Identity Center 10.4 Compliance Enforcement with AWS Config & Conformance Packs
11 Chapter 11: Data Security, Encryption & Vulnerability Management
11.1 Data Classification & Amazon S3 Security 11.2 Encryption at Rest with AWS Key Management Service (KMS) 11.3 Encryption in Transit with AWS Certificate Manager (ACM) 11.4 Secrets Management & Centralized Security Findings
12 Chapter 12: VPC Architecture, Endpoints & Network Protection
12.1 VPC Core Architecture, Subnetting & High Availability NAT 12.2 Private Network Connectivity: VPC Endpoints & Peering 12.3 Network Protection & Edge Security Auditing
13 Chapter 13: DNS, Route 53 Routing & Content Delivery
13.1 DNS Architecture & Route 53 Resolver for Hybrid Clouds 13.2 Route 53 Advanced Routing Policies & Query Logging 13.3 Global Content & Service Distribution: CloudFront & Global Accelerator
14 Chapter 14: Network Troubleshooting, Traffic Analysis & Hybrid Connectivity
14.1 VPC Configuration Troubleshooting & Analysis Tools 14.2 Network Traffic Analysis: VPC Flow Logs & Log Analytics 14.3 CloudFront Caching & Hybrid Connectivity Troubleshooting
4.1 EC2 Auto Scaling Policies & Elasticity
Key Takeaways Explain This Topic AI
Target Tracking Scaling automatically adjusts Auto Scaling group capacity to maintain a metric at a specified target value, such as ASGAverageCPUUtilization at 60% or ALBRequestCountPerTarget.
Step Scaling provides granular step adjustments based on the magnitude of CloudWatch metric threshold breaches and responds immediately without waiting for cooldown periods.
Predictive Scaling analyzes at least 24 hours of historical CloudWatch metric patterns using machine learning to schedule capacity ahead of recurring daily or weekly traffic surges.
Launch Templates supersede legacy Launch Configurations by supporting versioning, mixed instance types, and advanced Spot allocation strategies like capacity-optimized and price-capacity-optimized.
The default termination policy prioritizes Availability Zone rebalancing, followed by oldest launch template version and instances closest to the next billing hour, while instance scale-in protection safeguards long-running workloads.
Last updated: September 2026
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:
Policy Type Operational Trigger Response Mechanics Cooldown / Warmup Behavior
Target Tracking Target metric value (e.g., 60% CPU) Automatically calculates proportional capacity delta Uses instance warmup; ignores fixed cooldowns
Step Scaling Manually configured alarm thresholds Graduated capacity adjustments based on step breach size Evaluates continuously; respects instance warmup
Simple Scaling Single CloudWatch alarm threshold Fixed capacity adjustment (e.g., +2 instances) Locks group during mandatory cooldown period
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.
Default Group Cooldown : Configured at the Auto Scaling group level; applies to all simple scaling events and lifecycle transitions.
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:
AZ Rebalancing : Selects the Availability Zone with the largest number of instances.
Oldest Configuration : Selects instances running the oldest Launch Template version or Launch Configuration.
Closest to Next Billing Hour : Selects the instance running longest toward its next fractional hour.
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 ).