Module 02: AWS Global Infrastructure

Learning Objectives

By the end of this module, you will be able to:

• Describe the hierarchical structure of AWS global infrastructure: Regions, Availability Zones, Edge Locations, and specialized zones
• Apply the four-factor decision framework to select the appropriate AWS Region for a given workload
• Explain the physical and logical isolation properties of Availability Zones and why multi-AZ deployment is a production requirement
• Differentiate between Edge Locations, Local Zones, Wavelength Zones, and Outposts in terms of purpose and use case
• Identify when to use single-Region vs. multi-Region architectures based on availability and latency requirements
• Describe how the AWS private backbone network connects Regions and enables low-latency inter-AZ communication
• Explain the difference between opt-in Regions, default Regions, and GovCloud Regions
• Map infrastructure placement decisions to their downstream effects on latency, compliance, availability, and cost

Prerequisites

• Completion of Module 01: Cloud Computing Principles
• Familiarity with basic networking concepts (latency, data centers)

Why This Matters

Every architecture decision you will ever make on AWS begins with one question: where does this run?

The physical location of your infrastructure determines four things simultaneously:

1. Latency to your end users (physics wins every time)
2. Compliance with data sovereignty and regulatory requirements
3. Availability during failures (how isolated are your redundant copies?)
4. Cost (pricing varies by Region, sometimes by 20% or more)

As a Solutions Architect, you will never design a system in the abstract. You design it for a specific geographic reality. A healthcare application handling EU patient data has a fundamentally different infrastructure strategy than a gaming backend serving players in Southeast Asia. The services you choose matter, but where you place them matters first.

This module teaches you the WHERE before subsequent modules teach you the WHAT.

Concepts

The AWS Global Network

📊 Architecture Diagram: AWS global infrastructure showing Regions, Availability Zones, and edge locations distributed worldwide.

AWS operates one of the largest privately-owned networks on the planet. This is not the public internet. It is a purpose-built, redundant, global backbone that connects every Region to every other Region through multiple independent fiber paths.

The numbers as of 2025:

AWS invests billions annually in physical infrastructure expansion. Why does this matter to you? Because this investment creates the foundation you build on. You do not need to negotiate with telecom carriers, lease dark fiber, or worry about undersea cable redundancy. That is handled at a layer below your concern. Your job is to understand what is available and use it correctly.

The private backbone means that traffic between Regions (for example, replicating a database from us-east-1 to eu-west-1) travels over AWS-owned fiber, not the public internet. This gives you predictable latency, higher throughput, and encryption in transit by default between AWS facilities.

Regions

📊 Architecture Diagram: Availability Zone architecture showing physically separate data centers connected by low-latency links within a Region.

A Region is a geographic area containing multiple, physically separated data center clusters. Each Region is fully isolated from every other Region. No data replicates between Regions unless you explicitly configure it to do so.

Naming convention:

Regions follow the pattern {area}-{sub-area}-{number}:

How to Choose a Region

This is a decision framework you will use on every project. Evaluate these factors in priority order:

1. Compliance and Data Sovereignty

This overrides everything else. If regulation requires data to stay within a specific country, your Region choice is already made. GDPR, FedRAMP, HIPAA BAA eligibility, and national data residency laws all constrain where you can operate. No amount of latency optimization justifies a compliance violation.

2. Proximity to Users

Physics is non-negotiable. Light in fiber travels at roughly 200,000 km/s. A request from Tokyo to us-east-1 in Virginia adds approximately 80-100ms of round-trip latency just from propagation delay. If your users are in Tokyo, ap-northeast-1 eliminates that penalty.

3. Service Availability

Not every AWS service launches in every Region simultaneously. New services typically debut in us-east-1, then expand. If your architecture depends on a specific service (Amazon Bedrock, for instance), confirm it is available in your target Region before committing.

Check current service availability: AWS Regional Services List

4. Pricing

The same service can cost different amounts in different Regions. A t3.medium EC2 instance in us-east-1 might be 10-20% cheaper than the identical instance in ap-southeast-2 (Sydney). When compliance and latency do not constrain you, cost becomes the tiebreaker.

✅Tip: Run production workloads in the Region closest to your users. Run non-production workloads (dev, test, CI/CD) in whichever Region offers the best pricing, since latency does not matter for internal tools.

GovCloud Regions

AWS GovCloud (US) consists of two isolated Regions (us-gov-west-1 and us-gov-east-1) designed for U.S. government agencies, contractors, and organizations that handle controlled unclassified information (CUI). They meet FedRAMP High, ITAR, and DoD SRG compliance requirements. GovCloud Regions are operated by U.S. persons on U.S. soil and are not accessible from standard AWS accounts.

Opt-in Regions vs. Default Regions

