AWS Auto Scaling Solutions: Architecting for Elasticity
Configuring solutions for auto scaling (for example, DynamoDB, EC2 Auto Scaling groups, RDS storage auto scaling, ECS capacity provider)
AWS Auto Scaling Solutions: Architecting for Elasticity
This guide covers the configuration and management of auto-scaling across core AWS services, including EC2, ECS, DynamoDB, and RDS, as required for the AWS Certified DevOps Engineer - Professional (DOP-C02) exam.
Learning Objectives
After studying this guide, you should be able to:
- Differentiate between dynamic, predictive, and scheduled scaling strategies.
- Configure Auto Scaling Groups (ASGs) for EC2 and ECS Capacity Providers.
- Implement DynamoDB auto-scaling for Read/Write capacity units (RCUs/WCUs).
- Manage RDS storage auto-scaling to prevent out-of-space conditions.
- Select appropriate CloudWatch metrics to trigger scaling actions based on business requirements.
Key Terms & Glossary
- Target Tracking Scaling: A policy that increases or decreases capacity to maintain a specific metric at a target value (e.g., keep CPU at 50%).
- Predictive Scaling: An EC2-only feature that uses machine learning to forecast future traffic and provision instances in advance.
- Cooldown Period: A configurable timeframe after a scaling activity during which the ASG ignores further alarms to prevent "flapping."
- ECS Capacity Provider: A logical link between an ECS cluster and an ASG that manages the scaling of infrastructure based on container task demands.
- WCU/RCU: Write Capacity Units and Read Capacity Units; the throughput measurements for DynamoDB tables.
The "Big Idea"
Auto scaling is the technical realization of Elasticity. While scalability refers to the system's ability to handle growth, elasticity is the ability to both grow and shrink automatically based on real-time demand. This ensures high availability during spikes and cost optimization during lulls, moving from a fixed-capacity mindset to a consumption-based model.
Formula / Concept Box
| Concept | Scaling Logic / Trigger |
|---|---|
| Target Tracking | |
| Step Scaling | (e.g., +2 instances if CPU > 80%) |
| RDS Storage Scaling | Triggers when free space < 10% AND lasts > 5 mins AND max limit not reached |
| ECS Managed Scaling | Uses CapacityProviderReservation metric to ensure instances match tasks |
Hierarchical Outline
- I. EC2 Auto Scaling
- Launch Templates: Defines what is launched (AMI, Instance Type, Security Groups).
- Scaling Policies:
- Dynamic: Reactive scaling based on CloudWatch Alarms.
- Predictive: Proactive scaling based on historical patterns (minimum 24h data).
- Warm Pools: Pre-initialized instances ready to go into service faster.
- II. Database Scaling
- DynamoDB: Uses Target Tracking for throughput; handles spikes without manual intervention.
- RDS Storage: Automatically increases Disk (not Instance size) when storage is low.
- III. Container Scaling
- ECS Capacity Providers: Eliminates the "manual sync" between tasks and EC2 instances.
- EKS Autoscalers: Cluster Autoscaler (CA) or Karpenter for node-level scaling.
Visual Anchors
The Auto Scaling Control Loop
Multi-AZ EC2 Auto Scaling Architecture
Definition-Example Pairs
- Scheduled Scaling: Scaling based on a known calendar event.
- Example: An e-commerce site scaling out 2 hours before a planned Black Friday sale begins.
- RDS Storage Auto Scaling: Automatic volume expansion for RDS databases.
- Example: A database that starts at 100GB automatically grows to 110GB when it hits 90GB usage, preventing a database-wide crash.
- ASG Health Checks: The mechanism to determine if an instance should be replaced.
- Example: If an ALB health check fails for an instance, the ASG terminates it and launches a fresh replacement immediately.
Worked Examples
Scenario: Configuring DynamoDB Auto-Scaling
Goal: Maintain a 70% utilization rate for a table experiencing unpredictable social media traffic.
- Define Target: Set the Target Utilization to 70%.
- Define Range: Set Minimum Capacity to 5 and Maximum Capacity to 100.
- CloudWatch Alarm: AWS automatically creates two CloudWatch alarms behind the scenes: one for
ScaleOut(when utilization > 70%) and one forScaleIn(when utilization < 70% for a sustained period). - Result: If traffic surges and consumption hits 85%, DynamoDB increases RCUs/WCUs to bring the average back toward 70%.
Checkpoint Questions
- Which scaling policy is best for a workload that has a predictable daily spike at 9:00 AM? (Answer: Scheduled Scaling)
- True or False: RDS Storage Auto Scaling can be used to decrease storage size to save costs. (Answer: False, it only increases size)
- What metric does an ECS Capacity Provider use to decide when to scale the underlying EC2 ASG? (Answer:
CapacityProviderReservation) - Why might you use a "Warm Pool" for an EC2 ASG? (Answer: To reduce the time it takes for an instance to become ready for traffic by pre-initializing it).
Muddy Points & Cross-Refs
- Predictive vs. Dynamic: People often confuse these. Remember: Predictive is like a weather forecast (planning ahead), Dynamic is like an umbrella (reacting to rain).
- Scaling In vs. Termination Policies: Scaling in is the act of reducing capacity; the "Termination Policy" is the logic that decides which specific instance to kill first (e.g., OldestInstance, ClosestToNextInstanceHour).
- Cross-Ref: See Unit 3 (Resilient Cloud Solutions) for how Auto Scaling integrates with Route 53 Health Checks.
Comparison Tables
Scaling Strategy Comparison
| Feature | Target Tracking | Step Scaling | Predictive Scaling |
|---|---|---|---|
| Best For | Stable, metric-based goals | Rapidly changing spikes | Cyclic, predictable patterns |
| Complexity | Low (Automatic) | Medium (Manual steps) | High (Requires ML) |
| Service Support | EC2, ECS, RDS, DynamoDB | EC2, ECS | EC2 Only |
| Responsiveness | Balanced | Very Fast | Proactive (Zero Lag) |