Scaling Strategies in AWS Architecture Design

Efficient scaling is a cornerstone of the AWS Well-Architected Framework. It ensures that an application can handle varying loads while maintaining performance and optimizing costs. This guide covers the mechanisms, policies, and strategies required to design elastic architectures.

Learning Objectives

After studying this guide, you should be able to:

• Differentiate between Horizontal and Vertical scaling and identify when to use each.
• Configure Amazon EC2 Auto Scaling groups using various scaling policies (Target Tracking, Step, Simple).
• Explain the role of decoupling (e.g., via Amazon SQS) in allowing independent component scaling.
• Identify appropriate metrics (CPU, Memory, Request Count) for triggering scaling actions.
• Understand how to scale database and storage layers using Read Replicas and Elastic EBS volumes.

Key Terms & Glossary

• Auto Scaling Group (ASG): A logical grouping of EC2 instances that share similar characteristics and are managed as a single unit for scaling and health management.
• Horizontal Scaling (Scaling Out/In): Adding or removing instances (nodes) to a system.
• Vertical Scaling (Scaling Up/Down): Increasing or decreasing the power (CPU, RAM) of an existing instance.
• Cooldown Period: A configurable setting for Simple Scaling that ensures the ASG does not launch or terminate additional instances before the previous scaling activity takes effect.
• Warm-up Time: Used in Step Scaling; the time until a newly launched instance can contribute to the CloudWatch metrics of the ASG.

The "Big Idea"

In traditional on-premises environments, you must "build for the peak," leading to expensive idle resources. In AWS, the Big Idea is Elasticity: treating infrastructure as code that expands and contracts in real-time. Scaling isn't just about handling more users; it's about matching supply to demand exactly, ensuring you never pay for more than you need while never providing less than your users require.

Formula / Concept Box

Hierarchical Outline

1. Scaling Methodologies
   • Vertical Scaling: Resizing instances (e.g., t3.micro to m5.large). Requires downtime; has an upper hardware limit.
   • Horizontal Scaling: Adding more instances. Preferred for high availability; theoretically limitless.
2. Amazon EC2 Auto Scaling Policies
   • Manual Scaling: Manually updating the desired capacity.
   • Scheduled Scaling: Scaling based on known time patterns (e.g., Friday sale).
   • Dynamic Scaling:
     • Target Tracking: Maintains a specific metric (e.g., "Keep aggregate CPU at 50%").
     • Step Scaling: Escalates the response based on the size of the breach (e.g., +2 units if CPU > 60%, +4 units if CPU > 80%).
     • Simple Scaling: Single adjustment based on a single alarm.
3. Scaling Other Components
   • Storage: Amazon EBS Elastic Volumes allow resizing without downtime.
   • Databases: RDS Read Replicas scale read-heavy workloads; RDS Proxy manages connection pooling.
   • Serverless: AWS Lambda and Fargate scale automatically per request/task.

Visual Anchors

Scaling Decision Flow

Horizontal vs. Vertical Scaling Visualization

Definition-Example Pairs

• Step Scaling: A policy that increases capacity in "steps" based on the severity of a metric alarm.
  • Example: If a CPU alarm triggers at 70%, add 2 instances. If it hits 90%, add 5 instances immediately to prevent a crash.
• Decoupling: Breaking a monolithic application into independent parts that communicate via messages.
  • Example: An ordering system sends orders to an Amazon SQS queue. The "Order Processor" fleet scales up based on the number of messages in the queue, regardless of how fast the "Web Front-end" is running.
• Predictive Scaling: Using machine learning to forecast future traffic based on historical patterns.
  • Example: An e-commerce site scales up 30 minutes before a daily "Flash Sale" begins, based on traffic data from the previous two weeks.

Worked Examples

Example 1: Configuring Step Scaling

Scenario: You have an ASG with a desired capacity of 4. You want to handle rapid spikes in traffic.

Step 1: Define Alarm. Create a CloudWatch alarm for Average CPU Utilization > 60%. Step 2: Define Steps.

• Step A: If CPU is between 60% and 70%, add 2 instances.
• Step B: If CPU is between 70% and 80%, add 4 instances.
• Step C: If CPU is > 80%, add 8 instances.

Result: If a sudden traffic burst hits 85% CPU, the ASG skips steps A and B and immediately adds 8 instances, providing a much faster response than a Simple Scaling policy.

Checkpoint Questions

1. What is the main advantage of Horizontal Scaling over Vertical Scaling in a high-availability architecture?
2. Which scaling policy is best for maintaining a steady aggregate CPU utilization of 40%?
3. True or False: Step scaling policies utilize a cooldown period to prevent rapid fluctuations.
4. How does an Amazon RDS Proxy help with scaling database-heavy applications?
5. If an ASG has a Min size of 2, Max size of 10, and Desired capacity of 4, what happens if you manually change the Desired capacity to 1?

▶Click to see answers

1. Horizontal scaling provides better fault tolerance (no single point of failure) and can scale virtually without limits, unlike vertical scaling which is limited by the largest instance size available.
2. Target Tracking Policy.
3. False. Step scaling policies use "Warm-up Time" for new instances; Simple Scaling policies use cooldown periods.
4. It pools and shares database connections, preventing the database from reaching connection limits as the application tier scales horizontally.
5. The ASG will terminate 2 instances to reach the Desired capacity of 2 (it will not go to 1 because the Min size is 2).