Tool - AWS Availability Zone Mapper

An overview of how physical availability zones matter, and a tool to map them

Published Feb 17, 2024
I worked on a project where there will be some cross AWS account communication required at a large scale (think databases, think terabytes of data), and needed to consider data transfer costs and how we can reduce said costs for our client.
The original scenario was supporting an RDS database cluster migration using Amazon DMS to a new RDS database cluster in another account. You may not realise it, but there are data transfer costs between availability zones and cross account.
Using the Amazon DMS pricing as our cross account/cross availability zone example, here’s a quote from the pricing page;
All data transfer into AWS Database Migration Service is free, and data transferred between AWS Database Migration Service and databases in Amazon RDS and Amazon EC2 instances in the same Availability Zone also is free. Standard AWS data transfer rates apply when you migrate your source database to a target database in a different Availability Zone, Region, or outside of AWS. Standard AWS data transfer rates are listed on the EC2 instance pricing page.
Essentially if the target database cluster isn’t in the same availability zone, AWS will charge you for the data transfer costs between the replication instance and the target database cluster.
However, this premise is generally applicable to a number of data transfer processes.

The difference between logical and physical availability zones

While the above explanation is all well and good, what am I on about?
The tool I created was written to map AWS logical availability zones to their physical availability zones.
Confused? I don’t blame you!
Not many people don't realise or know that the physical availability zones for one AWS account aren’t the same for another AWS account. While the logical names are exactly the same, the actual physical availability zone can vary per AWS account.
This is to reduce the likelihood that all customers use physical availability zone a by default, and the physical hardware at this zone is at capacity almost immediately.
Amazon map the logical availability zones to different physical availability zones to ensure that no one physical zone has the bulk of customer usage.
Let me explain as if we were working in region ap-southeast-2
(Note: All AWS account Ids, and mapping examples are not accurate)
AWS account: 1111111111111 maps to the following physical availability zones for ap-southeast-2
However, AWS account 222222222222 maps to the following physical availability zones for ap-southeast-2
As you can see the physical availability zone is different for both AWS accounts logical availability zones a and b.

Why this matters

AWS determine internal data transfer costs, even between accounts based on their physical availability zone, not the logical availability zone and as we established these are different for each AWS account.
If you ensure your source and target resources reside on the same physical availability zone, you can generally reduce your costs and/or not be charged at all for data transfer!

The tool

This is where the Availability Zone Mapper comes in handy, it can connect to one or all of you AWS accounts and to one or many AWS regions and then generate a JSON file that contains the mapping between the logical and physical availability zones, which then helps you determine cross account communication or even local account data transfer cost reduction by ensuring resources are communicating on the same physical AZ.

Costs aren’t the only consideration

You may be notified either officially or via your TAM about hardware capacity issues in a particularly physical availability zone. Having a universal reference document to determine which accounts needs to create resources in which availability zone is also extremely handy to negate capacity issue blockers.

Where is the tool?

You can clone and use the tool by visiting the github repository
Please feel free to raise any issues or enhancements or features you would like to see.
Cheers, Jeremy