SkarpChapter 2 of 26
AWS Global Infrastructure, Availability Zones, and Core Building Blocks
Before you can design secure or resilient systems, you need a rock-solid grasp of how AWS is physically and logically laid out. This module walks through Regions, Availability Zones, and edge locations, and shows how services like Amazon EC2, Amazon S3, and Amazon RDS fit into that global fabric.
Big Picture: Why AWS Global Infrastructure Matters
Why Global Infrastructure First?
Before diving into services, you need a map of where AWS actually runs. The global layout underpins security, reliability, performance, and cost decisions.
Link to Well-Architected
The Reliability pillar is about workloads performing correctly and consistently. To design for reliability, you must understand Regions, Availability Zones, and edge locations.
Region Choice Matters
Choosing a Region is not just a dropdown. It affects latency to users, data residency and regulations, fault isolation boundaries, and even pricing for many services.
Edge Locations
AWS also runs edge locations for CloudFront and Route 53. These are separate from Regions and exist to bring content and DNS responses closer to end users.
What You Will Practice
You will build a mental model of Regions, AZs, and edges; see how EC2, S3, and RDS map onto them; and practice choosing the right scope in exam-style scenarios.
Regions: The Highest-Level Building Block
What Is a Region?
An AWS Region is a physical geographic area, like us-east-1 or eu-west-1. Each Region contains multiple isolated Availability Zones.
Region Scope
Most services are Region-scoped: EC2, RDS, VPCs, and security groups. AWS does not automatically replicate your data across Regions.
Design Impact: Latency
Choosing a Region close to users reduces network latency. For global apps, you may need multiple Regions or edge services to serve users efficiently.
Design Impact: Compliance & Cost
Region choice affects data residency compliance and price. The same instance type can cost different amounts in different Regions.
Exam Angle
Multi-Region appears in questions about disaster recovery, global users, or strict legal requirements around where data is stored.
Availability Zones: Fault Domains Inside a Region
What Is an AZ?
An Availability Zone is one or more discrete data centers in a Region, with redundant power and networking, connected to other AZs by fast, low-latency links.
Independent Failure Domains
Each AZ is designed as an independent failure domain. Issues in one AZ, like power or cooling failures, should not affect other AZs in the Region.
AZ Naming Gotcha
Labels like us-east-1a are account-relative. Your us-east-1a may map to a different physical AZ than another account’s us-east-1a.
Multi-AZ for Reliability
Putting everything in one AZ creates a single point of failure. Spreading resources over two or more AZs improves resilience without cross-Region latency.
Typical Multi-AZ Patterns
Common patterns: EC2 Auto Scaling across AZs, RDS Multi-AZ with a standby in another AZ, and load balancers distributing traffic across AZ targets.
Designing a Simple Multi-AZ Web App
Scenario Setup
Design a public web app for users in eastern US: low latency, high availability, minimal complexity. This is a classic SAA-C03 style scenario.
Region and VPC
Choose us-east-1 for proximity and features. Create a VPC with at least two public and two private subnets, each pair in different Availability Zones.
Compute Layer
Launch EC2 web servers in an Auto Scaling group that spans the two public subnets. Ensure at least one instance per AZ for high availability.
Database and Load Balancer
Use RDS Multi-AZ for the database and place an Application Load Balancer in front of EC2, with targets registered in both AZs.
What You Gain
If one AZ fails, the ALB and RDS failover keep the app running in the other AZ. This is the default HA pattern the exam expects when no cross-Region need exists.
Edge Locations and CloudFront: Bringing AWS Closer to Users
What Are Edge Locations?
Edge locations are sites in major cities where AWS runs services that need to be close to users, mainly CloudFront and Route 53.
Not Regions or AZs
You do not run EC2 or RDS in edge locations. They cache or proxy traffic back to origins in Regions like S3 buckets or load balancers.
CloudFront Basics
CloudFront is a global CDN. You create a distribution with origins such as S3 or ALB, and it caches content at edge locations for lower latency.
Why Use CloudFront?
Benefits: improved performance, better availability under traffic spikes, and stronger security when combined with AWS WAF and private origins.
Mental Model
Think of Regions as where your core systems live, and edge locations as nearby kiosks that serve cached or proxied content to users worldwide.
Core Building Block 1: Amazon EC2 (Compute in a Region and AZ)
What Is EC2?
Amazon EC2 provides virtual servers called instances. You run them inside a Region and a specific Availability Zone via a VPC subnet.
Placement and Scope
EC2 instances live in subnets, and each subnet maps to one AZ. EC2 is Region-scoped for AMIs and snapshots but highly available at the AZ level.
Key Characteristics
Important aspects: many instance families, multiple pricing models, and storage via EBS volumes or ephemeral instance store.
EC2 for High Availability
Use Auto Scaling groups across multiple AZs and load balancers to avoid single-instance, single-AZ designs in production.
Link to Well-Architected
EC2 design choices affect performance efficiency and cost optimization, especially through right-sizing and pricing model selection.
Core Building Block 2: Amazon S3 (Regional Object Storage)
What Is S3?
Amazon S3 is object storage. You store data as objects in buckets, and each bucket lives in a single Region you choose at creation.
Built-In Multi-AZ
For standard classes, S3 automatically replicates data across multiple AZs within the Region to achieve very high durability.
Key Properties
S3 offers high durability, virtually unlimited scalability, and access via HTTP(S). It is often used as a CloudFront origin.
Typical Use Cases
Common uses: static website hosting, backups and logs, data lakes, and application assets shared across multiple AZs.
Cross-Region Needs
For multi-Region resilience or locality, configure S3 Cross-Region Replication or Multi-Region Access Points instead of trying to place S3 in specific AZs.
Core Building Block 3: Amazon RDS (Managed Relational Databases)
What Is RDS?
Amazon RDS is a managed service for relational databases such as MySQL, PostgreSQL, Oracle, SQL Server, MariaDB, and Aurora.
Region and AZ Scope
RDS is Region-scoped. Each DB instance runs in one AZ, but you can enable Multi-AZ to add a synchronous standby in another AZ.
Multi-AZ for HA
In Multi-AZ, RDS writes to a standby in a different AZ. Failover is automatic on outages, but the standby is not used for normal read traffic.
Read Replicas
Read replicas are asynchronous copies used to offload read traffic or support cross-Region reporting and DR, not strict high availability.
Aurora Highlights
Aurora stores data in a cluster volume replicated across three AZs, with multiple readers. It is optimized for high availability and fast failover.
Thought Exercise: Picking Region, AZs, and Services
Work through this scenario mentally and, if you like, jot down your design. Then compare to the suggested approach.
Scenario: A learning platform has users in both Europe and North America. Requirements:
- Low latency for both regions of users
- Highly available web front end
- Centralized relational database (for now) in Europe to satisfy data residency requirements
- Cost-conscious: avoid unnecessary complexity
Questions to answer:
- Which primary Region would you choose for the database and most backend services? Why?
- How would you deploy the web front end to achieve low latency for both continents?
- How would you design high availability for the database?
- Would you use CloudFront or just regional deployments? Explain your choice.
Pause and decide your design before reading the suggested approach below.
Suggested approach (do not peek until you’ve thought it through):
- Pick a European Region such as `eu-central-1` or `eu-west-1` for the primary RDS database to satisfy data residency.
- Deploy multi-AZ RDS in that Region.
- Run your core application stack (EC2, containers, or serverless) in the same Region, spread across at least two AZs.
- For low latency in North America, either:
- Use CloudFront in front of S3/static assets and an ALB origin in Europe, or
- If dynamic latency is critical, deploy a read-only stack or caching layer (e.g., CloudFront + API caching, or an additional front-end Region) while keeping writes in Europe.
On the exam, the best answer will depend on whether the question emphasizes data residency, latency, or simplicity/cost most strongly.
Quiz 1: Regions, AZs, and Edge Locations
Test your understanding of AWS Regions, AZs, and edge locations.
A company runs a web application on EC2 instances in a single subnet in us-east-1a. They want to improve availability against data center failures without changing Regions. What is the MOST appropriate change?
- Enable S3 Cross-Region Replication for the application data
- Add an Auto Scaling group and Application Load Balancer across subnets in at least two AZs in the same Region
- Move the EC2 instances to an edge location using CloudFront
- Create a second VPC in another Region and add more EC2 instances there
Show Answer
Answer: B) Add an Auto Scaling group and Application Load Balancer across subnets in at least two AZs in the same Region
The goal is to protect against data center (AZ) failures within the same Region. The best approach is to use an Auto Scaling group and load balancer across subnets in multiple AZs in that Region. Cross-Region S3 replication and a second Region VPC introduce extra complexity and are not required by the question. CloudFront edge locations cannot host EC2 instances.
Quiz 2: EC2, S3, RDS in the Global Fabric
Check how well you can map core services to Regions, AZs, and edge locations.
Which statement is MOST accurate about how these services relate to Regions and AZs?
- EC2 and RDS are global services, while S3 is scoped to a single Availability Zone
- EC2 instances and RDS DB instances run in a single AZ, S3 buckets are Regional and store data across multiple AZs, and CloudFront uses edge locations
- S3 buckets automatically replicate data to all Regions, while RDS Multi-AZ replicates across edge locations
- CloudFront distributions run inside your VPC subnets in each AZ
Show Answer
Answer: B) EC2 instances and RDS DB instances run in a single AZ, S3 buckets are Regional and store data across multiple AZs, and CloudFront uses edge locations
EC2 and RDS instances are placed in a specific AZ within a Region. S3 buckets are Regional and, for standard classes, automatically store data across multiple AZs in that Region. CloudFront is a global CDN using edge locations. The other options misstate scopes or replication behavior.
Core Terms Review
Use these flashcards to reinforce key terms and their roles in AWS global infrastructure.
- AWS Region
- A physical geographic area, such as us-east-1 or eu-west-1, containing multiple isolated Availability Zones. Most AWS resources are created within a specific Region.
- Availability Zone (AZ)
- One or more discrete data centers with redundant power, networking, and connectivity in a Region. AZs are independent failure domains connected by low-latency links.
- Edge location
- An AWS site in a major city used mainly by CloudFront and Route 53 to cache or serve content and DNS responses closer to end users.
- Amazon EC2
- A core compute service providing virtual servers (instances) that run inside a VPC subnet in a specific Availability Zone within a Region.
- Amazon S3
- A Regional object storage service where buckets live in a single Region and, for standard classes, data is automatically stored across multiple AZs.
- Amazon RDS Multi-AZ
- A high-availability configuration where RDS maintains a synchronous standby DB instance in another AZ within the same Region and fails over automatically on outages.
- Amazon CloudFront
- AWS’s global content delivery network that uses edge locations to cache and deliver content from origins such as S3, ALB, or HTTP servers, improving latency and offloading origins.
- Multi-Region architecture
- An architecture that deploys workloads across two or more AWS Regions, often for global users, disaster recovery, or strict data residency requirements.
Key Terms
- Amazon S3
- A Regional object storage service where buckets live in a single Region and, for standard classes, data is automatically stored across multiple AZs.
- AWS Region
- A physical geographic area, such as us-east-1 or eu-west-1, containing multiple isolated Availability Zones. Most AWS resources are created within a specific Region.
- Amazon EC2
- A core compute service providing virtual servers (instances) that run inside a VPC subnet in a specific Availability Zone within a Region.
- Amazon RDS
- A managed relational database service for engines such as MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Amazon Aurora, deployed within a Region and AZ.
- Edge location
- An AWS site in a major city used mainly by CloudFront and Route 53 to cache or serve content and DNS responses closer to end users.
- Amazon CloudFront
- AWS’s global content delivery network that uses edge locations to cache and deliver content from origins such as S3, ALB, or HTTP servers, improving latency and offloading origins.
- Amazon RDS Multi-AZ
- A high-availability configuration where RDS maintains a synchronous standby DB instance in another AZ within the same Region and fails over automatically on outages.
- Multi-AZ architecture
- A design that spreads resources such as EC2 instances or RDS instances across at least two Availability Zones in the same Region to improve availability.
- Availability Zone (AZ)
- One or more discrete data centers with redundant power, networking, and connectivity in a Region. AZs are independent failure domains connected by low-latency links.
- Multi-Region architecture
- An architecture that deploys workloads across two or more AWS Regions, often for global users, disaster recovery, or strict data residency requirements.