Cloud Concepts and Architecture
The Cloud Concepts and Architecture domain tests whether you can explain the business case for cloud, describe AWS's global infrastructure, map workloads to the right service model, and draw the shared responsibility line. Questions are framing questions: you are given a constraint (cost, latency, compliance, resilience) and asked which model or architecture satisfies it.
The six advantages
- Trade capital expense for variable expense - pay for what you consume instead of pre-buying servers.
- Benefit from massive economies of scale - AWS aggregates demand and passes lower prices through.
- Stop guessing capacity - scale up or down instead of forecasting hardware years ahead.
- Increase speed and agility - provision resources in minutes.
- Stop spending money running and maintaining data centers - no racking, power, or cooling.
- Go global in minutes - deploy into multiple regions quickly.
Well-Architected Framework pillars
Operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Each pillar has design principles and best-practice questions; the framework is a review lens, not a compliance certification.
Global infrastructure vocabulary
A Region is a geographic area containing multiple, isolated Availability Zones. An Availability Zone is one or more discrete data centers with independent power, cooling, and networking, connected to siblings by low-latency links. Edge locations host CloudFront, Route 53, and Global Accelerator - they cache and route traffic, they do not run your EC2 instances. Local Zones push compute closer to a metro area.
Service models and responsibility
IaaS (EC2, EBS, VPC) leaves the guest OS and patching to you. Managed services (RDS, Lambda, S3) move more of the stack to AWS. The boundary moves per service: on EC2 you patch the OS; on RDS AWS patches the engine, but you still control data, IAM access, and network rules.
Worked example
A team runs a single EC2 instance and a self-managed MySQL database in one AZ and must survive an AZ failure with minutes of downtime. Reasoning: an AZ outage is within AWS's scope, so the fix is multi-AZ. Put EC2 behind an Application Load Balancer spanning two AZs, migrate MySQL to RDS Multi-AZ (synchronous standby, automatic failover), and move session state to DynamoDB. This delivers high availability inside one Region - not disaster recovery. Surviving a Region outage would require cross-Region replication and a documented RTO/RPO plan.
Traps that cost marks
- Treating "multi-AZ" as "multi-Region"; conflating an Availability Zone with a single data center.
- Confusing durability (S3's eleven nines) with availability.
- Assuming the shared responsibility split is identical for EC2 and Lambda.
- Choosing the edge network as a compute location.