Most Regions are enabled by default in your AWS account. However, some newer Regions require you to explicitly opt in before you can create resources there. This exists to prevent accidental resource creation in Regions you do not intend to use. Examples of opt-in Regions include af-south-1 (Cape Town), ap-east-1 (Hong Kong), and me-south-1 (Bahrain).

You can enable opt-in Regions from the Account Settings page in the AWS Management Console.

Availability Zones

📊 Architecture Diagram: Edge locations and Points of Presence (PoPs) that bring content closer to end users for reduced latency.

An Availability Zone (AZ) is one or more discrete data centers within a Region, each with redundant power, networking, and connectivity. AZs are the fundamental building block of high availability on AWS.

Key properties of Availability Zones:

• Physical separation: AZs within a Region are located in distinct facilities, often kilometers apart. They sit on different flood plains, use independent power grids, and connect through separate network carriers.
• Low-latency interconnection: Despite physical separation, AZs within a Region connect through dedicated, high-bandwidth, low-latency fiber. Inter-AZ latency is single-digit milliseconds (typically 1-2ms).
• Independent failure domains: An AZ can experience a complete power failure, network partition, or natural disaster without affecting other AZs in the same Region.

AZ Naming

AZ identifiers look like us-east-1a, us-east-1b, us-east-1c. The letter suffix identifies the AZ within the Region.

⚠️Warning: AZ names are mapped differently per AWS account. Your us-east-1a might be a physically different data center than another account's us-east-1a. AWS randomizes this mapping to distribute load evenly. If you need to coordinate AZ placement across accounts (for example, shared VPC subnets), use AZ IDs (like use1-az1) which are consistent across accounts.

Why Multi-AZ is Mandatory for Production

This is not a suggestion. It is an architectural requirement.

A single AZ, no matter how well-engineered, is a single point of failure. AWS designs AZs to fail independently, which means deploying across two or more AZs gives you fault tolerance against an entire data center complex going offline.

Services like RDS, ELB, and ECS all offer built-in multi-AZ configurations. If you are deploying anything that matters to your business in a single AZ, you have made an architectural error.

Check Your Understanding: If us-east-1 has 6 AZs and you deploy your application across 3 of them, what is the maximum number of simultaneous AZ failures your application can survive while maintaining availability?

Edge Locations and Points of Presence

📊 Architecture Diagram: How to choose an AWS Region based on compliance, latency, service availability, and pricing considerations.

Edge Locations are AWS data centers positioned in major cities worldwide, far from any Region. They exist for one purpose: to bring content and services physically closer to end users.

Edge Locations host:

• Amazon CloudFront (CDN): Caches static and dynamic content at the edge
• Amazon Route 53 (DNS): Resolves DNS queries from the nearest edge
• AWS WAF: Filters malicious traffic at the edge before it reaches your origin
• Lambda@Edge / CloudFront Functions: Runs lightweight compute at the edge

With 400+ Edge Locations globally, AWS positions these in population centers where users actually are. Your origin server might be in us-east-1, but your cached content is served from an Edge Location in Mumbai, Johannesburg, or Buenos Aires.

Regional Edge Caches

Between your origin Region and the Edge Locations sits an intermediate tier: Regional Edge Caches. These are larger, higher-capacity caches that hold content longer than individual Edge Locations. When an Edge Location's cache expires, it checks the Regional Edge Cache before going all the way back to your origin. This reduces origin load and improves cache hit ratios for less-popular content.

How Edge Locations differ from AZs:

Local Zones

A Local Zone is an extension of an AWS Region placed in a large population center that does not have a full Region. Think of it as an AZ that AWS drops into a metro area where latency to the parent Region is too high for certain use cases.

Characteristics:

• Provides compute, storage, database, and other services with single-digit millisecond latency to users in that metro area
• Connected to the parent Region via AWS private network
• You manage resources using the same APIs and tools as any other AZ
• Must be explicitly opted in (not enabled by default)

Use cases:

• Real-time gaming servers that need sub-10ms latency to players in Los Angeles
• Media production and rendering workloads in content creation hubs
• Live video streaming with ultra-low latency
• Any application where the parent Region is too far from the user base

Currently, Local Zones exist in cities like Los Angeles, Houston, Miami, Boston, and over 30 other metro areas. Check the AWS Local Zones page for current availability.

✅Tip: Local Zones are not for general production workloads. They have a smaller subset of services compared to a full Region. Use them when latency to the nearest Region is the specific problem you are solving.

Wavelength Zones

Wavelength Zones embed AWS compute and storage inside telecommunications providers' 5G networks. The goal is extreme: deliver single-digit millisecond latency to mobile devices connected to that carrier's 5G network.

How it works:

Traffic from a 5G-connected device reaches the carrier's cell tower, then hits the Wavelength Zone directly without ever traversing the public internet or traveling to a Region. The compute happens at the edge of the mobile network itself.

Use cases:

