AWS Global Infrastructure Explained Simply: Regions, Availability Zones, Local Zones, Edge Locations & Disaster Recovery

  • Post author:
  • Post category:aws
  • Post comments:0 Comments

AWS Global Infrastructure Explained Simply: Regions, Availability Zones, Local Zones, Edge Locations & Disaster Recovery

If you are learning AWS, one of the first things you should understand is the AWS Global Infrastructure.

At first, words like Region, Availability Zone, Local Zone, Edge Location, RTO and RPO can look confusing.

Don’t worry.

In this article, we will understand them with a very simple example.

Think about AWS like a huge city network.

World
  ↓
Region
  ↓
Availability Zone
  ↓
Buildings
  ↓
Servers

Let’s understand each one step by step.

1. What Is AWS Global Infrastructure?

AWS has infrastructure distributed across different geographical locations around the world.

The important concepts are:

  • Region
  • Availability Zone (AZ)
  • Local Zone
  • Edge Location / Point of Presence (PoP)

And when we talk about disaster recovery, we also need to understand:

  • RTO
  • RPO
  • Backup and Restore
  • Pilot Light
  • Active-Passive / Warm Standby
  • Active-Active

These are the main topics covered in the source material.

2. What Is an AWS Region?

Let’s start with the easiest concept.

Think of a Region as a city.

For example:

India
  |
  └── Mumbai Region

An AWS Region is a geographical area where AWS has a collection of Availability Zones.

For example:

Mumbai Region
   |
   |--- AZ-1
   |
   |--- AZ-2
   |
   |--- AZ-3

So remember:

Region = Big geographical area

The source material uses the analogy of a city/geographical area containing multiple Availability Zones.

3. Why Does AWS Have Different Regions?

You may ask:

“Why doesn’t AWS just put everything in one location?”

There are several reasons.

Reason 1: Lower Latency

Simple rule:

Closer = Faster

Suppose your users are in India.

If your application is also running in India:

User in India
      |
      | Short distance
      ↓
AWS India Region

The response can generally travel a shorter network distance.

But if your application is running far away:

User in India
      |
      |--------------------|
                           ↓
                     AWS Region
                     in America

The network distance is greater, so latency can be higher.

The source specifically describes Region placement as useful for reducing latency.

Reason 2: Compliance

Some businesses have requirements around where certain data can be stored.

For example, an organization may need certain data to remain within a particular country.

So choosing an appropriate AWS Region can be important for compliance requirements.

The source notes data-location requirements as one reason for having Regions.

Reason 3: Disaster Isolation

Suppose something goes wrong in Region 1.

Another Region can be geographically separate.

For example:

Mumbai Region

       ❌ Problem


Singapore Region

       ✅ Available

The source describes Regions as independent for disaster isolation.

4. AWS Region Names

You may have seen names such as:

ap-south-1
ap-southeast-1
us-east-1

These names contain information about the geographical area.

For example:

ap-south-1

can be understood as:

ap
 ↓
Asia Pacific

south
 ↓
South Asia

1
 ↓
Region identifier

The source uses this style of breakdown for Region identifiers.

5. What Is an Availability Zone?

Now we go one level deeper.

If:

Region = City

then you can think of:

Availability Zone = Building / group of buildings

For example:

Mumbai Region
       |
       |--- AZ-1
       |--- AZ-2
       |--- AZ-3

Each Availability Zone contains physical infrastructure.

The source describes an AZ as a building or group of buildings containing physical servers.

6. Why Do We Need Multiple Availability Zones?

Imagine your application is running only in AZ-1.

Mumbai Region

AZ-1
  |
Your Application

Now suppose AZ-1 has a major infrastructure failure.

Your application could become unavailable.

Instead:

Mumbai Region

AZ-1  → Application
AZ-2  → Application
AZ-3  → Application

If one AZ has a problem, the application can potentially continue operating through another AZ, depending on how the application is designed.

This is why multiple AZs are important for availability and resilience.

The source notes that multiple AZs help survive a single data-center failure.

7. Are Availability Zones Close Together?

They are geographically separated but still connected with AWS networking.

