Two teams at the same company are comparing notes after a bad afternoon. One says the trouble was in us-east-1a. The other checks its own dashboard, sees us-east-1a healthy throughout, and concludes the first team has misread something.
Both dashboards are right. The two accounts are not looking at the same building.
What AWS actually says
This is not a quirk or an outage artefact. It is deliberate, documented behaviour, and AWS states it plainly in the Resource Access Manager user guide:
"AWS maps the physical Availability Zones randomly to the Availability Zone names for each AWS account. As a result, the Availability Zone
us-east-1afor your AWS account might not represent the same physical location asus-east-1afor a different AWS account."
The reason is load. If every account saw the same zone as "a", the first zone in every region would carry the weight of everyone who ever accepted a default. Randomising the letters per account spreads that pressure across the real estate.
The identifier that does hold still
AWS publishes a second name for each zone, and this one is constant everywhere:
zone name us-west-2a account-specific, shuffled
zone ID usw2-az2 stable across every AWS accountThe documentation's own worked example is worth reading twice, because it shows the letters transposed rather than merely offset:
us-west-2a → usw2-az2
us-west-2b → usw2-az1⚠️ An account whose 2a maps to az2 and whose 2b maps to az1 has its first two zones swapped relative to an account where the mapping runs in order. Any comparison between those accounts that trusts the letter is reversed without anyone noticing.
Where this actually bites
The mapping is invisible for a single account operating alone, which is why the behaviour is so easy to miss for years. It surfaces when accounts meet.
Sharing a subnet through Resource Access Manager is the clearest case, and it is the reason the warning lives in that guide rather than in the EC2 documentation. A subnet shared from one account into another arrives carrying a zone ID, and the receiving account's letter for that ID may be anything at all.
Cross-account latency comparisons are quieter about failing. Two workloads that look co-located because both sit in "1a" can be a campus apart, and the millisecond difference gets attributed to instance type, networking configuration or noisy neighbours — to anything except the assumption underneath the measurement.
Post-incident work has the same shape. Correlating an event across accounts by zone letter produces a picture that is wrong in a way no amount of further analysis will reveal, because the error is in the join rather than in the data.
What this does not mean
Nothing here says your redundancy is broken. Spreading instances across 1a, 1b and 1c inside one account genuinely puts them in three distinct physical zones, which is the property multi-AZ design depends on. The letters are stable within an account and they are reliable for that purpose.
⚠️ Nor is the ID a public address. A zone ID identifies the same physical zone for everybody, but AWS does not publish which building any of them is, and nothing here lets you locate a data centre.
What to do with it
Anything that crosses an account boundary should carry the zone ID rather than the zone name. aws ec2 describe-availability-zones returns both, and the ZoneId field is the one that means the same thing to the person reading it as to the person who sent it.
Architecture diagrams shared between teams are worth checking for the same reason. A diagram labelled with letters is ambiguous the moment it leaves the account it was drawn in, and adding the ID beside the letter costs nothing.
If a cross-account latency number has ever looked strange, the mapping is cheap to rule out: pull the zone IDs for both accounts and see whether the pair you assumed were neighbours actually are.
Where this comes from
The quoted sentences and the worked mapping are from the AWS Resource Access Manager User Guide, "Availability Zone IDs for your AWS resources", read directly rather than from a summary. The transposed example is AWS's own describe-availability-zones output as printed on that page.
This is documented behaviour rather than an observation about any particular region, so it holds until AWS changes the mapping policy and says so.
View author profile → · Editorial policy
