Original Japanese article: 「距離」から考えるAWSリージョン間通信
Introduction
I'm Aki, an AWS Community Builder (@jitepengin).
When designing architectures on AWS, you’ve probably found yourself asking questions like:
- “How far apart are these two regions, actually?”
- “Is this distance realistic for a DR target?”
- “Is this latency something we can solve with architecture, or not?”
In this article, I want to look at “distance” as a prerequisite for region selection and disaster recovery (DR) design.
The goal here is not to measure latency precisely.
Instead, by organizing our perspective as:
distance → theoretical lower bound → observed latency
I hope to make everyday design decisions feel a bit more grounded and less stressful.
Latency is influenced by many factors: network paths, link quality, congestion, routing policies, and more.
You can’t explain everything with distance alone—but physical distance is one of the hard constraints.
Keeping that in mind, let’s walk through this together.
Why Look at “Distance” Instead of Latency?
As most of you already know, distance and latency are not the same thing.
In real-world communication, factors such as:
- Submarine cable routes
- Delays introduced by routers and switches
- Congestion and routing control
all stack up, and there is always a gap between theoretical and measured values.
So why bother looking at distance?
Because distance is a physical constraint.
Latency values fluctuate depending on environment and time of day, but the fact that Tokyo is far from Frankfurt never changes.
Distance helps as:
- A way to think about the lower bound of latency
- A decision axis for synchronous vs. asynchronous design
- A prerequisite for evaluating the realism of DR architectures
It doesn’t give you the answer—but it gives you a solid starting point.
Assumptions for Distance Calculation (Latitude, Longitude, and the Haversine Formula)
AWS regions exist somewhere on Earth, so their locations can be expressed using latitude and longitude.
- Latitude (lat): north–south position
- Longitude (lon): east–west position
For example, the Tokyo region (ap-northeast-1) can be approximated as:
lat = 35.6895
lon = 139.6917
Since the exact coordinates of AWS data centers are not public, we use approximate coordinates for representative cities.
To calculate distances, we use the Haversine formula.
The Haversine formula assumes the Earth is a perfect sphere and calculates the shortest distance (great-circle distance) between two points. It’s commonly used for distance calculations based on latitude and longitude.
Key points:
- Treat the Earth as a sphere, not a plane
- Compare all regions under the same assumptions
This is not about precise geodetic measurement—it’s a pragmatic way to understand relative distances between regions.
A CLI Tool to Visualize Distance Between AWS Regions
To make distance easier to grasp, I built a simple CLI tool.
The goal of this tool is not absolute accuracy, but to align our assumptions before having architecture discussions.
https://github.com/dataPenginPenguin/aws-region-distance
Directory Structure
aws-region-distance/
├── regions.json
├── geo.py
└── main.py
Region Definitions (regions.json)
This file defines AWS regions and the latitude/longitude of a representative city for each.
{
"us-east-2": { "name": "Ohio", "lat": 40.4173, "lon": -82.9071 },
"us-east-1": { "name": "N. Virginia", "lat": 38.0336, "lon": -78.5080 },
"us-west-1": { "name": "N. California", "lat": 37.7749, "lon": -122.4194 },
"us-west-2": { "name": "Oregon", "lat": 45.5152, "lon": -122.6784 },
"af-south-1": { "name": "Cape Town", "lat": -33.9249, "lon": 18.4241 },
"ap-east-1": { "name": "Hong Kong", "lat": 22.3193, "lon": 114.1694 },
"ap-south-2": { "name": "Hyderabad", "lat": 17.3850, "lon": 78.4867 },
"ap-southeast-3": { "name": "Jakarta", "lat": -6.2088, "lon": 106.8456 },
"ap-southeast-5": { "name": "Malaysia", "lat": 3.1390, "lon": 101.6869 },
"ap-southeast-4": { "name": "Melbourne", "lat": -37.8136, "lon": 144.9631 },
"ap-south-1": { "name": "Mumbai", "lat": 19.0760, "lon": 72.8777 },
"ap-southeast-6": { "name": "New Zealand","lat": -36.8485, "lon": 174.7633 },
"ap-northeast-3": { "name": "Osaka", "lat": 34.6937, "lon": 135.5023 },
"ap-northeast-2": { "name": "Seoul", "lat": 37.5665, "lon": 126.9780 },
"ap-southeast-1": { "name": "Singapore", "lat": 1.3521, "lon": 103.8198 },
"ap-southeast-2": { "name": "Sydney", "lat": -33.8688, "lon": 151.2093 },
"ap-northeast-1": { "name": "Tokyo", "lat": 35.6895, "lon": 139.6917 },
"ca-central-1": { "name": "Central", "lat": 43.6532, "lon": -79.3832 },
"ca-west-1": { "name": "West", "lat": 51.0447, "lon": -114.0719 },
"eu-west-1": { "name": "Ireland", "lat": 53.3498, "lon": -6.2603 },
"eu-west-2": { "name": "London", "lat": 51.5074, "lon": -0.1278 },
"eu-west-3": { "name": "Paris", "lat": 48.8566, "lon": 2.3522 },
"eu-central-1": { "name": "Frankfurt", "lat": 50.1109, "lon": 8.6821 },
"eu-central-2": { "name": "Zurich", "lat": 47.3769, "lon": 8.5417 },
"eu-north-1": { "name": "Stockholm", "lat": 59.3293, "lon": 18.0686 },
"eu-south-1": { "name": "Milan", "lat": 45.4642, "lon": 9.1900 },
"eu-south-2": { "name": "Spain", "lat": 40.4168, "lon": -3.7038 },
"sa-east-1": { "name": "São Paulo", "lat": -23.5505, "lon": -46.6333 },
"me-central-1": { "name": "UAE", "lat": 25.2048, "lon": 55.2708 },
"me-south-1": { "name": "Bahrain", "lat": 26.0667, "lon": 50.5577 },
"il-central-1": { "name": "Tel Aviv", "lat": 32.0853, "lon": 34.7818 }
}
Distance Calculation Logic (geo.py)
This module calculates physical distance between regions.
The theoretical latency is based on fiber optic propagation:
Theoretical RTT (round trip)
= distance_km × 2 ÷ (299,792 / 1.47) × 1000 (ms)
- Signal speed in fiber ≈ c / 1.47 (refractive index)
- c ≈ 299,792 km/s (speed of light in vacuum)
- This represents the physical lower bound of RTT
- Network devices and routing delays are not included
import math
def haversine_km(lat1, lon1, lat2, lon2):
"""
Calculate great-circle distance between two points on Earth.
Returns distance in kilometers.
"""
R = 6371 # Earth radius in km
dlat = math.radians(lat2 - lat1)
dlon = math.radians(lon2 - lon1)
a = (
math.sin(dlat / 2) ** 2
+ math.cos(math.radians(lat1))
* math.cos(math.radians(lat2))
* math.sin(dlon / 2) ** 2
)
c = 2 * math.atan2(math.sqrt(a), math.sqrt(1 - a))
return R * c
def theoretical_rtt_ms(distance_km, fiber_index=1.47):
"""
Calculate theoretical round-trip latency (ms)
based on fiber optic propagation speed.
"""
c = 299_792 # speed of light in vacuum (km/s)
fiber_speed = c / fiber_index
# RTT (round-trip)
return (distance_km * 2) / fiber_speed * 1000
CLI Implementation (main.py)
You select an origin region, and the tool lists distances to all other regions.
import json
from geo import haversine_km, theoretical_rtt_ms
def select_origin_region(regions):
"""
Let user select an origin AWS region.
"""
region_codes = list(regions.keys())
print("Select origin AWS region:\n")
for i, code in enumerate(region_codes, 1):
print(f"{i:2}) {code:15} {regions[code]['name']}")
while True:
try:
idx = int(input("\nEnter number: ")) - 1
if 0 <= idx < len(region_codes):
return region_codes[idx]
except ValueError:
pass
print("Invalid input. Please try again.")
def main():
with open("regions.json", encoding="utf-8") as f:
regions = json.load(f)
origin = select_origin_region(regions)
origin_info = regions[origin]
rows = []
for code, info in regions.items():
distance = haversine_km(
origin_info["lat"],
origin_info["lon"],
info["lat"],
info["lon"],
)
rtt = theoretical_rtt_ms(distance)
rows.append(
(code, info["name"], distance, rtt)
)
rows.sort(key=lambda x: x[2])
print("\nREGION NAME DIST(km) THEOR RTT(ms)")
print("------------------------------------------------------------------")
for code, name, dist, rtt in rows:
print(
f"{code:15} "
f"{name:22} "
f"{dist:8.0f} "
f"{rtt:13.2f}"
)
if __name__ == "__main__":
main()
Example Output (Tokyo as Origin)
Select origin AWS region:
1) us-east-2 Ohio
2) us-east-1 N. Virginia
3) us-west-1 N. California
4) us-west-2 Oregon
5) af-south-1 Cape Town
6) ap-east-1 Hong Kong
7) ap-south-2 Hyderabad
8) ap-southeast-3 Jakarta
9) ap-southeast-5 Malaysia
10) ap-southeast-4 Melbourne
11) ap-south-1 Mumbai
12) ap-southeast-6 New Zealand
13) ap-northeast-3 Osaka
14) ap-northeast-2 Seoul
15) ap-southeast-1 Singapore
16) ap-southeast-2 Sydney
17) ap-northeast-1 Tokyo
18) ca-central-1 Central
19) ca-west-1 West
20) eu-west-1 Ireland
21) eu-west-2 London
22) eu-west-3 Paris
23) eu-central-1 Frankfurt
24) eu-central-2 Zurich
25) eu-north-1 Stockholm
26) eu-south-1 Milan
27) eu-south-2 Spain
28) sa-east-1 São Paulo
29) me-central-1 UAE
30) me-south-1 Bahrain
31) il-central-1 Tel Aviv
Enter number: 17
REGION NAME DIST(km) THEOR RTT(ms)
------------------------------------------------------------------
ap-northeast-1 Tokyo 0 0.00
ap-northeast-3 Osaka 396 3.89
ap-northeast-2 Seoul 1153 11.30
ap-east-1 Hong Kong 2880 28.24
ap-southeast-1 Singapore 5315 52.12
ap-southeast-5 Malaysia 5322 52.19
ap-southeast-3 Jakarta 5785 56.74
ap-south-2 Hyderabad 6315 61.93
ap-south-1 Mumbai 6724 65.94
us-west-2 Oregon 7793 76.42
ap-southeast-2 Sydney 7827 76.75
me-central-1 UAE 7933 77.80
ca-west-1 West 7993 78.39
eu-north-1 Stockholm 8169 80.11
ap-southeast-4 Melbourne 8191 80.33
us-west-1 N. California 8271 81.11
me-south-1 Bahrain 8283 81.23
ap-southeast-6 New Zealand 8841 86.70
il-central-1 Tel Aviv 9159 89.82
eu-central-1 Frankfurt 9332 91.52
eu-west-2 London 9559 93.74
eu-central-2 Zurich 9578 93.93
eu-west-1 Ireland 9585 93.99
eu-west-3 Paris 9712 95.24
eu-south-1 Milan 9715 95.27
ca-central-1 Central 10348 101.49
us-east-2 Ohio 10498 102.95
eu-south-2 Spain 10762 105.54
us-east-1 N. Virginia 10924 107.13
af-south-1 Cape Town 14732 144.47
sa-east-1 São Paulo 18534 181.76
While Tokyo and Osaka are only a few hundred kilometers apart, regions in Europe and the US are 9,000–11,000 km away.
São Paulo is really far.
How Does Knowing Distance Change Design Discussions?
This CLI tool does not measure latency.
But aligning on distance as a shared assumption improves the quality of architectural discussions.
Making Latency Discussions More Realistic
Phrases like “overseas regions are slow” are common—but vague.
By looking at distance, you can say:
- Tokyo → N. Virginia: ~11,000 km
- Tokyo → Frankfurt: ~9,500 km
Once you see the numbers, it becomes obvious why real-time synchronization is difficult and why higher latency is expected.
Better Intuition for Multi-Region Design
In DR or global architecture discussions, “just deploy it in another region” often sounds easy.
Distance makes it clear that:
- Synchronous replication is unrealistic
- Asynchronous design is required
This understanding becomes intuitive, not just theoretical.
Easier to Explain to Non-Engineers
Latency and networking terms can get very technical.
But “these systems are 10,000 km apart” is easy for anyone to understand.
Distance becomes a powerful communication tool.
Realistic Multi-Region Choices in Japan
Japan has two AWS regions:
- Tokyo (
ap-northeast-1) - Osaka (
ap-northeast-3)
The distance is roughly:
- Tokyo → Osaka: ~400 km
This makes domestic DR a realistic option.
For unfamiliar regions or countries, visualizing distance like this can be surprisingly helpful.
Observed Latency
Distance is only a prerequisite.
Final decisions should always be based on measured latency.
You can spin up EC2 instances and measure manually—but that’s often overkill.
Instead, there are convenient tools available.
CloudPing (AWS Latency Monitoring)
CloudPing measures RTT by sending requests between region-based endpoints and visualizes the results in a matrix.
Conceptually:
- Lambda functions in each region initiate TCP connections
- Response times are measured and aggregated
- Inter-region latency trends become visible
AWS Network Manager
AWS Network Manager allows you to monitor performance across the AWS global network.
Comparing Theoretical and Measured Values
Below is a comparison using Tokyo as the origin:
| REGION | NAME | DIST (km) | THEOR RTT (ms) | CloudPing (ms) | AWS Network Manager (ms) |
|---|---|---|---|---|---|
| ap-northeast-3 | Osaka | 396 | 3.89 | 12.91 | 8.09 |
| us-west-2 | Oregon | 7793 | 76.42 | 102.91 | 96.70 |
| eu-west-1 | Ireland | 9585 | 93.99 | 205.86 | 202.00 |
| sa-east-1 | São Paulo | 18534 | 181.76 | 261.56 | 260.00 |
CloudPing and AWS Network Manager show very similar results.
Remember: the theoretical RTT is the physical lower bound based only on fiber propagation speed.
It does not include routing, switching, or congestion.
Still, it’s useful for understanding latency trends.
Factors Beyond Distance
This article focused on physical distance, but real latency depends on more:
- Internet-based connectivity
- AWS global network routing
- Dedicated connections via Direct Connect
Even with the best connectivity, distance never becomes zero.
Distance defines the lower bound, and everything else stacks on top of it.
How to Use This in Design
This distance-based approach is best used to decide whether a design is feasible at all.
Before measuring anything, distance helps you quickly assess:
- Synchronous vs. asynchronous design
- Impact on user experience
- What can be optimized vs. what must be accepted
- Whether a DR strategy is realistic
Using Distance in DR Design
Without considering distance, DR discussions often default to synchronous replication and vague RPO/RTO assumptions.
Just comparing:
- Tokyo → Osaka: ~400 km
- Tokyo → Virginia: ~11,000 km
makes it obvious:
- Tokyo–Osaka: synchronous or near-synchronous may work
- Tokyo–Virginia: async-only, latency-tolerant design required
This understanding clicks immediately.
Deciding on Region-Dependent Services
Some AWS services are tightly region-bound or limited cross-region.
If regions are close, you can trade off latency against complexity.
If they’re far apart, the design may simply not be viable.
Looking at distance first helps you judge architectural validity, not just technical possibility.
Combining with Measured Data
A practical workflow:
- Use distance to understand the rough trend
- Check CloudPing or AWS Network Manager
- Decide if the latency is acceptable
This CLI tool supports step 1—it helps explain why differences exist before comparing numbers.
Conclusion
In this article, we looked at a simple tool for visualizing distance between AWS regions, along with services for observing real latency.
The tool itself is simple, but understanding physical distance helps turn vague assumptions into more concrete design discussions.
Distance is not latency—but it’s an important prerequisite.
Sharing this perspective makes region selection and DR design discussions more grounded and productive.
You may not use this tool every day, but sometimes it’s fun (and useful) to confirm:
“Yeah… that region really is far.”
I hope this article helps with your architecture decisions and learning.
Top comments (0)