AWS Global Infrastructure

AWS is a hierarchy of physical locations, and nearly every architectural decision about availability, latency, compliance and cost is really a decision about where in that hierarchy something sits.

The layers

Regions

A Region is the boundary that matters most. Data stays in the Region you put it in unless you explicitly replicate it, which is what makes Region choice the answer to most data residency questions.

Regions are isolated from each other by design. A failure in us-east-1 does not affect eu-west-1, and resources do not implicitly span Regions: a VPC, an S3 bucket, an EBS volume all belong to exactly one.

aws ec2 describe-regions --query 'Regions[].RegionName' --output text

Some Regions are opt-in and must be enabled before use, which catches people whose API calls fail with an authorisation error that does not mention the Region at all.

Choosing one

Four considerations, roughly in order:

Latency. Closest to your users. This dominates for anything interactive.

Compliance. Data residency rules may simply decide it for you.

Price. Regions differ, sometimes by 10 to 20% for identical resources. us-east-1 is usually among the cheapest; newer and smaller Regions are often the most expensive.

Service availability. New services launch in us-east-1 first and reach smaller Regions months or years later. Check before designing around something recent.

# Is this service available here?
aws ec2 describe-instance-type-offerings \
  --location-type availability-zone --region eu-west-2 \
  --filters Name=instance-type,Values=m7g.large

The us-east-1 exception

A handful of things are anchored to us-east-1 regardless of where you operate:

• ACM certificates for CloudFront must be issued there.
• Some IAM and billing APIs are served from there.
• S3 bucket creation there must omit LocationConstraint, unlike every other Region.

That first one catches almost everyone building a CDN in Europe or Asia.

Availability Zones

An Availability Zone is one or more data centres with independent power, cooling and physical security, connected to other zones in the Region by high-bandwidth, low-latency private links, typically single-digit milliseconds apart.

Deploying across at least two zones is the baseline for production. A subnet belongs to exactly one zone, so multi-AZ means one subnet per zone per tier, with a load balancer or a managed service spreading across them.

Zone names are per account

eu-west-1a in your account is not necessarily the same physical zone as eu-west-1a in someone else's. AWS randomises the mapping so that customers do not all crowd into whichever zone is alphabetically first.

For genuine physical identity. Coordinating with a partner account, or placing resources deterministically. Use the zone ID, which is consistent across accounts:

aws ec2 describe-availability-zones --region eu-west-1 \
  --query 'AvailabilityZones[].{Name:ZoneName,ID:ZoneId}' --output table

|  Name        |  ID        |
|  eu-west-1a  |  euw1-az1  |
|  eu-west-1b  |  euw1-az3  |
|  eu-west-1c  |  euw1-az2  |

The practical consequence for infrastructure code is to query zones rather than hardcoding names.

Cross-AZ traffic costs money

This is the part that surprises people on the bill. Data transferred between Availability Zones is charged in both directions.

A chatty microservice architecture spread evenly across three zones can spend meaningfully on traffic that never leaves the Region. It is the cost of the availability, and usually worth paying, but worth knowing about rather than discovering.

Mitigations where the volume justifies them: topology-aware routing in Kubernetes, keeping tightly-coupled services zone-local, and caching to reduce chattiness.

Note that traffic within a single zone is free, and traffic to most AWS services through a VPC endpoint avoids both cross-AZ and NAT charges.

Local Zones and Wavelength

Local Zones place compute and storage in a metro area far from the parent Region, for workloads needing single-digit millisecond latency to a specific city. They offer a subset of services and are managed as an extension of the parent Region.

Wavelength Zones do the same inside telecom providers' 5G networks.

Both are niche. Most workloads are better served by choosing a nearby Region and using CloudFront for static content.

Edge locations

Hundreds of points of presence serving CloudFront, Route 53, AWS Global Accelerator and AWS WAF. They cache content and terminate connections close to users, which reduces latency and, importantly, reduces data transfer costs, since egress from CloudFront is cheaper than egress from a Region.

Serving downloads and static assets through CloudFront rather than directly from S3 is usually both faster and cheaper.

Designing for failure

Multi-AZ is the right default and multi-Region rarely is. Going multi-Region means replicating data with the consistency trade-offs that implies, duplicating infrastructure, handling DNS failover, and testing something that is difficult to test. For a failure mode that is genuinely rare. Most organisations that believe they need it would be better served by making their multi-AZ deployment actually reliable.

Quick reference

---

Key takeaways

• Region is the data residency and isolation boundary. Resources belong to exactly one.
• Choose on latency, compliance, price and service availability: in roughly that order.
• ACM certificates for CloudFront must be in us-east-1, whatever Region you otherwise use.
• Zone names are randomised per account: use zone IDs when physical identity matters.
• Cross-AZ traffic is charged both ways. Within a zone it is free.
• Multi-AZ is the production baseline; multi-Region rarely justifies its cost.
• CloudFront egress is cheaper than Region egress, so serving assets through it saves money as well as time.

---

Check your understanding

---

Frequently Asked Questions

What is the difference between a Region and an Availability Zone?

A Region is a geographic area such as eu-west-1, and it is the boundary for data residency. Data stays there unless you replicate it deliberately. An Availability Zone is one or more discrete data centres within a Region, with independent power, cooling and networking, connected to the other zones by low-latency private links. Deploying across multiple zones protects against a single data centre failure; deploying across Regions protects against a whole Region failing and is far more work.

Which AWS Region should I use?

Start with the one closest to your users for latency, unless data residency requirements decide it for you. Then check two things people often miss: pricing varies between Regions by as much as 10 to 20% for identical resources, and new services launch in us-east-1 first and reach smaller Regions much later. If you are building for a global audience, a nearby Region plus CloudFront usually beats trying to run in several.

Why does eu-west-1a mean something different in another account?

AWS randomises the mapping between zone names and physical zones for each account, so that everyone does not concentrate in whichever letter sorts first. The zone ID, such as euw1-az1, is consistent across all accounts and is what you compare when physical location genuinely matters. For example when two accounts need resources in the same facility to avoid cross-AZ transfer charges. describe-availability-zones returns both.

Why am I charged for data transfer inside one Region?

Traffic between Availability Zones is charged per gigabyte in both directions, because zones are physically separate facilities. An architecture with many small services distributed evenly across three zones can generate substantial internal transfer. Traffic within a single zone is free, as is traffic to most AWS services through a VPC endpoint. If cross-AZ charges are significant, topology-aware routing and keeping tightly-coupled services zone-local both help.

Do I need a multi-Region architecture?

Almost certainly not. Multi-AZ protects against the failure mode that actually occurs, a data centre problem, and is straightforward. Multi-Region protects against an entire Region failing, which is rare, and costs you data replication with its consistency trade-offs, duplicated infrastructure, DNS failover, and a disaster recovery process that is genuinely hard to test. Most teams considering it would get more reliability from making their multi-AZ deployment properly resilient first.

Why must my CloudFront certificate be in us-east-1?

CloudFront is a global service whose configuration is managed from us-east-1, so ACM certificates it uses must be requested there regardless of where your origin and the rest of your infrastructure live. This catches nearly everyone building a distribution in Europe or Asia. In Terraform it means an aliased provider block pinned to us-east-1 purely for the certificate resource, while everything else uses your normal Region.