Why AWS Availability Zone IDs Differ Per Account - The Design Intent Behind AZ Mapping
Explains how us-east-1a maps to different physical AZs per account, why AZ IDs (use1-az1) were introduced, the design intent of even capacity distribution, and considerations for cross-account AZ specification.
us-east-1a Is Not the Same Place for Everyone
AWS Availability Zone names (us-east-1a, us-east-1b, etc.) are mapped to different physical AZs per account. Account A's us-east-1a and Account B's us-east-1a may point to different physical data center clusters. This is a piece of trivia that many people don't know even after years of using AWS. The reason AWS adopted this design is even capacity distribution. If us-east-1a pointed to the same physical AZ for all accounts, many users would think "let's just use a," causing load to concentrate on us-east-1a. By randomizing the mapping, load across physical AZs is naturally distributed. This mapping is determined at account creation time and never changes afterward. Within the same account, us-east-1a always points to the same physical AZ.
Introduction of AZ IDs - Uniquely Identifying Physical AZs
Because AZ name mappings differ per account, a way to specify "the same physical AZ" across accounts became necessary. For example, when sharing a subnet with another account using RAM (Resource Access Manager), there are cases where the sharing source and destination want to place resources in the same physical AZ. AZ IDs were introduced to solve this challenge. AZ IDs use a format like use1-az1 and use1-az2, pointing to the same physical AZ across all accounts. If Account A's us-east-1a maps to use1-az1 and Account B's us-east-1c maps to the same use1-az1, both are using the same physical AZ. AZ IDs can be checked in the EC2 console's "AZ ID" column or the ZoneId field of the describe-availability-zones API. For cross-account architecture design, specify physical AZs using AZ IDs rather than AZ names.
Mapping Implementation - How It's Determined
The mapping between AZ names and physical AZs is randomly assigned at account creation time. AWS does not publish the mapping algorithm, but several characteristics have been identified through observation. First, the mapping is not completely random; weighting that considers load balance across physical AZs is likely applied. When a new physical AZ is added, the mapping is presumably adjusted so that more accounts are mapped to that AZ. Second, regarding the relationship between the number of AZs in a region and mapping: us-east-1 has 6 AZs, but new accounts only see 4 to 5 AZs by default. The remaining AZs require opt-in. This is a mechanism to direct new account load to newer AZs when older AZs have limited capacity. Third, even accounts within the same organization (AWS Organizations) have different mappings. If unified mapping is needed within an organization, use AZ IDs.
Cases Where AZ Mapping Becomes an Issue
There are cases where AZ mapping differences actually cause problems. The most common is cross-account data transfer costs. When transferring data from Account A's us-east-1a (physical: use1-az1) to Account B's us-east-1a (physical: use1-az2), the AZ names are the same but the physical AZs differ, incurring inter-AZ data transfer charges ($0.01/GB). Since data transfer within the same physical AZ is free, you can reduce transfer costs by checking AZ IDs and placing resources in the same physical AZ. Another case is latency optimization. Communication latency within the same physical AZ is under 0.1ms, while inter-AZ communication latency is 1-2ms. When microservice-to-microservice communication is frequent, placing them in the same physical AZ can reduce latency. However, from an availability perspective, distributing services across multiple AZs is recommended. Design with the tradeoff between latency and availability in mind.
Local Zones and Wavelength Zones - Extended AZ Concepts
Local Zones and Wavelength Zones are extensions of the AZ concept. Local Zones are small-scale infrastructure placed outside AWS Regions, providing computing resources close to specific cities. While there is no Local Zone in the Tokyo Region, one exists in Osaka. Local Zones are used to provide low-latency services close to end users. Wavelength Zones are AWS infrastructure placed within telecom carrier 5G networks. Requests from 5G devices are processed within the carrier's network, resulting in lower latency than routing through the internet. Local Zones and Wavelength Zones are enabled through an opt-in mechanism different from regular AZs. They are disabled by default and must be enabled from the EC2 console's "AZ" settings. These extended AZs are also assigned AZ IDs and can be used for cross-account identification. To systematically learn about AZ design philosophy, specialized books (Amazon) are helpful.