🦡
「距離」から考えるAWSリージョン間通信

2025/12/19に公開
「距離」から見るAWSリージョン間通信レイテンシ

 はじめにAWS Community Builderのぺんぎん（@jitepengin）です。
AWSでアーキテクチャを検討していると、下記のような場面があると思います。
「このリージョンとこのリージョン、どれくらい離れているんだっけ？」
「DR先として選ぶには、現実的な距離なのかな？」
「このレイテンシって、設計でどうにかなる話なんだろうか？」
そこで、今回はリージョン選定やDR設計を考えるための前提としての「距離」に目を向けてみます。
本記事では、レイテンシを正確に測ることを目的にするのではなく、距離 → 理論的に考えられる下限 → 実測レイテンシという順で視点を整理することで、

日々の設計判断を、少しだけ落ち着いて考えられるようになることを目指しています。
レイテンシは、ネットワーク経路や回線品質、混雑状況など、さまざまな要因の影響を受けます。距離だけで語れるものではありませんが、物理的な距離が一つの前提条件になることも、また事実です。
そのあたりを頭の片隅に置きつつ、読み進めていただければ嬉しいです。

 なぜレイテンシではなく「距離」を見るのか皆さんご認識の通り、距離とレイテンシは同義ではありません。
実際の通信では、
海底ケーブルの敷設ルート
ルータやスイッチなど中間機器による遅延
輻輳や経路制御
といった要素が重なり、理論値と実測値には必ず乖離が生じます。

それでも距離を見る価値があるのは、距離が物理的な制約の一つであるからです。

レイテンシの数値は環境や時間帯によって変動しますが、「東京とフランクフルトが遠い」という事実は変わりません。
距離は、
レイテンシの下限を意識するための材料
同期／非同期設計を切り分ける判断軸
DR構成の現実性を考えるための前提条件
として、設計を考える際のヒントになります。

 距離計算の前提（緯度・経度とHaversine式）AWSリージョンも地球上のどこかに存在している以上、緯度（latitude）と経度（longitude）で位置を表現できます。
lat（latitude）：南北方向の位置
lon（longitude）：東西方向の位置
例えば、東京リージョン（ap-northeast-1）はおおよそ次のような座標で表せます。
lat = 35.6895
lon = 139.6917
厳密なデータセンターの座標は把握できないため、今回はおおよその座標を用いてリージョン間の距離を求めようと思います。
距離計算にはHaversine（ハーサイン）式を利用します。

Haversine式とは、地球を完全な球体と仮定し、2地点間の最短距離（大円距離）を計算するための数式です。

緯度・経度から距離を求める際によく用いられます。

下記がポイントとなります。
地球を平面ではなく球体として扱うこと
すべてのリージョンを同じ前提条件で比較すること
あくまでも、精密な測量を目的としたものではなく、リージョン間距離を相対的に把握するための割り切りとして扱います。

 AWSリージョン間の距離を可視化するCLIツール距離を直感的に確認するため、簡単なCLIツールを作成しました。
このツールの目的は、距離を正確に計算することそのものではなく、設計議論の前提となる共通認識を揃えることになります。
https://github.com/dataPenginPenguin/aws-region-distance

 ディレクトリ構成aws-region-distance/
├── regions.json
├── geo.py
└── main.py

 リージョン定義（regions.json）AWSリージョン一覧と、それぞれを代表する都市の緯度・経度を定義します。
{
  "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 }
}



 距離計算処理（geo.py）リージョン間の「物理的距離」を算出するための処理です。

レイテンシ理論値算出（光ファイバー伝搬モデル）は下記で計算しています。
光ファイバー伝搬のみを考慮した理論RTT（往復遅延） = distance_km × 2（往復） ÷ (299792 / 1.47) × 1000（ms換算）

※ 光ファイバー中での信号伝搬速度は おおよそc/1.47（屈折率による）。

※ c = 約 299,792 km/s（真空中速度）

※ 本記事で算出しているレイテンシ理論値は、光ファイバー中の伝搬速度（c / 1.47）を前提とした往復（RTT）の物理的下限値であり、ネットワーク機器や経路制御による遅延は含みません。
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本体（main.py）起点となるリージョンを選択し、他リージョンまでの距離を一覧表示します。
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()


 実行例（東京リージョン起点）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
