AWS Multi-Service Auto Scaling: Architecture and Implementation

This guide explores the mechanisms for automating capacity management across the AWS ecosystem, focusing on the compute, database, and container layers as required for the DevOps Engineer Professional (DOP-C02) exam.

Learning Objectives

By the end of this guide, you should be able to:

• Differentiate between Dynamic, Predictive, and Scheduled scaling for EC2.
• Configure RDS Storage Auto Scaling to prevent "Storage Full" errors without manual intervention.
• Implement DynamoDB Auto Scaling for provisioned throughput (RCU/WCU).
• Explain the role of ECS Capacity Providers in bridging container demands with infrastructure.
• Evaluate Kubernetes Cluster Autoscaler vs. Karpenter for EKS node management.

Key Terms & Glossary

• ASG (Auto Scaling Group): A logical collection of EC2 instances treated as a single unit for scaling and management.
• Cooldown Period: A configurable setting that prevents an ASG from launching or terminating additional instances before previous scaling activities take effect.
• Target Tracking Scaling: A policy where you select a scaling metric (e.g., Average CPU) and a target value; AWS handles the math to keep the metric at that level.
• Karpenter: An open-source, flexible, high-performance Kubernetes cluster autoscaler that bypasses traditional ASGs for faster node provisioning.
• Capacity Provider: An ECS resource that manages the scaling of infrastructure for tasks, specifically linking ECS services to ASGs.

The "Big Idea"

Scaling is the cornerstone of Resiliency and Cost Optimization. In a modern cloud architecture, scaling must happen at every tier. If your web tier (EC2) scales but your database (RDS) hits a storage ceiling, or your container orchestrator (EKS) can't provision new nodes, the system fails. Effective DevOps automation involves synchronizing these diverse scaling engines to maintain a "Goldilocks" state: enough capacity to ensure performance, but not so much that you waste budget.

Formula / Concept Box

Hierarchical Outline

• I. Compute Scaling (EC2)
  • Dynamic Scaling: Responds to real-time CloudWatch metrics (CPU, Network In/Out).
  • Predictive Scaling: Uses machine learning to forecast traffic 24 hours in advance (EC2 only).
  • Scheduled Scaling: Pre-defined changes based on known events (e.g., "Black Friday").
• II. Database Scaling
  • RDS Storage Auto Scaling: Automatically increases EBS volume size when space is low.
  • DynamoDB Auto Scaling: Modifies Read/Write Capacity Units based on traffic patterns.
• III. Container Scaling
  • ECS Capacity Providers: Manages the "scaling out" of EC2 instances for Fargate or EC2-backed tasks.
  • EKS Cluster Autoscaler: Watches for "unschedulable" pods and adjusts ASG size.
  • EKS Karpenter: Directly calls EC2 APIs to provision right-sized nodes without ASGs.

Visual Anchors

ECS Capacity Provider Workflow

Scaling Performance vs. Demand

The following diagram represents the relationship between Actual Demand (Sine Wave) and Capacity (Step Function).

Definition-Example Pairs

• Predictive Scaling
  • Definition: Scaling based on historical traffic patterns using ML models.
  • Example: A news site that consistently sees a 300% traffic spike every Monday at 8:00 AM uses predictive scaling to warm up instances at 7:45 AM.
• RDS Storage Auto Scaling
  • Definition: A feature that increases storage capacity when available space is less than 10% or is low for a sustained period.
  • Example: A logging database on RDS Postgres starts at 100GB. As logs accumulate, RDS automatically increases storage to 150GB without any downtime or manual volume modification.
• ECS Managed Termination Protection
  • Definition: Prevents the ASG from terminating an EC2 instance if it is currently running an ECS task.
  • Example: During a scale-in event, the ASG wants to kill i-12345. Because Managed Termination Protection is on, it waits until the ECS task on that instance is safely drained.

Worked Examples

Scenario: Configuring DynamoDB Scaling

Problem: You have a DynamoDB table with a baseline of 100 WCU. You expect sudden, unpredictable spikes up to 1,000 WCU. How do you configure auto scaling?

Step-by-Step Solution:

1. Determine Target Utilization: Set a target utilization (e.g., 70%).
2. Set Constraints: Define a Minimum (100) and Maximum (2,000) WCU.
3. Application Auto Scaling: DynamoDB uses Application Auto Scaling to create a CloudWatch Alarm.
4. The Trigger: When ConsumedWriteCapacity exceeds 70% of 100 WCU for a sustained period, the alarm triggers.
5. The Result: AWS updates the provisioned WCU to a higher value based on the current load, keeping utilization near the 70% target.

Checkpoint Questions

1. Which scaling type is ONLY available for EC2 Auto Scaling Groups?
   • Answer: Predictive Scaling.
2. True or False: RDS Storage Auto Scaling can automatically scale down storage to save costs.
   • Answer: False. Storage can only scale up; scaling down requires a manual migration or snapshot/restore.
3. What is the primary difference between EKS Cluster Autoscaler and Karpenter?
   • Answer: Cluster Autoscaler manages ASGs; Karpenter bypasses ASGs and provisions EC2 instances directly.

Muddy Points & Cross-Refs

• RDS Scaling Confusion: Students often confuse RDS Storage Auto Scaling with Instance Scaling. RDS Storage Auto Scaling is automatic; changing the DB Instance class (e.g., db.t3.micro to db.m5.large) is NOT automatic unless using Aurora Serverless.
• Fargate vs. EC2 in ECS: Remember that Fargate doesn't require Capacity Providers or ASGs because it is serverless compute. Capacity Providers are specifically for managing the infrastructure of the EC2 Launch Type.

Comparison Tables