The source notes that AZs are generally separated by a distance intended to provide both fast communication and isolation, and that their power, cooling and networking are independent.

Think:

             Mumbai Region

       AZ-1              AZ-2
        🏢                 🏢
         \               /
          \             /
           \-----------/
             Private
             network

The important idea is:

AZs are separate enough for isolation, but connected enough for applications to communicate efficiently.

8. Region vs Availability Zone

This is a very common interview question.

Remember:

Region
   |
   |--- Availability Zone
   |
   |--- Availability Zone
   |
   |--- Availability Zone

Region

A geographical area containing multiple AZs.

Availability Zone

An isolated infrastructure location within a Region.

Easy Example

Think about a city.

City = Region

Building 1 = AZ-1
Building 2 = AZ-2
Building 3 = AZ-3

Very easy to remember.

9. Regional Services vs Zonal Services

This is another important concept.

Some AWS services are regional, while some resources are tied to a particular Availability Zone.

The source gives examples such as EC2 and EBS as zonal services/resources, while S3, DynamoDB and Lambda are presented as regional services with AWS-managed multi-AZ availability.

Zonal Example

Think about an EC2 instance.

You launch an EC2 instance in:

Mumbai Region
    |
    └── AZ-1
         |
         └── EC2

That particular EC2 instance belongs to that AZ.

Similarly, EBS volumes are associated with an AZ.

Regional Example

Some AWS services are managed across multiple AZs by AWS.

Examples from the notes include:

S3
DynamoDB
Lambda

The important thing to remember is:

Regional does not automatically mean that every service stores your data in every Region.

A Region and multiple AZs are different concepts.

10. Global Services

Some AWS services operate globally rather than being tied to a single Region in the same way as typical regional resources.

Examples from the source include:

  • IAM
  • CloudFront
  • Route 53

 

Think:

                    Globe
                      |
        -----------------------------
        |             |             |
       IAM         Route 53      CloudFront

11. What Is a Local Zone?

Now we come to Local Zone.

Suppose the nearest AWS Region is quite far away from your users.

For example:

User
 |
 |--------------------------|
                             |
                       AWS Region

Maybe the distance causes additional latency.

AWS Local Zones can provide selected AWS infrastructure services closer to end users.

The source gives an example where the parent Region is Mumbai and a Local Zone is closer to Kolkata. It describes selected services such as EC2 and EBS being available there while relying on the parent Region for other services such as S3 and DynamoDB.

12. Why Do We Need Local Zones?

Simple answer:

To bring selected compute/storage capabilities closer to users.

Imagine:

AWS Region
     |
     | 1500+ km
     |
Kolkata
     |
     User

If latency matters significantly, having infrastructure closer to the user can help.

The source uses a video-call type of workload as an example where latency can matter.

13. Important Point About Local Zones

A Local Zone is not simply another complete AWS Region.

It provides a selected set of services and remains associated with a parent Region.

Think:

Parent Region
     |
     |
Local Zone
     |
     |--- EC2
     |--- EBS
     |
     └── Uses parent Region
         for other capabilities

The source specifically points out that the Local Zone depends on the parent Region for services such as S3 and DynamoDB in the example.

14. When Is a Local Zone Useful?

Imagine your application:

Application
     |
     ↓
Database

If the application constantly needs to communicate with a database that remains in the parent Region, moving only the application closer to the user may not eliminate all latency.

The source makes this exact point: if every application call needs to communicate with the database in the parent Region, a Local Zone may not provide the expected benefit for that use case.

So don’t think:

“Local Zone = everything becomes faster.”

Instead think:

“Local Zone = selected infrastructure is placed closer to users.”

15. What Is an Edge Location?

Now we have:

Region
Availability Zone
Local Zone

There is one more important concept:

Edge Location, also called a Point of Presence (PoP).

Edge Locations are locations where AWS operates certain services closer to users.

The source explains that AWS manages and operates these locations and that customers do not deploy their own servers there.

16. CloudFront and Edge Locations

One important service associated with Edge Locations is:

Amazon CloudFront

CloudFront is a CDN.

