AWS Academy Cloud Foundations — Module 3: AWS Global Infrastructure Overview

Module Objective: Describe the components of the AWS global infrastructure — Regions, Availability Zones, and edge locations — and explain how to choose among them and combine them to build highly available architectures.

Builds on Module 1, which introduced Regions and Availability Zones briefly; this module goes deeper into how they fit together and how to design around them.

Regions

An AWS Region is a physical geographic area — such as US East (N. Virginia) or Asia Pacific (Tokyo) — that contains multiple, isolated data center clusters. Each Region is completely independent of every other Region: resources don't automatically replicate or fail over across Regions unless a customer explicitly configures that.

Property	Detail
Isolation	Each Region is isolated from every other Region to contain the impact of failures and to support data-residency requirements
Naming	Regions are named by geography and given a code, e.g. `us-east-1`, `eu-west-2`, `ap-southeast-1`
Service availability	Not every AWS service is available in every Region, especially newly launched ones
Independent pricing	The same service can be priced differently from one Region to another

🔵 Note Some services — such as AWS Identity and Access Management (IAM) — are global rather than Region-scoped, meaning the same configuration applies across all Regions a customer uses.

Availability Zones

Each Region is made up of multiple Availability Zones (AZs) — one or more discrete data centers with redundant power, networking, and connectivity, housed in separate facilities. AZs within a Region are connected by high-bandwidth, low-latency private networking, but are physically separated far enough apart to reduce the odds that a single disaster (fire, flood, power outage) takes out more than one.

Property	Detail
Minimum per Region	Every AWS Region has a minimum of three Availability Zones
Naming	AZs are identified by a letter suffix on the Region code, e.g. `us-east-1a`, `us-east-1b`
Purpose	Deploying across multiple AZs is the primary mechanism for building fault-tolerant applications within a single Region

✅ Tip — Multi-AZ Is the Default Recommendation Running production workloads across at least two Availability Zones — rather than in just one — is one of the most repeated recommendations in the AWS Well-Architected Framework, because it protects against a single data center failure.

Edge Infrastructure

Beyond Regions and AZs, AWS operates edge infrastructure to bring content and, increasingly, compute physically closer to end users.

Component	Purpose
Points of Presence (PoPs)	Locations used by Amazon CloudFront and Amazon Route 53 to cache content and resolve DNS closer to users, reducing latency
AWS Local Zones	Smaller infrastructure deployments in large metro areas, placing compute and storage closer to dense population centers for latency-sensitive applications
AWS Wavelength	Embeds AWS compute and storage within telecommunications providers' 5G networks for ultra-low-latency mobile applications

🔵 Why It Matters Edge infrastructure targets a different problem than Regions and AZs: Regions/AZs are about durability and fault tolerance, while edge infrastructure is about reducing the physical distance — and therefore latency — between AWS resources and end users.

Extending AWS On-Premises

For workloads that must stay physically on-premises — due to latency, local data processing, or regulatory requirements — AWS offers ways to bring AWS infrastructure and APIs into a customer's own facility.

Service	What It Provides
AWS Outposts	Physical racks of AWS-managed compute and storage hardware installed in a customer's own data center, running the same APIs as the AWS cloud
AWS Direct Connect	A dedicated, private network connection from a customer's premises to AWS, bypassing the public internet

⚠️ Warning — Hybrid Isn't Free of Trade-offs Extending AWS on-premises still requires physical space, power, and often a minimum-term commitment. It solves specific latency or data-residency problems — it isn't simply "the cloud, but local," and it comes with its own operational overhead.

Choosing a Region

Selecting which Region(s) to deploy into is one of the first architectural decisions in any AWS project, and it typically weighs four factors.

Factor	Consideration
Compliance	Data residency, sovereignty, or industry regulations may require data to stay within a specific country or region
Proximity / latency	Choosing a Region physically close to end users reduces round-trip latency
Service availability	Newer or specialized services may only be available in a subset of Regions
Pricing	The same resource can cost different amounts in different Regions

✅ Tip — Many Workloads Span More Than One Region It's common to run a primary workload in one Region and replicate data or stand up disaster-recovery resources in a second Region, trading additional cost and complexity for resilience against a full Region-level event.

Designing for High Availability

AWS global infrastructure gives architects the raw materials for resilience; how those materials get used determines the actual availability of a workload.

Concept	What It Means
Fault tolerance	The ability of a system to keep operating correctly even when a component fails, typically by eliminating single points of failure
High availability	Designing a system to remain accessible and operational for as close to 100% of the time as possible, often measured as "nines" of uptime
Disaster recovery (DR)	The strategy and processes for restoring service after a larger-scale failure, such as the loss of an entire Region

🔵 Note Multi-AZ deployments address most single-data-center failures. Multi-Region deployments — a more advanced and costlier pattern — address the much rarer case of an entire Region becoming unavailable.

How Infrastructure Choices Show Up in the Console

In practice, most AWS global infrastructure decisions are made through a simple Region selector in the AWS Management Console, with AZ placement handled either automatically by a service or explicitly when launching a resource.

Where It Appears	What Happens
Console Region selector (top navigation)	Determines which Region's resources are being viewed or created
Amazon EC2 launch wizard	Lets a customer pick a specific Availability Zone, or leave it to AWS to choose
Amazon S3 bucket creation	A bucket is created in one selected Region, with data automatically spread across that Region's AZs

✅ Tip — Check the Region Selector First A very common source of "where did my resource go?" confusion for new AWS users is simply being in the wrong Region in the console. Checking the Region selector is often the first troubleshooting step.

Key Terms for Module 3

Region: An isolated, physical geographic area containing multiple Availability Zones
Availability Zone (AZ): One or more discrete data centers with redundant power and networking within a Region; every Region has at least three
Point of Presence (PoP): An edge location used by services like Amazon CloudFront and Route 53 to reduce latency for end users
AWS Local Zones: Smaller AWS infrastructure deployments in metro areas, placing compute closer to dense population centers
AWS Wavelength: AWS compute and storage embedded within telecom 5G networks for ultra-low-latency mobile applications
AWS Outposts: Physical AWS-managed racks installed in a customer's own data center, running the same APIs as the AWS cloud
AWS Direct Connect: A dedicated, private network connection between a customer's premises and AWS
fault tolerance: A system's ability to keep operating correctly despite the failure of a component
high availability: Designing a system to remain accessible and operational as close to 100% of the time as possible

Review Questions

What is the relationship between a Region and an Availability Zone, and what is the minimum number of AZs in every Region?
Why are Regions kept isolated from one another rather than automatically replicating data between them?
What problem do Points of Presence, Local Zones, and Wavelength each solve, and how do they differ from one another?
How does AWS Outposts differ from simply using AWS Direct Connect to link an on-premises data center to AWS?
What four factors typically drive the choice of which AWS Region to deploy into?
What is the difference between fault tolerance and disaster recovery?
Why might deploying an application across multiple Availability Zones not be sufficient protection against every possible failure?