Regions and Availability

Goal: understand the geography every AWS design sits on. By the end you should know which boundary is the failure domain and which is the isolation domain, why your us-east-1a isn't the same place as someone else's, and what multi-region actually costs before you promise it to anyone.

---

1. Regions

The analogy: a region is a city. AWS operates in many of them, and by default what happens in one city stays there.

The technical version: a region is a named, geographically separate cluster of data centres — us-east-1 (N. Virginia), eu-west-1 (Ireland), ap-southeast-2 (Sydney). Each has its own service endpoints, its own resource namespace, and its own quotas.

Regions are isolated from each other by design. This is the property that matters most and the one people accidentally rely on without noticing:

• Resources do not replicate between regions unless you configure replication explicitly.
• Most resource identifiers are region-scoped. An AMI ID, a subnet ID, a security group ID mean nothing in another region.
• A region-wide event does not, by design, cascade into other regions.
• Quotas are per region — a new region starts you at defaults, however much headroom you arranged elsewhere. See ARNs, Tagging & Quotas.

That isolation is deliberate. It's also why "just fail over to another region" is a much bigger project than it sounds: nothing is there unless you put it there.

AWS has no equivalent of Azure's paired regions. There is no automatic partner region, no platform-managed replication between a designated pair, and no guaranteed sequential update ordering. If you want a second region, you choose it, you replicate to it, and you keep it current. Anyone arriving from Azure should unlearn this expectation early.

---

2. Availability Zones

The analogy: if a region is a city, an AZ is a building — or a small campus of them — far enough from its siblings that one flooding doesn't flood the others, close enough that walking between them takes moments.

The technical version: an Availability Zone is one or more discrete data centres within a region, with independent power, cooling, and physical security, connected to sibling AZs by high-bandwidth, low-latency private links.

Property	Detail
Separation	Meaningfully distant — far enough to avoid correlated physical failure
Inter-AZ latency	Low single-digit milliseconds — synchronous replication is practical
Inter-AZ traffic	Charged per GB, in both directions
Count per region	Most regions have three or more; some older ones have two. ⚠️ verify per region
Purpose	The unit of correlated failure you design around

AZ names are shuffled per account

This one catches nearly everyone. us-east-1a in your account and us-east-1a in mine are probably different physical zones. AWS randomises the name-to-zone mapping per account, specifically so that customers don't all pile into "a" and leave the others idle.

The consequence: AZ names are not comparable across accounts. When it genuinely matters — a shared VPC, a cross-account latency-sensitive placement, comparing capacity notes with another team — use the AZ ID, which is consistent:

aws ec2 describe-availability-zones \
  --query 'AvailabilityZones[].[ZoneName,ZoneId,State]' --output table
# eu-west-1a   euw1-az2   available     ← ZoneId is the stable identifier
# eu-west-1b   euw1-az1   available
# eu-west-1c   euw1-az3   available

---

3. Global, regional, zonal

Every AWS resource has a scope, and knowing which is which prevents a specific class of design error.

Scope	Meaning	Examples
Global	One instance for the whole account; no region in the ARN	IAM users and roles, Organizations, Route 53 hosted zones, CloudFront distributions, WAF (global scope)
Regional	Exists in one region; survives the loss of any single AZ	S3 buckets, DynamoDB tables, SQS queues, Lambda functions, VPCs, ELBs, ECR repositories
Zonal	Lives in exactly one AZ; dies with it	EC2 instances, EBS volumes, subnets, RDS instances (a single instance), ElastiCache nodes

The design rule falls straight out of the table: zonal resources need a sibling in another AZ. Regional resources already survive AZ loss. Global resources survive regional loss but are, for that same reason, a shared dependency worth respecting.

Two nuances that cause arguments:

• S3 bucket names are globally unique; buckets are regional. The namespace is global, the data is not. Nobody else can take your bucket name in another region, but your data lives in one region until you replicate it.
• A VPC is regional; its subnets are zonal. This is why a subnet belongs to exactly one AZ and why "spread across AZs" concretely means "use several subnets".

