AWS global infrastructure

AWS global infrastructure organizes cloud resources into geographic deployment areas and distinct failure boundaries. Its main building blocks are Regions, Availability Zones, and edge locations. These are not interchangeable: Regions establish geographic placement, Availability Zones support isolation within a Region, and edge locations bring selected delivery and networking functions closer to users.

A Region is a separate geographic area containing multiple Availability Zones. Engineers select Regions based on user proximity, service availability, pricing, regulatory requirements, and recovery objectives. Most workload resources are regional or zonal rather than automatically worldwide. Launching an application in one Region does not create a working copy in another Region, and service capabilities can differ between Regions.

An Availability Zone consists of one or more discrete data centers with redundant power, networking, and connectivity. Availability Zones within a Region are physically separated and connected through low-latency networking. This arrangement supports architectures that remain available when one zone becomes unavailable. However, placing resources in multiple zones is only useful when application routing, capacity, storage, and dependencies can also withstand a zone failure.

For example, a regional web application might use a load balancer with application instances in two Availability Zones and a database configured for supported Multi-AZ operation. If one zone fails, the surviving application tier must have enough capacity to handle traffic, and database failover must fit the application's recovery requirements. Two instances in different zones do not provide complete resilience if both depend on a single zonal database or outbound networking component.

Edge locations support services such as content delivery and traffic acceleration. A content delivery network can cache eligible content near users, reducing latency and requests to the origin. An edge location is not an Availability Zone and does not provide the same general-purpose deployment environment. Local Zones are another distinct extension: they place selected resources closer to particular population or industry centers while remaining associated with a parent Region.

Multi-Region architecture addresses broader disruptions and can improve proximity to geographically distributed users. A disaster recovery design might replicate data to a second Region and maintain infrastructure definitions that can recreate the application there. Recovery depends on replication lag, available capacity, routing changes, credentials, and operational readiness. Active-active deployment can reduce reliance on a single Region, but it introduces harder problems involving concurrent writes, consistency, conflict resolution, and coordinated releases.

The trade-offs are practical rather than purely geographic. Cross-zone and cross-Region communication can introduce transfer charges, while longer network distances increase latency. Additional deployment locations increase operational complexity and can require duplicate capacity. Teams should define recovery time and recovery point objectives before choosing between a single-Region Multi-AZ design, standby recovery, and active-active deployment.

Common misconceptions include assuming that every AWS service is regional, that all storage automatically replicates across Regions, or that using a global endpoint makes an application resilient to regional failures. Some services have global scope or global entry points, but their dependencies and recovery behavior still require inspection. For data residency, selecting a Region is only part of the design: backups, replicas, logs, edge caching, and service-specific data handling must also match the applicable requirements.