Task Statement 2.1: Design scalable and loosely coupled architectures.
📘AWS Certified Solutions Architect – (SAA-C03)
1. What is Scaling?
Scaling means adjusting resources to handle workload changes.
- If demand increases → add resources (scale out / up)
- If demand decreases → remove resources (scale in / down)
Goal:
- Maintain performance
- Reduce cost
- Ensure high availability
2. Types of Scaling
2.1 Vertical Scaling (Scale Up / Down)
Increase or decrease the power of a single resource.
Example (IT-based):
- Change EC2 instance type from
t3.micro→m5.large
Key Points:
- Easy to implement
- No architecture changes needed
- Limited by maximum instance size
- May require downtime
AWS Services:
- Amazon EC2
- Amazon RDS
2.2 Horizontal Scaling (Scale Out / In)
Add or remove multiple resources.
Example:
- Add more EC2 instances behind a load balancer
Key Points:
- Highly scalable
- No single point of failure
- Requires distributed design
AWS Services:
- EC2 Auto Scaling
- Elastic Load Balancer (ELB)
2.3 Diagonal Scaling
Combination of both:
- Scale up first, then scale out
3. Scaling Strategies
3.1 Manual Scaling
- User manually adds/removes resources
Use Case:
- Predictable workloads
- Testing environments
Limitation:
- Not suitable for dynamic traffic
3.2 Scheduled Scaling
- Scale based on time schedules
Example:
- Increase capacity during business hours
AWS Feature:
- EC2 Auto Scaling Scheduled Actions
3.3 Dynamic Scaling (Automatic Scaling)
Automatically adjusts based on metrics.
Types:
a) Target Tracking Scaling
- Keeps a metric at a target value
Example:
- Maintain CPU at 50%
b) Step Scaling
- Scale based on thresholds
Example:
- CPU > 70% → add 2 instances
c) Simple Scaling
- Basic scaling with cooldown period (less used)
3.4 Predictive Scaling
- Uses machine learning to forecast demand
Key Benefit:
- Scales before traffic increases
4. Scaling Compute Services
4.1 Amazon EC2
Tools:
- Auto Scaling Group (ASG)
- Elastic Load Balancer (ELB)
Key Features:
- Minimum, maximum, desired capacity
- Health checks
- Multi-AZ deployment
Exam Tips:
- Use ASG for high availability
- Combine with ELB for load distribution
4.2 AWS Lambda (Serverless)
Scaling Behavior:
- Automatically scales per request
Key Points:
- No server management
- Scales instantly
- Pay per execution
Limitation:
- Concurrency limits
4.3 Containers (ECS / EKS / Fargate)
Scaling Methods:
- Service Auto Scaling
- Cluster Auto Scaling
Key Concepts:
- Scale tasks/pods based on load
- Works well for microservices
5. Scaling Storage Services
5.1 Amazon S3
Scaling:
- Automatically scales
Key Features:
- Unlimited storage
- High request rate support
Exam Tip:
- No need to provision capacity
5.2 Amazon EBS
Scaling:
- Increase volume size
- Change volume type
Limitation:
- Attached to one EC2 instance
5.3 Amazon EFS
Scaling:
- Automatically scales storage
Use Case:
- Shared file system across instances
6. Scaling Database Services
6.1 Amazon RDS
Scaling Options:
Vertical Scaling:
- Change instance size
Horizontal Scaling:
- Read Replicas (for read-heavy workloads)
Storage Scaling:
- Enable auto storage scaling
Exam Tips:
- Use Read Replicas for scaling reads
- Use Multi-AZ for availability, NOT scaling
6.2 Amazon Aurora
Advanced Scaling:
- Auto Scaling Read Replicas
- Aurora Serverless (automatic scaling)
6.3 Amazon DynamoDB
Scaling Types:
Provisioned Mode:
- Manual or Auto Scaling
On-Demand Mode:
- Fully automatic scaling
Key Feature:
- Handles massive workloads automatically
7. Scaling Networking Components
7.1 Elastic Load Balancer (ELB)
Types:
- Application Load Balancer (ALB)
- Network Load Balancer (NLB)
Scaling:
- Automatically scales
Role:
- Distributes traffic across targets
7.2 Amazon CloudFront
Scaling:
- Automatically scales globally
Benefit:
- Reduces load on backend systems
8. Decoupling and Scaling
Scaling works best when components are loosely coupled.
Key Services:
8.1 Amazon SQS
- Queue-based scaling
- Consumers process messages at their own rate
8.2 Amazon SNS
- Pub/Sub model
- Fan-out scaling
8.3 Amazon EventBridge
- Event-driven scaling
9. Stateless vs Stateful Scaling
Stateless Applications:
- No session data stored locally
- Easy to scale horizontally
Example:
- Web servers
Stateful Applications:
- Store session/data locally
- Harder to scale
Solution:
- Externalize state (e.g., use ElastiCache or DynamoDB)
10. Key Decision Factors (VERY IMPORTANT FOR EXAM)
When choosing a scaling strategy, consider:
1. Traffic Pattern
- Steady → Manual or Scheduled
- Unpredictable → Dynamic or Serverless
2. Application Type
- Stateless → Horizontal scaling
- Stateful → Requires special handling
3. Cost
- Over-provisioning vs Auto scaling
4. Performance
- Latency requirements
5. Fault Tolerance
- Multi-AZ deployment
11. Common Exam Scenarios
Scenario 1:
Unpredictable traffic spikes
→ Use:
- Auto Scaling + ELB
- or Lambda
Scenario 2:
Read-heavy database workload
→ Use:
- RDS Read Replicas
Scenario 3:
Event-driven architecture
→ Use:
- SQS + Lambda
Scenario 4:
Global users
→ Use:
- CloudFront
Scenario 5:
Microservices
→ Use:
- ECS / EKS + Auto Scaling
12. Important Exam Tips
- Auto Scaling = HIGH AVAILABILITY + COST OPTIMIZATION
- ELB = REQUIRED for distributing traffic
- Lambda = best for automatic scaling
- S3, DynamoDB = fully managed scaling
- Read Replicas = scaling reads, NOT writes
- Multi-AZ = availability, NOT scaling
- Stateless apps = easiest to scale
Final Summary
To pass the exam, remember:
- Understand types of scaling (vertical, horizontal, diagonal)
- Know when to use Auto Scaling vs Serverless
- Identify which AWS services scale automatically
- Recognize scaling patterns in exam scenarios
- Always prefer:
- horizontal scaling
- loosely coupled architecture
- managed services