CDN means:

Content Delivery Network.

Suppose you have a website with:

Images
Videos
CSS
JavaScript

Instead of making every user travel all the way to your origin server, cached content can be served from an edge location closer to the user.

The source specifically describes CloudFront as a CDN used for caching static content such as videos and images.

17. Route 53 and Edge Locations

Another important AWS service mentioned in the notes is:

Route 53

Route 53 is AWS’s DNS service.

DNS basically converts something like:

amazon.com

into an IP address/endpoint.

The source describes Route 53 as resolving DNS queries and gives this kind of example.

18. Edge Location vs Region

This is easy to confuse.

Region

Used to host AWS infrastructure and services in a geographical area.

Edge Location

Used by AWS services such as CloudFront to bring certain functionality closer to users.

Think:

Region
   ↓
Main AWS infrastructure

Edge Location
   ↓
Closer to users

19. AWS Shield

The notes also mention AWS Shield.

AWS Shield provides protection against DDoS attacks.

The source describes it as providing protection against network flooding at the edge.

A simplified picture:

Attacker
   |
   | Huge traffic
   ↓
Edge
   |
   | Protection
   ↓
Application

The basic idea is to help protect applications from certain DDoS attacks.

20. How Route 53 Can Help Direct Users

Imagine a user in Kolkata opens:

amazon.com

The DNS system can determine an appropriate endpoint based on the configured routing behavior.

The source illustrates a user reaching a nearby Route 53 edge and receiving an endpoint such as CloudFront, an Application Load Balancer, or API Gateway depending on the routing configuration.

Simplified:

User
 |
 ↓
Route 53
 |
 ↓
Choose appropriate endpoint
 |
 ├── CloudFront
 ├── Load Balancer
 └── API Gateway

21. Now Let’s Talk About Disaster Recovery

So far we discussed AWS infrastructure.

Now imagine something goes seriously wrong.

For example:

Primary Region
      ❌
   Disaster

What should happen?

We need a Disaster Recovery (DR) strategy.

The goal is to reduce downtime and continue serving users as much as possible.

The source describes AWS infrastructure as designed with the assumption that failures can happen and introduces RTO/RPO as key disaster-recovery metrics.

22. What Is RTO?

RTO means:

Recovery Time Objective

Simple meaning:

How much downtime can we tolerate before the system needs to recover?

For example:

RTO = 1 hour

means the recovery target is within about one hour.

Another example:

RTO = 10 minutes

means the recovery target is much faster.

The source defines RTO around how long the system can be down before recovery.

23. What Is RPO?

RPO means:

Recovery Point Objective

Simple way to think about it:

How much recent data can we afford to lose?

For example:

RPO = 1 hour

means the recovery design may tolerate losing up to roughly an hour of recent data, depending on the implementation.

If:

RPO = few seconds

the system needs much more frequent/continuous data replication.

The source notes that smaller RPO requires more frequent or continuous replication.

24. Easy Way to Remember RTO and RPO

Remember these two questions:

RTO

How fast can I come back?

RPO

How much data can I afford to lose?

So:

RTO → Time to recover

RPO → Amount of data loss we can tolerate

25. Disaster Recovery Strategy 1: Backup and Restore

This is one of the simpler and cheaper approaches.

Imagine:

Region 1
Primary
   |
   | Daily backup
   ↓
Region 2
DR

The DR Region doesn’t normally run the application.

The source describes the DR Region as having backup files while application and database infrastructure are not running.

What Happens During Disaster?

Suppose Region 1 fails.

We need to:

  1. Create/start application servers.
  2. Restore the database from the latest backup.
  3. Make the DR database primary.
  4. Redirect DNS to Region 2.

The source lists these recovery steps.

This can result in:

RTO → Hours
RPO → Hours

depending on the backup frequency and recovery process.

26. Disaster Recovery Strategy 2: Pilot Light

Now let’s make the DR environment a little more prepared.

In Pilot Light:

Primary Region
Application → Running
Database → Running

DR Region
Application → OFF
Database → Running

The source describes the DR database as continuously replicated while application servers remain off.

During a disaster:

Start application servers
        ↓
Promote DR database
        ↓
Change DNS
        ↓
Traffic goes to DR

The source gives an example target of:

RTO = 10–30 minutes
RPO = seconds to minutes

depending on replication lag.

27. Disaster Recovery Strategy 3: Active-Passive / Warm Standby

Now let’s make the DR Region even more ready.

In Active-Passive, also called Warm Standby, the DR environment is already running at a smaller scale.

Think:

Primary Region
     |
     | 100% traffic
     ↓
Application

DR Region
     |
     | Small application setup
     ↓
Ready

The source describes the DR application servers as running at a smaller scale and the database as continuously replicated.

Some traffic may even be sent to the DR Region for testing or other purposes.

The notes also mention that the DR database may operate as a read replica, while writes can be directed to the primary Region.

28. What Happens During Disaster?

Suppose the primary Region fails.

We can:

1. Scale application servers
       ↓
2. Promote DR database
       ↓
3. Change DNS
       ↓
4. Serve users from DR

The source gives an example of scaling application servers from 2 to 10 during recovery.

The expected RTO is in minutes, while RPO can be seconds to minutes depending on replication lag.

29. Disaster Recovery Strategy 4: Active-Active

Now comes the most interesting setup.

In Active-Active, both Regions are serving real users.

          Users
         /     \
        ↓       ↓
   Region 1   Region 2
      50%        50%

There is no traditional:

Primary
   ↓
DR

concept in the same way.

Both Regions are active.

The source describes both Regions as serving real users and one Region absorbing traffic if the other fails.

30. Active-Active Example

Imagine:

Mumbai Region
     ↑
     |
   Users
     |
     ↓
Singapore Region

Both Regions are working.

If Mumbai has a failure:

Mumbai ❌

Singapore
   ↓
Handles traffic

The goal is to avoid a traditional recovery wait.

However, Active-Active introduces another difficult problem:

Data conflicts.

31. The Data Conflict Problem

Imagine the available balance is:

₹100

Now two Regions receive updates at almost the same time.

Region 1

Deposit = ₹10

Region 2

Deposit = ₹20

Now both Regions synchronize their data.

What should the final balance be?

Ideally:

₹100 + ₹10 + ₹20
= ₹130

But depending on how replication and conflict resolution are implemented, concurrent updates can create conflicts.

The source specifically uses this balance example to explain the challenge of conflicts in Active-Active systems.

32. Last Write Wins

One possible conflict-resolution approach is:

Last Write Wins

For example:

10:00 → +₹10
10:01 → +₹20

The latest write wins.

So the later update determines the stored value under that conflict-resolution rule.

The source uses DynamoDB as an example of a system that can use a last-write-wins approach and explains that this does not fit every business scenario.

33. Why Last Write Wins Is Not Always Good

Consider money.

Suppose:

Balance = ₹100

Two deposits happen:

Region 1 → +₹10

Region 2 → +₹20

If one update simply overwrites the other, we might incorrectly end up with:

₹120

instead of:

₹130

That’s why conflict resolution is a very important part of distributed system design.

34. GEO Sharding

Another approach mentioned in the source is Geo Sharding.

The basic idea is:

Keep a particular user’s data associated with a particular geographical Region.

For example:

Mumbai users
      ↓
Mumbai Region

Singapore users
      ↓
Singapore Region

Now the same user’s data is less likely to be modified simultaneously in multiple Regions.

The source introduces this idea as a way to reduce conflicts by directing a particular user’s data to a particular location.

35. Complete AWS Global Infrastructure Picture

Now let’s connect everything.

                         WORLD
                           |
          --------------------------------
          |                              |
     Mumbai Region                 Singapore Region
          |                              |
     ------------                   ------------
     |     |    |                   |    |    |
    AZ-1  AZ-2  AZ-3                AZ-1 AZ-2 AZ-3

Then we can have Local Zones:

Mumbai Region
     |
     └── Local Zone
          |
          └── Closer to users

And Edge Locations:

Users
  |
  ↓
Edge Location
  |
  ↓
CloudFront / Route 53
  |
  ↓
