Global Infrastructure #

When we build and deploy applications in the cloud, we’re not sending our code to some abstract, formless entity in the sky. Behind all the API convenience, web consoles, and serverless automation we enjoy lies massive physical infrastructure spread across the globe. This infrastructure consists of giant data center buildings, intercontinental undersea fiber optic cable networks, backup power generation systems, and millions of physical server racks. Our decisions about where that physical infrastructure runs directly impact user access speed (latency), data sovereignty law compliance, monthly operational budgets (cost), and our application’s resilience in the face of natural disasters. Understanding a cloud provider’s global infrastructure architecture is therefore one of the most important foundations for every cloud engineer and systems architect.

Global Infrastructure Hierarchy #

To manage such massive scale in an orderly way while minimizing the impact of failures, major cloud providers (like AWS, Google Cloud, or Microsoft Azure) organize their physical infrastructure into several structured hierarchical layers.

flowchart TD
    Geo["Geographic Area (Continent/Large Region)"] --> Region["Region (Group of Independent AZs)"]
    Region --> AZ["Availability Zone / AZ (Physical Failure Isolation)"]
    AZ --> DC["Data Center (One or More Physical Buildings)"]
    DC --> Racks["Physical Racks & Servers (Compute Infrastructure)"]

Let’s break down each hierarchy layer from the largest unit to the smallest:

1. Geographic Area: This is the top-level division, usually covering continents or large world regions, such as Asia Pacific, North America, Europe, or the Middle East. Its purpose is to help organizations group deployment locations at a macro level.
2. Region: A specific geographic area within a country that contains several interconnected Availability Zones (AZs). Examples of regions are Singapore (ap-southeast-1), Jakarta (ap-southeast-3), and Northern Virginia (us-east-1). Each region operates independently and is fully isolated from other regions.
3. Availability Zone (AZ): A failure isolation unit within a single region. One AZ consists of one or more standalone physical data centers with independent power supplies, cooling, and internet connections, yet connected to other AZs in the same region through a private, ultra-low-latency fiber optic network.
4. Data Center: The physical building housing thousands of computer servers. This is where computing hardware physically runs under extremely tight security.
5. Physical Rack & Server: The metal racks holding physical servers, storage devices (storage arrays), network switches, and connectivity cables. At this level, the hypervisor virtualization layer divides physical hardware resources into the Virtual Machines (VMs) we rent in the cloud.

Region: A Group of Independent Data Centers #

A region is the hub where we deploy applications and store data in the cloud. The key characteristic of a region is full independence. That means a natural disaster failure (like a storm, major earthquake, or a country-wide blackout) that cripples one region won’t affect other regions’ operations. Our data will never automatically move or replicate to another region unless we explicitly configure it.

Key Criteria for Choosing a Region #

Choosing the region where your application runs isn’t a random decision or based on which region name sounds popular. There are four crucial criteria you must evaluate deeply before picking a region:

1. Latency (Geographic Proximity to Users) #

The laws of physics on the speed of light through fiber optic cables limit how fast data can travel from server to end-user device. Every 1,000 kilometers of physical distance adds roughly 10-15 milliseconds (ms) of extra latency (round-trip time).

• If 95% of your application’s target users are in Indonesia, deploying in the Jakarta Region (ap-southeast-3) gives very low latency (< 10 ms).
• Conversely, if you deploy that application in the Northern Virginia Region (us-east-1), users in Indonesia will experience a ping of around 200-250 ms for every request, significantly hurting user experience.

2. Data Sovereignty and Legal Compliance #

Many countries have strict regulations about where their citizens’ sensitive data may be stored.

• In Indonesia, Government Regulation (PP) No. 71 of 2019 requires electronic system operators serving the public to manage, process, and store data within Indonesian territory.
• In the European Union, GDPR (General Data Protection Regulation) prohibits transferring EU citizens’ personal data outside the region without equivalent legal protection.
• Failing to comply with data sovereignty regulations can result in astronomical fines or revocation of your business operating license.

3. Service Cost (Cost Variations) #

Renting the exact same type of Virtual Machine or database can have significantly different prices between regions. This price difference comes from variations in the cloud provider’s local operating costs, such as building land rental prices, local industrial electricity rates, the country’s tax system, and hardware scarcity levels in that region.

• Generally, long-established, very large flagship regions like us-east-1 (Virginia) have the cheapest rates in the world.
• New regions or regions in developing countries (like Jakarta or Sao Paulo) often have rental rates 15% to 35% more expensive for the same service type.

4. Service Availability #