東京と大阪が数百kmである一方、

欧米リージョンが9,000〜11,000km離れていることが一目で分かります。

サンパウロ遠いですねぇ…

 距離が分かると、設計の議論はどう変わるのかこのCLIは、レイテンシを測定するためのツールではありません。

しかし、距離という共通認識を揃えることで、設計議論の質が変わります。

 レイテンシの議論が現実になる「海外リージョンは遅い」「リージョンを跨ぐとレイテンシが高い」 こうした表現はよく使われますが、その遅さがどの程度なのかを具体的にイメージするのは難しいのかなと思います。
距離を見ることで、
東京 → バージニア：約11,000km
東京 → フランクフルト：約9,500km
といった事実を数字で示せるようになります。

単純に距離が長いことが原因であるため、リアルタイム同期が厳しい理由や、レイテンシが伸びるのが自然であることを直感的に説明できます。

 マルチリージョン設計の腹落ちDRやグローバル展開の議論では、「別リージョンにも配置しましょう」という話が簡単に出てきます。

ここでも距離を見た瞬間に、
同期レプリケーションは現実的ではない
非同期前提の設計が必要
といった判断が、理屈ではなく感覚として理解できるようになります。

 非エンジニアにも説明しやすいレイテンシやネットワークの話は専門用語が増えがちです。

一方で「物理的に1万km離れている」という説明は、エンジニアでなくても直感的に理解できます。

設計意図を共有する場面で、距離という指標は強力な補助線になります。

 マルチリージョン構成の現実的な選択肢日本では、Tokyo（ap-northeast-1）と Osaka（ap-northeast-3）という2つのリージョンがあります。
距離を確認すると、
Tokyo → Osaka：約400km
という結果になります。
この距離感は、国内DR構成を検討する上で現実的な前提になります。

東京と大阪が近いこと自体は感覚的に分かっていても、馴染みのない国や地域については、このような可視化が有効に働く場面もあると思います。

 実測レイテンシ距離はあくまで前提条件です。

最終的な判断には実測レイテンシの確認が必要となります。

一般的には各リージョンにEC2を建ててそこからネットワークツールを使って測定する方法があると思います。
ただ、そのためだけにインスタンスを建てるのも面倒…そういった際に簡易的に確認する手段として、いくつかのツールがあります。

 CloudPing (AWS Latency Monitoring)https://cloudping.co/
このサイトは各リージョンに配置されたエンドポイントへ pingを送信し、RTT（往復遅延）を測定した結果をまとめたものです。
ざっくりとした仕組みとしては、こういったものとなります。
各リージョンの Lambda から他リージョンへ TCP 接続を行い、応答時間を測定
その結果を集計してブラウザ上でマトリクス表示
実測値をもとにしたリージョン間レイテンシの傾向が分かる

 AWS Network ManagerAWS Network Managerを使用することで、AWSグローバルネットワークの通信パフォーマンスがモニタリング可能になります。
これらのツールを活用することでリージョン間通信の実測値を測定可能です。

 理論値と実測値の比較先ほど取得した実測値と理論値を比較してみます。

東京リージョンを起点にいくつかピックアップして理論値とCloudPing (AWS Latency Monitoring)、AWS Network Managerの実測結果をまとめました。


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

eu-south-2
Spain
10762
105.54
234.02
228.00

sa-east-1
São Paulo
18534
181.76
261.56
260.00

CloudPing (AWS Latency Monitoring)とAWS Network Managerはほぼ同じレイテンシが出ていますね。

ここでポイントなのが、レイテンシ理論値は、光ファイバー中の伝搬速度（c / 1.47）を前提とした往復（RTT）の物理的下限値であり、ネットワーク機器や経路制御による遅延は含まないということです。

とはいえ、リージョン間のレイテンシの傾向をつかむには役立つのかなと思います。
距離をもとに、レイテンシの理論値を確認し、イメージをつかんで、そこから実測値を確認するといいかもしれません。

 距離以外にも影響する要素本記事では「物理的な距離」を軸にAWSリージョン間の関係を見てきましたが、実際のレイテンシは距離だけで決まるわけではありません。