AWS Region

36. The Whole Concept in One Example

Imagine you are building a large video application.

Your users are in India.

You could have:

Users
  |
  ↓
CloudFront Edge
  |
  ↓
Mumbai Region
  |
  |--- AZ-1
  |--- AZ-2
  |--- AZ-3

If you need infrastructure closer to a particular city, a Local Zone may be considered depending on the workload.

For disaster recovery:

Mumbai Region
      |
      | Replication
      ↓
Singapore Region

Then you choose a DR strategy depending on your required:

RTO
RPO
Cost
Complexity

37. Easy Comparison Table

Concept Simple Meaning
Region Large geographical AWS area
Availability Zone Isolated infrastructure location inside a Region
Local Zone Selected AWS infrastructure closer to users
Edge Location AWS edge location used by services such as CloudFront
CloudFront CDN for delivering cached content closer to users
Route 53 DNS service
RTO How quickly we need to recover
RPO How much recent data loss we can tolerate
Backup & Restore Restore infrastructure/data after disaster
Pilot Light Database ready, application mostly off
Warm Standby Smaller application environment already running
Active-Active Multiple Regions serve users at the same time

38. Backup & Restore vs Pilot Light vs Warm Standby vs Active-Active

Think about four levels:

                   More Prepared
                        ↑
                        |
Backup & Restore
        ↓
Pilot Light
        ↓
Warm Standby
        ↓
Active-Active
                        |
                        ↓
                  More Infrastructure

Backup & Restore

DR = Mostly empty

Cheaper, but recovery takes longer.

Pilot Light

DR Database = Ready
DR App = Off

Faster than backup/restore.

Warm Standby

DR Database = Ready
DR App = Running

Faster recovery.

Active-Active

Region 1 = Active
Region 2 = Active

Both serve users.

But it introduces additional distributed-data challenges such as conflict resolution.

39. Final Cheat Sheet

If you are preparing for a Java/AWS interview, remember these lines:

Region

A geographical area containing multiple Availability Zones.

Availability Zone

An isolated infrastructure location inside a Region.

Local Zone

Brings selected AWS infrastructure closer to users.

Edge Location

AWS-managed edge location used by services such as CloudFront.

RTO

How quickly the system needs to recover.

RPO

How much recent data loss the system can tolerate.

Backup & Restore

Restore everything after the disaster.

Pilot Light

Keep the database ready, application mostly off.

Warm Standby

Keep a smaller DR application environment running.

Active-Active

Multiple Regions actively serve users.

Active-Active Problem

Data conflicts can happen when the same data is changed in multiple Regions.

Conclusion

AWS Global Infrastructure becomes much easier when you stop trying to memorize definitions and instead imagine a real-world city.

Region
  ↓
City

Availability Zone
  ↓
Building / group of buildings

Local Zone
  ↓
Infrastructure closer to users

Edge Location
  ↓
Closer edge point for services like CloudFront

And for disaster recovery:

Backup & Restore
      ↓
Pilot Light
      ↓
Warm Standby
      ↓
Active-Active

As you move toward more aggressive recovery requirements, the architecture generally needs more infrastructure, replication and operational complexity. The source material illustrates this progression through the four DR strategies and their example RTO/RPO characteristics.

The one thing to remember:

Region protects you from geographical problems, AZ protects you from infrastructure-location failures, Edge Locations help bring content/services closer to users, and Disaster Recovery strategies help you continue operating when something goes wrong.

SEO Title

AWS Global Infrastructure Explained: Region, AZ, Local Zone, Edge Location & Disaster Recovery

Meta Description

Learn AWS Global Infrastructure in simple terms. Understand Regions, Availability Zones, Local Zones, Edge Locations, RTO, RPO and AWS Disaster Recovery strategies.

URL Slug

/aws-global-infrastructure-region-az-local-zone-disaster-recovery/

Tags

AWS · AWS Global Infrastructure · AWS Region · Availability Zone · Local Zone · Edge Location · CloudFront · Route 53 · Disaster Recovery · RTO · RPO · Cloud Computing

Tags:

Leave a Reply