• Autonomous vehicle decision-making that cannot tolerate network hops
• Augmented/virtual reality streaming
• Real-time industrial IoT processing
• Interactive live video and game streaming on mobile

When this matters vs. when it does not:

If your users connect over standard broadband, WiFi, or even 4G, Wavelength Zones provide no benefit. They are specifically optimized for the 5G carrier path. For most applications, a Regional deployment or a Local Zone provides sufficient latency. Wavelength is for the extreme edge of latency sensitivity on mobile networks.

AWS Outposts

Outposts is AWS infrastructure that runs in your own data center, co-location space, or on-premises facility. AWS ships you a physical rack (or a smaller 1U/2U server for the Outposts Servers form factor), installs it, and manages it. You get the same APIs, same tools, same services, but the hardware sits in your building.

Why it exists:

• Data residency: Some data absolutely cannot leave your facility (financial, healthcare, government)
• Low-latency local processing: Applications that must process data on-premises with sub-millisecond latency to local systems
• Hybrid consistency: Run the same application code and infrastructure-as-code templates across AWS Regions and your own facilities

What Outposts is NOT:

Outposts is not "private cloud." It is not you running AWS software on your own hardware. AWS owns, delivers, installs, and manages the hardware. It connects back to a parent Region for control plane operations. If the connection to the parent Region goes down, certain management operations become unavailable, though existing workloads continue to run.

Check Your Understanding: A financial services company needs to process trading data with sub-1ms latency to their existing on-premises systems, but also wants to use AWS services. The data cannot leave their facility due to regulation. Which infrastructure option is the best fit?

Choosing Your Infrastructure Strategy

Not every application needs global distribution. Most do not. Here is how to think about infrastructure strategy based on requirements:

Single-Region, Multi-AZ

The default for most workloads.

Your application runs in one Region, deployed across two or more AZs. This gives you high availability against data center failures while keeping architecture simple and costs predictable.

• Recovery Time Objective (RTO): Minutes
• Latency: Optimized for one geographic area
• Complexity: Low
• Cost: Baseline

Multi-Region Active-Passive (Disaster Recovery)

A secondary Region stands by with replicated data but does not serve traffic. If the primary Region experiences a catastrophic failure (extremely rare, but possible), you fail over to the secondary.

• RTO: Minutes to hours (depending on automation)
• Latency: Optimized for one geographic area (primary)
• Complexity: Medium
• Cost: Baseline + standby infrastructure + data replication

Multi-Region Active-Active (Global Applications)

Multiple Regions serve traffic simultaneously. Users connect to the nearest Region. Data replicates bidirectionally. This is the architecture for global-scale applications like streaming platforms, social media, and financial trading systems.

• RTO: Near-zero (traffic routes around failure automatically)
• Latency: Optimized globally
• Complexity: High (conflict resolution, eventual consistency)
• Cost: Highest (full infrastructure in each Region)

Decision tree:

⚠️Warning: Do not default to multi-Region for the sake of appearing sophisticated. Multi-Region active-active introduces significant complexity in data consistency, conflict resolution, and operational burden. Choose it when the requirements demand it, not as a resume-driven architecture decision.

Instructor Notes

• Start with a globe visualization showing AWS Regions and ask students to identify which Region they would use for different scenarios (EU healthcare app, U.S. government workload, gaming company in Southeast Asia)
• Demonstrate the Region selector in the AWS Console and show how the service list changes between Regions
• Use the AWS Global Infrastructure interactive map during the lesson
• The AZ ID vs. AZ name distinction is a common source of confusion in multi-account environments. Use a concrete example with two accounts showing different AZ name mappings to the same physical AZ ID
• Emphasize that multi-AZ is a day-one decision, not something you add later. Architecture choices made at the start compound throughout the lifecycle
• For the lab, students will use the AWS CLI to enumerate Regions, AZs, and Local Zones available to their account, then analyze latency differences using CloudFront distribution metrics

Key Takeaways

1. Regions are fully isolated. Data stays in a Region unless you explicitly move it. This is your primary tool for compliance and data sovereignty.

2. Availability Zones are your minimum unit of fault tolerance. Multi-AZ is not optional for production workloads. Period.

3. Edge Locations solve the latency problem for content delivery. They cache content close to users without requiring you to deploy full infrastructure in dozens of cities.

4. Local Zones, Wavelength Zones, and Outposts are specialized tools. Do not reach for them unless you have a specific latency, connectivity, or data residency requirement that a standard Region cannot satisfy.

5. Region selection is a requirements-driven decision, not a default. Always evaluate compliance, latency, service availability, and cost in that priority order.

6. The AWS private backbone is invisible but foundational. Inter-Region and inter-AZ traffic travels over AWS-owned infrastructure, giving you predictable performance without managing the network yourself.

7. Start simple, expand when requirements demand it. Single-Region Multi-AZ covers the vast majority of workloads. Add complexity only when you have a documented reason.