Cloud providers don’t release new services simultaneously worldwide. Cutting-edge features (like the latest GPU types for AI, new serverless database models, or machine learning integrations) usually launch first in flagship regions. If your application architecture depends heavily on a specific feature, you’re forced to choose a region where that service is already Generally Available (GA).

Availability Zone (AZ): The Key to Failure Isolation #

If regions are designed for large-scale geographic failure isolation, Availability Zones (AZs) are designed to isolate everyday infrastructure failures within a local area without sacrificing application performance.

flowchart TD
    subgraph Region["Region (e.g. ap-southeast-3 Jakarta)"]
        direction LR
        subgraph AZ_A["Availability Zone A (AZ-a)"]
            DC1["Data Center 1"]
            DC2["Data Center 2"]
        end
        subgraph AZ_B["Availability Zone B (AZ-b)"]
            DC3["Data Center 3"]
        end
        subgraph AZ_C["Availability Zone C (AZ-c)"]
            DC4["Data Center 4"]
        end
        AZ_A <-->|"High-Speed Fiber Optic Network<br>(Latency < 2ms)"| AZ_B
        AZ_B <-->|"High-Speed Fiber Optic Network<br>(Latency < 2ms)"| AZ_C
        AZ_C <-->|"High-Speed Fiber Optic Network<br>(Latency < 2ms)"| AZ_A
    end

Every AZ within a region is connected by a very fast private fiber optic network. Inter-AZ network latency is usually kept under 2 milliseconds. This extremely low latency is critical because it allows us to do synchronous data replication (waiting for confirmation that a write to a server in another AZ completed before responding success to the user) without making the application feel slow.

AZ Physical Isolation Characteristics: #

• Safe Physical Distance: AZs within a region are geographically separated by a fairly large distance (usually several to tens of kilometers apart). The goal is that if a local disaster happens (like a flash flood in one district, a fire at a main electrical substation, or a road construction accident cutting public internet cables), the incident only affects one AZ and not the others.
• Independent Infrastructure: Each AZ has its own backup electrical substation with industrial UPS battery stacks and diesel fuel reserves for its generators, capable of supplying power for days without the main grid. Water cooling systems (chillers) and ISP internet connections (backbone carriers) also enter the building through physically different routes in each AZ.

Multi-AZ Deployment: The Production Minimum Standard #

Running an entire application and database in a single Availability Zone (Single-AZ) is a fatally careless architectural choice for a production environment. If that AZ suffers a hardware failure, your application goes completely offline.

That’s why modern architectures always adopt the Multi-AZ Deployment pattern. In this scenario, we distribute application instances evenly across at least two or three AZs, and place a Load Balancer at the front of the system to distribute traffic fairly.

Automatic Failover Handling in Multi-AZ #

If one AZ dies completely, the load balancer constantly monitoring server health (health checks) detects the loss of responses from servers in the problem AZ. The load balancer immediately cuts traffic to that AZ and redirects the entire request load to healthy servers in other AZs.

This redirect happens automatically within seconds, with no manual intervention needed from the Operations team (SRE/Sysadmin). Your end users won’t even notice a physical disaster is happening in the data center.

sequenceDiagram
    participant Client as User
    participant LB as Load Balancer (Multi-AZ)
    participant AZ_A as AZ-A Instances (Down)
    participant AZ_B as AZ-B Instances (Active)
    
    Client->>LB: Send HTTP Request
    LB-->>AZ_A: Send request (Experiencing Physical Failure)
    LB->>LB: Detect Failed Health Check in AZ-A
    LB->>LB: Mark AZ-A as Unhealthy
    LB-->>AZ_B: Reroute request to AZ-B
    AZ_B-->>LB: Successful response (HTTP 200)
    LB-->>Client: Successful response to User

At the database level, Multi-AZ works by placing the primary database (Primary) in AZ-1 and a backup database (Standby) in AZ-2. Data replication runs synchronously from Primary to Standby. If AZ-1 is destroyed, the cloud provider automatically promotes the Standby database in AZ-2 to become the new Primary, and redirects application connections (endpoint string) to the new database in under a minute.

Edge Locations and CDN: Reaching End Users #

Beyond Regions and Availability Zones, there’s another very important global infrastructure component for speeding up our application content performance: the Edge Location (also known as Points of Presence / PoP).

Region vs Edge Location Differences #

It’s very important not to confuse Edge Locations with Regions or AZs. They have completely opposite functions and architectures:

How CDN Leverages Edge Locations? #

When you use a CDN (Content Delivery Network) service, Edge Locations act as the front line closest to users’ physical locations.

