Study Guide: Architecting for the Cloud
Cloud design differs fundamentally from traditional on-premises architecture. Instead of building for peak capacity with static resources, cloud architects design for elasticity, automation, and “failure as a first-class citizen.” The goal is to create systems that are resilient, cost-effective, and easy to evolve.
The Restaurant Analogy
Imagine a traditional restaurant where the Chef (Server) also takes orders, cleans tables, and handles payments. If the Chef gets sick or there is a rush, the entire system collapses. This is Tight Coupling.
A Cloud-Optimized restaurant uses a Waiter (Load Balancer) to take orders, a Ticket System (SQS) to hold orders, and multiple Chefs (Auto Scaling) who only cook. If one Chef leaves, another steps in. If the kitchen is full, orders wait safely in the Ticket System. This is Loose Coupling and Decoupling.
Core Concepts: The Well-Architected Framework
The AWS Well-Architected Framework provides a consistent set of strategies to evaluate architectures. For the SAA-C03 exam, you must understand these six pillars:
- Operational Excellence: Running and monitoring systems to deliver business value.
- Security: Protecting information and systems (Shared Responsibility Model).
- Reliability: Ensuring a workload performs its intended function correctly and consistently.
- Performance Efficiency: Using computing resources efficiently as demand changes.
- Cost Optimization: Avoiding unnecessary costs.
- Sustainability: Minimizing the environmental impacts of running cloud workloads.
Comparison: Scaling Strategies
| Feature | Vertical Scaling (Scale Up) | Horizontal Scaling (Scale Out) |
|---|---|---|
| Definition | Increasing the size/specs of an existing instance (e.g., t3.micro to m5.large). | Adding more instances to your resource pool (e.g., 1 instance to 10 instances). |
| Availability | Single point of failure remains. Downtime often required for resize. | High availability. If one instance fails, others continue to work. |
| Limit | Hardware limit (you can only get so big). | Virtually limitless. |
| Best Use Case | Legacy applications that cannot be distributed. | Modern, stateless web applications. |
Decision Matrix: Architecture Patterns
IF the requirement is to handle unpredictable traffic spikes THEN use Auto Scaling with Target Tracking.
IF you need to protect against a single Data Center failure THEN deploy resources across Multiple Availability Zones (Multi-AZ).
IF you need to decouple two components to prevent data loss THEN insert an Amazon SQS queue between them.
IF you need to serve global users with low latency THEN use Amazon CloudFront (Edge Locations).
Exam Tips: Golden Nuggets
- Design for Failure: Always assume everything will fail. Use Multi-AZ for RDS and ELB for EC2.
- Statelessness: Store user session data in ElastiCache or DynamoDB, not on the local EC2 instance disk.
- Know Your “Elasticity”: S3, Lambda, and DynamoDB scale automatically. EC2 requires an Auto Scaling Group (ASG).
- Distractor Alert: Avoid “Snowball” for real-time data; Snowball is for physical bulk migration. Use Kinesis for real-time streams.
Architectural Flow: Scalable & Resilient Web App
- Route 53: Global DNS routing.
- ALB/NLB: Traffic distribution.
- Auto Scaling: Dynamic capacity.
- CloudWatch: Monitoring & Alarms.
- Hardcoding IP addresses.
- Single Point of Failure (Single-AZ).
- Over-provisioning resources.
- Storing state on the web server.
- Static: S3 + CloudFront.
- Event-Driven: S3 -> Lambda -> SNS.
- Decoupled: EC2 -> SQS -> EC2.
- Caching: ElastiCache (Redis).