---

4. Failure domain vs. isolation domain

The single most useful framing on this page.

	Availability Zone	Region
Role	Failure domain	Isolation domain
Design question	"What breaks together?"	"What contains a disaster?"
Typical answer	Spread across 3 AZs behind a load balancer	Usually one region; a second only with a real requirement
Cost of using it	Cross-AZ data transfer, modest latency	Duplicated infrastructure, replication, operational complexity
Recovery	Automatic, in seconds, if designed for	Deliberate, minutes to hours, and rehearsed

Multi-AZ is the default and is close to non-negotiable. Three AZs, a load balancer, an Auto Scaling group, no instance-local state. It costs cross-AZ transfer and a little latency, and it converts an AZ event from an outage into a capacity reduction.

Multi-region is a decision, not a default. It is dramatically more expensive — in money, in engineering time, and in the ongoing tax of keeping the second region genuinely current. Do it when there's a real requirement: a regulatory one, a latency one, or an availability target that genuinely cannot be met inside a single region. "For resilience" without a stated RTO and RPO is not a requirement; it's an aspiration that will decay into an untested standby nobody trusts.

---

5. Opt-in regions

Not every region is enabled by default. Older regions are on automatically; newer ones — and several regional additions since roughly 2019 — must be explicitly enabled per account.

This has consequences beyond a checkbox:

• Resources can't be created there until enabled, which surprises expansion projects on day one.
• STS session tokens have historically differed in whether they're valid in opt-in regions, depending on account settings and endpoint used. ⚠️ verify current STS token version behaviour and defaults against AWS docs
• Enabling is an organisation-level action you can control via SCPs — and disabling unused regions is a genuinely useful security control. An attacker with credentials commonly spins up mining capacity in a region nobody watches.

Practical guidance: enable only the regions you use, deny the rest via SCP, and delete default VPCs in regions you don't intend to use. It reduces both the attack surface and the number of places you have to look when auditing.

---

6. Data residency

Your data stays in the region you put it in. AWS does not move customer data between regions on its own. That's the foundation of most compliance answers.

The honest caveats:

• Global services are global. IAM, Organizations, and Route 53 hold configuration outside any single region. That's metadata — user names, role definitions, DNS records — not your workload data, but a compliance reviewer may still ask.
• CloudFront caches at edge locations worldwide, by design. If you serve regulated content through it, that's a deliberate decision requiring geo-restriction or a different design.
• You can move data across regions accidentally. Cross-region replication, a snapshot copy, a backup plan with a cross-region rule, or a global table are all things you configure — but a colleague configuring them is enough.
• Sovereign and isolated partitions exist — AWS GovCloud and the China regions operate as separate partitions with distinct ARNs (aws-us-gov, aws-cn) and separate credentials. AWS has also been building a European Sovereign Cloud. ⚠️ verify current availability, partition names, and scope against AWS docs

To enforce residency, use the aws:RequestedRegion condition key in SCPs — remembering the global-service exemptions covered in Accounts & Organizations.

---

7. Choosing a region

Five factors, roughly in order of how often they decide it:

Factor	Notes
Latency to users	Usually dominant for user-facing workloads. Measure; don't assume the nearest map pin wins
Compliance / residency	Often decides it outright, and isn't negotiable
Service availability	New services launch in a subset of regions first. Check before committing
Price	Prices differ per region, sometimes substantially for the same instance type. ⚠️ verify current pricing
Carbon intensity	Some regions run on markedly cleaner grids; AWS publishes guidance

The us-east-1 question deserves its own paragraph. It's the oldest and largest region, it's often cheapest, and it gets new services first. It's also where the control planes for several global services live — IAM, Organizations, CloudFront, Route 53 — which means a significant us-east-1 event can have effects felt by customers who don't run anything there. Two practical consequences: an ACM certificate used by CloudFront must be issued in us-east-1, and billing and global-service CloudTrail events land there. Choose it deliberately, not by accepting the console default.