If your application’s origin server is in the Singapore Region and a user in Jakarta accesses an application image asset, the caching flow at the Edge Location works like this:

flowchart TD
    User["User in Jakarta"] -->|"Request image.jpg file"| Edge["Jakarta Edge Location"]
    Edge -->|"Check Cache"| CacheCheck{"In Cache?"}
    CacheCheck -- "Yes (Cache Hit)" --> DeliverHit["Send Image to User (< 5ms)"]
    CacheCheck -- "No (Cache Miss)" --> FetchOrigin["Fetch Image from Origin Server (Singapore Region, ~30ms)"]
    FetchOrigin --> SaveCache["Save Image in Edge Cache"]
    SaveCache --> DeliverMiss["Send Image to User"]

Besides CDN, Edge Locations also serve critical security features like:

• DDoS Mitigation: Absorbing fake request flood attacks at the closest level to the attacker’s source, before that traffic reaches and cripples your origin server in the main region.
• Anycast DNS: Providing super-fast domain name resolution because the nearest DNS server answers user queries.
• Edge Computing: Running lightweight compute functions (like HTTP header manipulation or redirects) directly at the Edge Location before requests are sent to the main server.

Multi-Region Deployment: Extreme-Level Resilience #

Although Multi-AZ provides excellent protection against most everyday infrastructure failures, it still has limitations. If a continent-scale catastrophe happens (like war, national undersea fiber optic cable cuts, or a global software misconfiguration at the cloud provider level that cripples an entire region), then the Multi-AZ architecture within that single region will collapse too.

For systems with very high criticality (like national banking systems, global ride-hailing apps, or giant e-commerce portals), we need Multi-Region Deployment architecture.

Multi-Region Architecture Patterns #

There are two main patterns for designing Multi-Region systems:

1. Active-Passive (Disaster Recovery): One primary region (Active) handles 100% of daily operational traffic. Data is asynchronously replicated to a backup region (Passive). If the Active region dies completely, the global DNS system redirects to the Passive region. Depending on the architecture, there are several variants:
   • Backup & Restore: Cheap, but slow RTO (Recovery Time Objective) because you have to restore the database from backup.
   • Pilot Light: The backup database is always alive and synced, but application servers are off or minimal. Takes a few minutes to scale up when disaster strikes.
   • Warm Standby: Application servers in the Passive region are already running at minimum capacity, ready to accept traffic redirects with very fast RTO.
2. Active-Active: Both regions actively serve user traffic simultaneously. Users in Asia are routed to the Singapore Region, while users in America are routed to the Virginia Region by latency-based routing. Data is synchronized bidirectionally (bi-directional replication).

Multi-Region Technical Complexity #

Although it offers the highest availability level, Multi-Region architecture brings enormous technical complexity and prohibitively expensive costs:

• Asynchronous Replication & Data Consistency (Eventual Consistency): Thousands of kilometers between regions make synchronous data replication impossible because network latency is too high (for example, writing data in Jakarta and waiting for written confirmation from Virginia before replying to the user would add hundreds of milliseconds of latency). We’re forced to use asynchronous replication, which means there’s a risk of losing the most recent data (data loss) if the primary region is suddenly destroyed before replication completes.
• Data Transfer Costs (Data Egress Costs): Cloud providers charge significant rates for data traffic leaving one region to another. Busy cross-region database sync costs can exceed the VM rental cost itself.
• Split-Brain Syndrome: If the communication network connecting regions is cut (yet both regions are physically alive), both regions may assume their partner has died. Both will try to write new data independently without synchronization, resulting in extremely difficult-to-fix data conflicts (data corruption).

Summary #

• A Region is an independent geographic area fully isolated from other regions to prevent large-scale cascading failures. Region choice determines user latency, operational costs, data regulation compliance, and feature availability.
• An Availability Zone (AZ) is a physical failure isolation unit within a single region. It consists of standalone data centers with separate power, cooling, and internet connectivity routes to handle local incidents without downtime.
• Multi-AZ deployment is the minimum standard for production applications to guarantee high availability through automated failover and traffic load balancing.
• An Edge Location is not a place to run general compute, but a distributed point of presence acting as a CDN to cache static content, accelerate DNS, and absorb DDoS attacks at the perimeter closest to users.
• Multi-Region deployment targets high-level disaster recovery and low global latency, but requires very complex data consistency handling (eventual consistency) and expensive data transfer costs.

← Previous: Elasticity vs Scalability   Next: HA & Fault Tolerance →