What is the difference between an AWS Region and an Availability Zone?
A Region is a separate geographic area, like Mumbai, with its own set of data centres. An Availability Zone is one or more isolated data centres inside a Region, with its own power and networking. You spread an app across AZs to survive a data-centre failure, and across Regions to survive a whole-area outage or to be closer to users.
Explain it simply
Think of a bank. A Region is a city where the bank operates, like Mumbai or Hyderabad. An Availability Zone is one branch building inside that city. Each branch has its own power backup and staff, so if one branch has a fire, the others in the city keep working. They are close enough to share records quickly over fast private links.
If the whole city is hit by floods, you need a branch in another city. That is a multi-Region setup.
Example
An exam-results website hosted in the Mumbai Region (ap-south-1):
Region: ap-south-1 (Mumbai)
AZ ap-south-1a: web server 1, primary database
AZ ap-south-1b: web server 2, standby database
AZ ap-south-1c: web server 3
Load balancer spreads traffic across all three AZs.
If ap-south-1a loses power:
- servers in 1b and 1c keep serving
- the standby database in 1b takes overUsers barely notice. Without the second and third AZ, the site would be down.
How it works
- Region: a physical location in the world. Each has a code such as
ap-south-1(Mumbai) orap-south-2(Hyderabad). Regions are isolated from each other, and your data stays in the Region you choose unless you copy it elsewhere. - Availability Zone: one or more discrete data centres with redundant power, networking and connectivity. Most Regions have three or more AZs. They are physically separated so one local disaster is unlikely to hit two of them, but connected with high-bandwidth, low-latency links.
- AZ names are per account. Your
ap-south-1amay not be the same physical AZ as another account'sap-south-1a. AZ IDs (likeaps1-az1) identify the real location. - Scope of services: some resources live in one AZ (an EC2 instance, an EBS volume, a subnet). Some are regional and already spread across AZs (S3 Standard, DynamoDB, an Application Load Balancer spanning several subnets). A few are global (IAM, Route 53, CloudFront).
How to choose a Region
- Latency: closer to your users is faster.
- Data rules: some data must stay in a particular country.
- Service availability: new services do not launch in every Region at once.
- Cost, which differs between Regions.
Real-world use
- An Indian startup picks Mumbai or Hyderabad so pages load fast for Indian users and data stays in India.
- An RDS database runs in Multi-AZ mode so a standby in another AZ takes over automatically.
- A large payments company keeps a copy of critical data in a second Region for disaster recovery.
Common mistakes
- Running everything in a single AZ and calling it "highly available".
- Thinking a Region and an AZ are the same thing, or that one AZ is one server.
- Going multi-Region on day one. It adds data-sync complexity that most apps do not need; multi-AZ covers most failures.
- Forgetting that data transfer between AZs and between Regions usually costs money.
What to say in the interview
"A Region is a separate geographic area such as Mumbai, fully isolated from other Regions. Inside each Region there are multiple Availability Zones, each made of one or more data centres with independent power and networking, linked by low-latency connections. For high availability I deploy across at least two AZs behind a load balancer and use a Multi-AZ database. For disaster recovery or global users I'd add a second Region. I choose Regions by user latency, data residency rules, service availability and cost."
Follow-up questions
- Which AWS services are global, which are regional and which are zonal?
- How would you design an app to survive the loss of one AZ?
- What is the difference between high availability and disaster recovery?
- What are edge locations, and how are they different from AZs?
Go deeper
Read these once the basics above feel easy.
Edge locations are separate from Regions and AZs. CloudFront and Route 53 use them to cache content and answer DNS queries close to users. Local Zones and Wavelength Zones extend a Region to specific cities or telecom networks for very low latency.
Multi-Region designs choose between active-passive (a warm standby Region, simpler) and active-active (both serve traffic, which needs conflict handling for writes). Tools include S3 Cross-Region Replication, DynamoDB global tables, Aurora Global Database and Route 53 health-check failover. Define RTO (how fast you must recover) and RPO (how much data you can lose) first; they decide the design.