---

8. Multi-region, honestly

If you do need a second region, these are the recognised strategies, cheapest and slowest first:

Strategy	What runs in region 2	RTO	RPO	Cost
Backup & restore	Nothing — backups only	Hours	Hours	Lowest
Pilot light	Data replicated; core services off	Tens of minutes	Minutes	Low
Warm standby	A scaled-down but running copy	Minutes	Seconds–minutes	Medium
Active/active	Full capacity, serving traffic	Near zero	Near zero	Highest

The hard part is never the compute — it's the data. Stateless application tiers are easy to duplicate. Getting a consistent, current copy of state in two places forces a genuine choice between consistency and availability, and no amount of AWS service selection makes that choice go away. Services that help — Aurora Global Database, DynamoDB global tables, S3 Cross-Region Replication — each embed a specific answer to that trade-off, and you should know which answer you've bought.

Things that reliably get forgotten when standing up a second region: service quotas (at defaults there), AMIs and container images (region-scoped — must be copied), KMS keys (region-scoped — data must be re-encrypted), ACM certificates, Secrets Manager entries, IAM roles referenced by ARN with a region in them, and the deploy pipeline itself.

A standby you have never failed over to does not work. Whichever strategy you choose, schedule a real failover exercise. The first attempt always surfaces something — a missing quota, a hard-coded region, a DNS TTL nobody lowered.

---

9. Beyond regions and AZs

Thing	What it is	Use when
Local Zones	A small AWS deployment in a metro area, attached to a parent region	Single-digit-millisecond latency to a specific city
Wavelength Zones	AWS infrastructure inside telecom operators' 5G networks	Mobile-edge applications
Outposts	AWS-managed racks in your data centre	Data must stay on premises, or latency to on-prem systems is critical
Edge locations	CloudFront's global cache points of presence	Content delivery — not general compute

Edge locations are not Local Zones. Edge locations cache and terminate connections for CloudFront and a few edge services; you can't run an EC2 instance in one. Confusing the two leads to architectures that assume compute where there is only cache.

---

10. Anti-patterns

Anti-pattern	Why it hurts	Instead
Everything in one AZ	An AZ event is a full outage	Three AZs, load balanced
Comparing AZ names across accounts	The mapping is randomised per account	Use AZ IDs
Hard-coded AMI or subnet IDs in shared modules	They're region-scoped and break on expansion	Look them up by name or tag
"We'll fail over to another region" with no replication	Nothing is there to fail over to	Choose a strategy, replicate, and rehearse
Chatty services spread across AZs on the hot path	Cross-AZ charges both ways, plus latency	Keep hot paths intra-AZ where correctness allows
Assuming quota headroom carries to a new region	Quotas are per region	Request increases before launch day
Leaving unused regions enabled	Somewhere nobody watches for crypto-mining	Disable them; deny by SCP
A CloudFront certificate outside us-east-1	It simply won't attach	Issue CloudFront certs in us-east-1
A standby region never tested	Discovering the gaps during a real incident	Scheduled failover exercises
Multi-region "for resilience" with no RTO/RPO	Enormous cost, untested benefit	State the target first, then pick the cheapest strategy that meets it

---

Check yourself

• Which is the failure domain and which is the isolation domain — the AZ or the region?
• Why is eu-west-1a not a meaningful thing to compare between two accounts, and what is?
• Classify these: an EBS volume, an S3 bucket, an IAM role, a subnet, a Route 53 hosted zone.
• You've replicated your database to a second region. Name four other things that must exist there before a failover works.
• Why does disabling unused regions improve your security posture?
• What's the difference between an edge location and a Local Zone?
• Why must a CloudFront certificate be issued in us-east-1?

---

Next: ARNs, Tagging & Quotas — the identifier every policy consumes, the metadata that makes cost attributable, and the limits that bite on launch day.

← Back to the Foundations overview · ← Previous: IAM & Identity