例えば、リージョン間の接続方法によっても体感は大きく変わります。
インターネット経由の通信
AWSのグローバルネットワークを利用した通信
Direct Connect を用いた専用線接続
これらは同じリージョン間であっても、安定性や遅延特性が異なります。

ただし、どの接続方式を選んだとしても、物理的な距離そのものがゼロになることはありません。
距離はあくまで「下限値」を決める要素であり、その上にネットワーク構成や回線品質といった要因が積み重なって最終的なレイテンシが決まる、という理解が重要だと思います。

 設計ではどう使うかこの距離に基づいたアプローチは「この構成が可能かどうか」を決めるための前提条件を揃えるために使うのがいいと思います。
実測する前に距離を見ることで、次のような判断が早い段階でできます。
同期前提の設計か、非同期前提の設計か
ユーザー体験に影響が出るレベルか
技術で頑張る領域なのか、割り切るべき領域なのか
DRで現実的なものか

 DR（災害対策）設計での使い方DR構成を考える際に、別リージョンにも同じデータを置くという話が出てくると思います。

距離（レイテンシ）を見ずにこの話をすると、同期レプリケーションが前提になってしまったり、RPO / RTO の議論が曖昧になるといったことが起きがちです。
例えば、
Tokyo → Osaka：約 400 km
Tokyo → N. Virginia：約 11,000 km
この距離差を見るだけで、
Tokyo–Osaka：同期 or ほぼ同期でも現実的
Tokyo–Virginia：非同期前提、遅延許容設計が必須

という判断が、理屈ではなく感覚として腹落ちします。

 リージョン依存サービスを使うかどうかの判断一部のAWSサービスは、リージョン依存が強い、あるいはクロスリージョンでの利用に制約があります。

距離が近いリージョン同士であれば、許容できるレイテンシや実装や運用の複雑さをトレードオフとして検討できますが、距離が大きく離れると、そもそも設計として無理が出ます。
距離を最初に見ておくことで、「技術的にできる」ではなく「設計として成立するか」を冷静に判断できるようになります。

 実測値と組み合わせて考える前述したように距離はあくまで前提条件です。

実際の設計では、次のように組み合わせて使うのが現実的です。
1.距離で大まかな傾向を掴む

2.CloudPing (AWS Latency Monitoring)やAWS Network Managerで実測値を見る

3.許容できるかどうかを判断する
今回のCLIツールは1.を担うものとなります。

いきなり数値の比較に入る前に、「なぜその差が出るのか」を説明できる材料として使えます。

 まとめ今回は、AWSリージョン間の距離を可視化するツールとレイテンシの参考になるサイトを紹介しました。

作成したツール自体はシンプルですが、リージョン間の物理的な距離が分かることで感覚的に語っていた話題を、もう一段具体的に考えられるようになるかもしれません。

また、CloudPing (AWS Latency Monitoring)やAWS Network Managerと組み合わせることでよりイメージしやすくなると思います。
距離はレイテンシそのものではありませんが、設計判断において役立つ前提条件です。

この前提を共有できるだけで、リージョン選定やDRの議論は、感覚論から設計の話へと進めやすくなります。
今回のツールは直接的に使う場面は多くないかもしれませんが、あのリージョン遠いなーだとか、意外と近いなーだとか見てみるのも面白いかもしれません。
今回の記事が、皆さんの設計や学びの参考になれば幸いです。
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
eu-south-2	Spain	10762	105.54	234.02	228.00
sa-east-1	São Paulo	18534	181.76	261.56	260.00
はじめに

なぜレイテンシではなく「距離」を見るのか

距離計算の前提（緯度・経度とHaversine式）

AWSリージョン間の距離を可視化するCLIツール

ディレクトリ構成

リージョン定義（regions.json）

距離計算処理（geo.py）

CLI本体（main.py）

実行例（東京リージョン起点）

距離が分かると、設計の議論はどう変わるのか

レイテンシの議論が現実になる

マルチリージョン設計の腹落ち

非エンジニアにも説明しやすい

マルチリージョン構成の現実的な選択肢

実測レイテンシ

CloudPing (AWS Latency Monitoring)

AWS Network Manager

理論値と実測値の比較

距離以外にも影響する要素

設計ではどう使うか

DR（災害対策）設計での使い方

リージョン依存サービスを使うかどうかの判断

実測値と組み合わせて考える

まとめ

Discussion
