AWS Foundations
AWS Global Infrastructure
Understand Regions, Availability Zones, edge locations, and global services as the physical map behind AWS architecture decisions.
After this, you will understand
Region and Availability Zone decisions explain most AWS answers about latency, resilience, disaster recovery, compliance, and service availability.
A Region is a geographic AWS area, and Availability Zones are separate data center groups inside that Region.
Learners memorize service names without knowing whether the service is regional, zonal, edge-based, or globally scoped.
Choose Regions for users, compliance, service availability, and disaster recovery, then spread critical workloads across multiple Availability Zones.
Think before readingWhy does an exam answer often prefer Multi-AZ before multi-Region?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- AWS Regions
- Availability Zones
- Local Zones
- Wavelength Zones
- Edge locations
- Regional, zonal, and global services
- Latency and proximity
- Data residency and compliance
- High availability across Availability Zones
- Disaster recovery across Regions
1. Plain-English Definition
AWS global infrastructure is the worldwide physical and logical footprint that AWS services run on.
The most important units are Regions and Availability Zones. A Region is a separate geographic area such as us-east-1, eu-west-1, or ap-southeast-2. An Availability Zone is one or more physically separate data centers inside a Region, connected with high-speed, low-latency networking.
For a beginner, the useful mental model is:
world -> Region -> Availability Zone -> data centers -> physical infrastructure
AWS also has edge locations for services that need to be closer to users, such as CloudFront and Route 53. Some newer infrastructure options, such as Local Zones and Wavelength Zones, place selected services closer to specific metro areas or telecom networks.
This infrastructure map matters because cloud architecture is not location-free. Your resources run somewhere. Users connect from somewhere. Data may legally need to stay somewhere. Failures can affect one Availability Zone, a Region, or a service control plane. Good architecture knows the map.
2. Why This Matters In AWS
Many AWS design choices are really placement choices.
If users are in Singapore, running everything in Northern Virginia may add unnecessary latency. If customer data must stay in Germany, the Region choice is part of compliance. If an application must survive a data center failure, single-AZ deployment is not enough. If the business needs disaster recovery after a regional outage, Multi-AZ is not enough by itself.
For SAA-C03, the global infrastructure model is everywhere:
- Multi-AZ RDS for high availability
- Auto Scaling groups spanning subnets in multiple Availability Zones
- Elastic Load Balancers routing across healthy targets
- S3 durability within a Region
- CloudFront caching content at edge locations
- Route 53 routing users to healthy endpoints
- multi-Region read replicas, backups, or failover for disaster recovery
The exam often tests whether you can match the failure requirement to the right placement level.
3. The Beginner Mental Model
Think of a Region as a city where AWS has multiple isolated campuses. Each campus is an Availability Zone. If you put all your servers on one campus, a campus-level problem can still take you down. If you spread servers across campuses in the same city, you can survive more local failures.
That is the basic availability pattern:
one Region
-> Availability Zone A
-> Availability Zone B
-> Availability Zone C
For many production systems, the first reliability move is to use multiple Availability Zones in one Region. This usually gives strong availability with less complexity than active-active multi-Region architecture.
Multi-Region is a bigger move. It can help with disaster recovery, global latency, strict data isolation, or regional business continuity. But it introduces harder problems: data replication, failover, consistency, routing, cost, deployment coordination, monitoring, and operational practice.
4. What That Mental Model Misses
The simple map hides several details.
First, not every service works the same way. EC2 instances are placed in subnets, and subnets live in one Availability Zone. S3 buckets are regional, but AWS replicates data across multiple facilities inside that Region. IAM is global. Route 53 is global. CloudFront uses edge locations. DynamoDB global tables replicate across Regions when configured.
Second, Availability Zone names are account-mapped. us-east-1a in one account may not point to the same physical AZ as us-east-1a in another account. AWS uses AZ IDs when you need a consistent physical mapping across accounts.
Third, multi-Region does not automatically mean active-active. A system can be backup-and-restore, pilot light, warm standby, active-passive, or active-active. Each option has different recovery time, recovery point, cost, and operational complexity.
Fourth, low latency is not only geography. Caching, database placement, connection reuse, private networking, DNS routing, and service architecture all affect latency. Region choice is one big lever, not the only lever.
5. AWS Mechanics
When you launch resources, you usually choose a Region first. Then, for zonal services, you choose subnets or Availability Zones.
EC2 instances, EBS volumes, and subnets are Availability Zone scoped. An EBS volume must be in the same AZ as the instance that attaches it. A subnet belongs to one AZ. An Auto Scaling group can span subnets in multiple AZs. A load balancer can route to healthy targets across enabled AZs.
RDS can run in a Multi-AZ configuration where AWS maintains a standby in another AZ for failover. Aurora stores six copies of data across three AZs by design. EFS can provide a regional file system with mount targets in multiple AZs.
S3 is regional. You choose a Region for the bucket, but you do not choose an individual AZ. S3 is designed for high durability by storing data across multiple facilities within the Region.
CloudFront uses edge locations. The origin may be S3, an Application Load Balancer, EC2, or another HTTP endpoint, but users often receive cached content from a nearby edge location.
6. Architecture Examples
A basic highly available web app in one Region might use:
- an Application Load Balancer across at least two Availability Zones
- EC2 instances or containers in private subnets across those AZs
- an RDS Multi-AZ database
- S3 for object storage
- CloudFront for cached static content
- Route 53 for DNS
This design protects against many AZ-level failures.
A disaster recovery design might add another Region:
- automated backups copied to another Region
- infrastructure templates ready to deploy
- a read replica or standby database in the recovery Region
- Route 53 failover routing
- runbooks and tested recovery procedures
The second design is more expensive and operationally demanding. It should be driven by business recovery objectives, not by a vague desire to be "more redundant."
7. SAA-C03 Exam Signals
"Highly available within a Region" usually points to multiple Availability Zones, load balancing, Auto Scaling, Multi-AZ databases, and managed services designed for regional resilience.
"Disaster recovery if an entire Region is unavailable" points to multi-Region architecture, backup copies, replicas, Route 53 failover, or active-active designs.
"Low latency for global users" often points to CloudFront, Global Accelerator, Route 53 latency routing, or placing workloads closer to users.
"Data must remain in a specific country or jurisdiction" makes Region selection and data residency central.
"Service is unavailable in the selected Region" means you may need another Region or another service. AWS service availability is not identical in every Region.
8. Common Traps
Do not confuse Availability Zones with Regions. Multi-AZ and multi-Region solve different failure scopes.
Do not assume that deploying two instances in one subnet gives high availability. One subnet maps to one Availability Zone. Use subnets across multiple AZs.
Do not assume every service is regional. IAM and Route 53 are global. EC2 instances are zonal. S3 buckets are regional. CloudFront is edge-based.
Do not choose multi-Region when the requirement only asks for high availability within a Region and low operational overhead. Multi-Region may be more resilient, but it is not always the best exam answer.
Do not forget data transfer and replication costs. Moving data between AZs, Regions, and users can affect the architecture.
9. What To Learn Next
After the infrastructure map, study the Shared Responsibility Model. It explains which parts of this stack AWS operates and which parts the customer must configure correctly.
Then move into the VPC Networking Model, because VPC design is where account, Region, AZ, subnet, and routing concepts become concrete.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.