Global Infrastructure

Your application serves customers in New York, London, and Tokyo. A user in Tokyo experiences 300ms latency because their requests travel to a US-East data center and back. Meanwhile, your company learned that a new regulation requires all Japanese customer data to remain physically within Japan. You need infrastructure close to your users AND data residency compliance. This is exactly why cloud providers organize their global infrastructure into regions and availability zones.

A Region is a geographical area where cloud resources are deployed. Each region consists of multiple isolated locations called Availability Zones. AWS currently operates 33 geographic regions with 105 availability zones. When you launch an EC2 instance, you choose a region. That instance runs in a specific data center within that region. Regions are independent: an outage in US-East-1 does not affect resources in EU-West-1. This isolation is intentional.

Region selection is driven by three factors. Latency matters because physical distance directly impacts round-trip time. A server in Frankfurt serves European users with 20-50ms latency; serving those same users from Virginia adds 80-120ms. Compliance requires data to remain within specific geographic boundaries. GDPR mandates EU data stays in the EU. China requires data to remain within mainland China. Service availability varies by region. Not all AWS services are available in every region.

An Availability Zone (AZ) is an isolated location within a region, designed to be physically separate from other AZs. Each AZ has independent power, networking, and cooling. AZs within a region are connected by low-latency, high-bandwidth private fiber, typically with single-digit millisecond latency. This connection enables synchronous replication between AZs which is critical for building highly available architectures.

AZ design follows the fault isolation principle. An AZ is not a single data center. It is one or more data centers with independent infrastructure. If one AZ loses power, the others in the same region continue operating. If one AZ has a networking failure, traffic routes to healthy AZs. This isolation means you can distribute your application across multiple AZs and survive the failure of any single AZ without downtime.

When you deploy an application across multiple AZs, you create a highly available architecture. For example, running web servers in two AZs behind a load balancer means that if one AZ fails, the load balancer automatically routes traffic to the healthy AZ. Your users experience a brief disruption (seconds) rather than a prolonged outage.

Your application in US-East-1 serves users globally, but users in Australia experience 250ms load times. You cannot move your entire application to Australia; your team, databases, and integrations are all in the US. You need a way to serve content closer to users without relocating infrastructure. This is the problem edge locations solve.

Edge locations are small data centers positioned at the network edge, close to end users. They are smaller than regions or AZs and designed for a single purpose: caching and serving content as close to users as possible. AWS CloudFront operates over 600 edge locations globally. When a user in Sydney requests content from your application, CloudFront serves the cached copy from the nearest edge location in Sydney instead of fetching it from US-East-1. The result: latency drops from 250ms to under 20ms.

Edge locations power Content Delivery Networks (CDNs). CloudFront, Azure CDN, and Google Cloud CDN cache static content (images, CSS, JavaScript, video) at edge locations worldwide. When a user requests content, the CDN serves it from the nearest edge. If the content is not cached, the CDN fetches it from the origin server, caches it at the edge, and serves it to the user.

CDNs extend beyond simple caching. They provide DDoS protection by absorbing traffic spikes at the edge before they reach your origin. They handle SSL termination at the edge, reducing load on your servers. They enable live video streaming with minimal latency. They provide security features like bot detection and WAF integration at the edge.

Local Zones extend a region closer to large population centers. An AWS Local Zone is an extension of a region that places compute, storage, and other services at the edge in a specific metropolitan area. For example, the US-West-2 region (Oregon) has Local Zones in Los Angeles, San Francisco, and Seattle. Local Zones provide single-digit millisecond latency to users in those cities.

Wavelength Zones push cloud infrastructure into 5G carrier networks. AWS Wavelength embeds EC2 instances directly into telecommunications carrier data centers, enabling ultra-low latency applications for 5G devices. If you are building an autonomous vehicle application or a real-time industrial IoT platform that requires sub-10ms latency to 5G devices, Wavelength Zones bring cloud compute to the cellular network edge.

Geographic distribution is not just a performance optimization; it fundamentally determines your architecture resilience, compliance posture, and user experience.

Latency and user experience are directly tied to physical distance. Light travels through fiber optic cable at roughly two-thirds the speed of light in a vacuum. A request from London to New York (5,500 km) takes approximately 70ms round-trip at the speed of light, not counting routing and processing overhead. Real-world latency is typically 120-150ms for this route. Users perceive delays over 100ms as sluggish. By deploying in eu-west-1 (Ireland), European users get 20-40ms latency instead of 120-150ms.

Fault tolerance through geographic redundancy means distributing critical systems across multiple regions. A single-region deployment survives AZ failures within that region but cannot survive a regional outage. While rare, regional outages have occurred (US-East-1 in 2011, S3 in 2017). A multi-region architecture deploys primary and standby systems in separate regions. If one region goes down, DNS failover routes traffic to the healthy region.

Data residency and sovereignty regulations require specific data to remain within defined geographic boundaries. GDPR mandates that EU citizen personal data must be processed and stored within the EU. China cybersecurity law requires certain data to remain within mainland China. Russia requires citizen data to be stored on Russian servers. These regulations force architectural decisions: you must deploy databases and processing in the required region, even if performance would be better elsewhere.

Cost implications of geographic distribution are real. Running infrastructure in multiple regions multiplies your compute, storage, and data transfer costs. Cross-region data transfer is expensive; AWS charges $0.02/GB for data transfer between US regions and $0.12/GB for intercontinental transfer. For petabyte-scale data, these costs become significant. The architectural decision is always a tradeoff: how much availability and performance do you need versus how much are you willing to pay?