Lesson 034 · AWS Learning Path

AWS 034: AWS global infrastructure

Anil Jalela · Published Jul 29, 2025 · 5 min read

The problem

"AWS is global" is too vague for architecture. Workloads use a partition, account, Region, Availability Zone, Local Zone, edge network, and service-specific resource scope. Data is not automatically copied everywhere.

Final outcome

You will map the AWS location hierarchy, inspect Regions and Availability Zones available to the account, and choose a primary Region for a scenario using latency, regulation, service availability, resilience, operations, and cost.

Location hierarchy

AWS partition
└── Region
    ├── Availability Zone
    │   └── one or more data centers
    ├── Local Zone, where offered
    └── regional service endpoints

AWS edge network and other specialized locations use service-specific models.

The commercial AWS partition, AWS GovCloud (US), and AWS China partitions have separate account and endpoint boundaries. An ordinary commercial account cannot simply select a China or GovCloud Region.

Region

A Region is a separate geographic area. Most regional resources remain in the Region where they are created. Replication to another Region occurs only when the service and architecture configure it.

Select a Region using:

• legal and regulatory requirements;
• data residency;
• latency to users and dependencies;
• service and feature availability;
• expected capacity;
• price;
• carbon or sustainability requirements where relevant;
• disaster-recovery design;
• team access and operations;
• network connectivity.

The closest Region by distance may not produce the lowest application latency or meet legal and feature needs.

Availability Zone

An Availability Zone is an isolated location within a Region with redundant infrastructure and high-bandwidth, low-latency connectivity to other zones in the Region.

Deploying across zones can protect against a zonal failure. It can also add data-transfer cost, replication behavior, and application complexity. A multi-AZ label is useful only when requests, state, dependencies, health checks, and recovery actually use the zones.

Local Zones and Wavelength

Local Zones place supported resources closer to a metropolitan area for low-latency needs while connecting to a parent Region. Wavelength Zones place supported compute and storage at telecommunications-provider 5G edge locations.

These are not replacements for Regions or ordinary Availability Zones. Service availability, control-plane location, dependency paths, resilience, and pricing must be evaluated.

Edge locations

AWS edge services, including Amazon CloudFront and Route 53, use distributed points of presence according to each service's design. An edge location is not an Availability Zone where arbitrary VPC resources can be launched.

A CloudFront cache near a user can reduce content latency, but the origin, application, and data tiers still have regional architecture and failure behavior.

Inspect Regions

Run the AWS 033 preflight, then:

aws ec2 describe-regions \
  --profile course \
  --all-regions \
  --query 'Regions[].{Region:RegionName,Status:OptInStatus,Endpoint:Endpoint}' \
  --output table \
  --no-cli-pager

--all-regions includes Regions regardless of ordinary enablement visibility for the account where supported. OptInStatus helps distinguish enabled, enabled-by-default, and not-opted-in states.

Do not enable a Region in this lesson.

Inspect Availability Zones

COURSE_REGION="ap-south-1"
aws ec2 describe-availability-zones \
  --profile course \
  --region "$COURSE_REGION" \
  --filters Name=zone-type,Values=availability-zone \
  --query 'AvailabilityZones[].{Name:ZoneName,Id:ZoneId,State:State}' \
  --output table \
  --no-cli-pager

Zone names and zone IDs are different. Zone IDs identify physical zones consistently across accounts. Historical per-account name mapping means that a name such as us-east-1a can represent different physical zones between some older accounts. AWS documentation describes mapping changes for accounts created from November 2025. Use zone IDs for cross-account physical alignment.

Service scope exercise

Classify:

Service-specific exceptions matter. For example, a global control plane can still have regional data paths or resiliency dependencies.

Region decision exercise

Scenario:

• most learners are in India;
• personal data must remain in India;
• the required managed service is available in Mumbai and Hyderabad;
• on-premises connectivity terminates in Mumbai;
• a separate recovery Region is required;
• the budget is limited;
• RTO is four hours and RPO is one hour.

Create region-decision.md with:

1. hard constraints;
2. candidate Regions;
3. latency evidence method;
4. service and feature comparison;
5. data-residency interpretation;
6. primary Region choice;
7. recovery Region choice;
8. replication and transfer implications;
9. operational ownership;
10. rejected alternative.

Do not claim a recovery Region meets RTO/RPO until replication, deployment, secrets, DNS, capacity, and restoration are tested.

Count warning

AWS adds Regions, Availability Zones, Local Zones, and edge locations. Do not build a lesson or exam strategy around a memorized infrastructure count. Use the current official infrastructure pages when a count is required.

Stable concepts are more important:

• Regions are isolated geographic areas;
• Regions contain multiple Availability Zones;
• zonal resources have zonal failure boundaries;
• cross-Region behavior must be designed;
• edge improves supported service delivery and does not host every workload.

Common failures

Completion gate

Pass when the learner correctly maps partition, Region, AZ, Local Zone, Wavelength, and edge; produces current read-only Region/AZ evidence; uses zone IDs correctly; and makes a requirement-driven primary and recovery Region decision.

No Regions were enabled and no resources were created.

Official sources

• AWS Regions and Availability Zones
• AWS Regions
• AWS Availability Zones and zone IDs
• AWS Local Zones concepts