マネージドサービス部 佐竹です。
AWS Transit Gateway（TGW）の Inter-Region Peering を利用して、東京リージョンとヨーロッパにある全8リージョンの VPC 間を相互に接続し、それぞれの Ping 応答速度を測定しました。その実装方法と、測定結果についてまとめましたのでブログでご紹介します。
- はじめに
- 検証のための要件
- 想定構成
- 実装
- 測定
- 余談：東京リージョン TGW での折り返し通信について
- まとめ
はじめに
結果だけを確認されたい方は Ping 測定結果 をご確認ください。
本題です。
日本で AWS をご利用中のお客様は、東京リージョンをメインにご利用されている場合がほとんどでしょう。
ただ、エンタープライズ企業様の場合は、海外の子会社などから東京リージョンへの接続を行うというシナリオがよくあります。また、この接続においては Public 接続が許されず、Private 接続に限ることも多い状況です。この場合は、CloudFront や Global Accelerator での対応は難しくなってしまいます。
セキュリティの観点からプライベート接続に限られる場合には、海外拠点に近い AWS リージョンに AWS Site-to-Site VPN を敷設し、可能な限りすぐに AWS バックボーンへと接続することで、海外から東京リージョンまでの通信を安定させることが可能になります。
今回、ヨーロッパの支店から東京リージョンへの接続を安定させたいという要望を頂きました。ただ、ヨーロッパのどのリージョンを利用すれば、東京リージョンへの通信遅延が安定して早いのか不明でしたため、ヨーロッパにある全8リージョンと TGW の Inter-Region Peering を実装し、EC2 インスタンス間で Ping を実行して ms を調査しました。
検証のための要件
検証で漏れが出ないように、事前に要件をまとめます。
私は個人的な検証においても、できる限り要件定義と環境構成図の作成をします。というのも、それをしているかどうかで実際の検証作業がうまく行くかどうか、つまりは短時間で完了できるかが変わってくるためです。というわけで、以下より要件です。
まず、検証するリージョンはヨーロッパ圏にある全リージョンとしました。そのうち、3つのリージョンはデフォルトで有効化されていません。このため、Zurich、Milan、Spain のリージョンは別途有効化の対応が必要です。リージョンの有効化については以下の公式ドキュメントを参照ください。
また、それぞれを TGW で結ぶということは、VPC CIDR の重複を避けなければなりません。このため、東京リージョン含めて 9 つの VPC の CIDR を予め定義しておきます。
利用するリージョン及びその CIDR を以下にまとめます。
| Region | Code | 有効化 | VPC CIDR |
|---|---|---|---|
| Asia Pacific (Tokyo) | ap-northeast-1 | 不要 | 172.16.100.0/24 |
| Europe (Frankfurt) | eu-central-1 | 不要 | 172.16.200.0/24 |
| Europe (Ireland) | eu-west-1 | 不要 | 172.16.201.0/24 |
| Europe (London) | eu-west-2 | 不要 | 172.16.202.0/24 |
| Europe (Paris) | eu-west-3 | 不要 | 172.16.203.0/24 |
| Europe (Stockholm) | eu-north-1 | 不要 | 172.16.204.0/24 |
| Europe (Zurich) | eu-central-2 | 必要 | 172.16.210.0/24 |
| Europe (Milan) | eu-south-1 | 必要 | 172.16.211.0/24 |
| Europe (Spain) | eu-south-2 | 必要 | 172.16.212.0/24 |
VPC は全てクラスBを利用し、第3オクテットで判断します。東京リージョンは独立して .100 を付与してあります。デフォルトで利用が可能なヨーロッパの5つのリージョンは .200 を利用します。個別に有効化する必要がある残り3つのリージョンについては、.210番台を採番しました。
AZ/Subnet 設計
今回は検証のため、Availability Zone を複数利用する必要性が低いと判断し、AZ は1つとします。
また、Subnet は「EC2 インスタンスを構築する Subnet」と「TGW アタッチメントを収容する Subnet」がそれぞれあればよく、2つのみ作成します。そして、全ての Subnet は Private Subnet とします。
なお、TGW アタッチメントの Subnet を分離する必要性についてですが、以下の通りベストプラクティスに従うために分離します。
各 Transit Gateway VPC アタッチメントに個別のサブネットを使用します。
EC2 インスタンスへの通信要件
EC2 インスタンスへは Systems Manager (SSM) の Session Manager を利用してログインすることとします。
このため、EC2 インスタンスは Private のまま（NAT も IGW もなし）で良いのですが、SSM のための IAM Role や VPC Endpoint が必要になります。
SSM を利用するために必要な VPC Endpoint は AWS ドキュメントに記載のある通りですが、基本的に以下の3つです。
- ssm.region.amazonaws.com
- ssmmessages.region.amazonaws.com
- ec2messages.region.amazonaws.com
今回はこれに加えて S3 Gateway Endpoint、CloudWatch Logs（logs）、KMS についても作成します。これは、Session Manager のログ出力と、暗号化のために必要となるためです。
このあたりについては以下のナレッジセンターに詳しく記載があります。
EC2 インスタンスにログインが必要なリージョンでのみこれを構築します。
TGW 設計
各リージョンに構築する TGW においては、全て Inter-Region Peering を実装します。
この場合、ヨーロッパの各リージョンからの接続先となるリージョンは東京リージョンのみであり、ヨーロッパのリージョン同士は Peering しません。
想定構成
ざっくりと定義した要件に沿って、本構成の AWS 環境構成図を示します。
早速、この構成図の通り構築して行きます。
実装
そこまで作業量も多いものでもないので、マネジメントコンソールでぽちぽちと実装していきます。
Region の利用申請
最初は以下の状態からスタートになります。
デフォルトで利用が可能なリージョンは、東京リージョンを含めて6つです。このため、3つのリージョンを有効化する必要があります。リージョンの有効化には数十分かかるため、予め有効化しておいたほうが良いでしょう。
AWS マネジメントコンソールの画面右上にあるリージョンの一覧の最下部に「Manage Regions」へのリンクがあります。これを押下すると上画像の画面が現れます。必要なリージョンを複数選択し、有効化します。
「Enable regions」を押下してしばし待ちます。
押下して10数分間は「Enabling」のままです。完了すると、画面右上のリージョン一覧から選択が可能となります。
各 VPC の作成
以下の構成図の通りになるよう、VPC を各リージョンに作成していきます。
それぞれのリージョンに作成する VPC の CIDR は事前に定義した通りとなっています。
マネジメントコンソールから VPC を作る場合「VPC and more」を利用すると Subnet も同時に作成してくれます。今回はこの機能を利用して、Private Subnet も2つ同時に作成することにしました。
要件の通りに選択すると、上図の通りの選択となります。
作成はすぐに完了します。VPC と同時に以下のコンポーネントが完成します。
- TGW Tokyo-subnet-private1-ap-northeast-1a
- TGW Tokyo-rtb-private1-ap-northeast-1a
- TGW Tokyo-subnet-private2-ap-northeast-1a
- TGW Tokyo-rtb-private2-ap-northeast-1a
ルートテーブルが分離されているのが良いですね。
private1 が EC2 インスタンス用、private2 が TGW のアタッチメントが利用する ENI 用です。
この作業を、ヨーロッパのリージョン8か所でも行います。
Transit Gateway 関連作業
各 TGW の作成
TGW はリージョナルサービスのため、全てのリージョンに TGW を作成します。
作成後は上図の通りです。
TGW の設定は特に変更せずそのままとします。そのため、Name タグのみ指定しておきます。
- Default association route table = Enable
- Default propagation route table = Enable
少し補足ですが、上記の2つの設定は「今回の設定においては」意味がない（利用できない）設定となります。
Inter-Region Peering の場合、自動的に TGW のルートテーブルを設定してくれる本設定は機能しないため、全て手動で設定する必要があります。
各 TGW アタッチメントの作成
先ほど作成した各リージョンの TGW と VPC とを紐づけるために TGW アタッチメントの作成を行います。
アタッチメントタイプは「VPC」で、ENI を作成する Subnet は先に記載した通り「subnet-private2」を選択します。
subnet-private1 ルートテーブルの設定
アタッチメントが subnet-private2 に作成されると、Subnet のルートテーブルで経路設定が可能になります。これを忘れると TGW へ通信が行われないため、忘れずに記載しましょう。
そして実際に設定を行うのは EC2 インスタンスを作成予定の「rtb-private1」側です。上画像の通り、初期値のままでは local にしか経路がありません。
今回は「172.16.0.0/16」を全て TGW へと向けます。シビアに設計するのであれば、ここに8つのリージョン全ての CIDR を別々に記載すべきという気もしますが、今回は作業を省力化するために全ての VPC を「172.16.0.0/16」内に入れたのでこのようにしておきます。
この作業を全リージョンでそれぞれ実施します。
EC2 関連作業
Default VPC Security Group のルール変更
ここでも省力化のために、default VPC security group (Sg) を利用します。
EC2 は「172.16.0.0/16」からの通信を全て許容する Inbound Rule を記載しておきます。
同様に、この作業を全リージョンでそれぞれ実施します。
VPC Endpoint の作成
東京リージョンでのみ VPC Endpoint の作成を行います。作成する Endpoint は以下の6つです。
- com.amazonaws.ap-northeast-1.ssm (Interface)
- com.amazonaws.ap-northeast-1.ssmmessages (Interface)
- com.amazonaws.ap-northeast-1.ec2messages (Interface)
- com.amazonaws.ap-northeast-1.s3 (Gateway)
- com.amazonaws.ap-northeast-1.logs (Interface)
- com.amazonaws.ap-northeast-1.kms (Interface)
なお、S3 のみ Gateway 型となっており、指定した Subnet の Route Table に経路の追加が行われます。
Interface 型は ENI が作成されるため Subnet が必要です。これは「TGW Tokyo-subnet-private2-ap-northeast-1a」へ収容します。加えて Interface 型に付与する Security Group ですが、これも Default VPC Security Group をアタッチすることとして省力化します。
各 EC2 インスタンスの構築
手順としては先に TGW Inter-Region Peering を作成しても良いのですが、今回は EC2 インスタンスを構築する本作業を先に実施します。
今回は、各リージョンの「subnet-private1」に tg4.micro の Amazon Linux インスタンスを構築しました。Sg は先に修正した default Sg を利用します。SSM のための IAM Role もアタッチしておきましょう。
作成が完了すると、上図の通りになります。
念のため SSM Fleet Manager から作成されたインスタンスのステータスを確認しておくとよいでしょう。東京リージョンでは SSM Session Manager でログインを試みますが、ここで正常動作の確認ができない場合、SSM が利用できません。
TGW Inter-Region Peering 関連作業
最後に、東京リージョンに作成された TGW と各リージョンの TGW とを、Inter-Region Peering で接続します。
この作業が完了すると、先に掲載した以下の構成図通りとなります。
各ヨーロッパリージョンから TGW アタッチメントの作成
各ヨーロッパリージョンから作業を行います。
TGW の Inter-Region Peering はアタッチメントの作成画面から行うことができます。
アタッチメントタイプに「Peering Connection」を選択し、ターゲットとなる TGW の ID を指定します。この時、TGW の ID は手入力を行う必要があるため、東京リージョンの TGW ID はメモしておきましょう。
この画面は、フランクフルトリージョンから東京リージョンに対して TGW Inter-Region Peering を作成したところです。
この作業を、ヨーロッパのリージョン8か所で行います。
東京リージョンでの TGW アタッチメントの承諾
フランクフルトリージョンで TGW Inter-Region Peering を作成すると、東京リージョンの TGW アタッチメント画面にそれが表示されるようになります。
ステータスは「Pending Acceptance」の状態となります。
これを東京リージョン側で承諾（Accept）する必要があります。
承諾してしばらく待つと「Available」になります。
残り7つの TGW についても順に承諾します。
後の作業で各アタッチメントを判別しやすくするために、どのリージョンのアタッチメントなのかを Name タグに記載しておくとよいでしょう。
全てが Available になったことを確認します。
各 TGW ルートテーブルでの Static Route の作成
先に記載した通り、TGW ルートテーブルに自動的に経路が流れてくることはありませんので、手動で経路を追加します。
まずはヨーロッパの各リージョンからです。経路の向きは、上図の赤矢印の通りです。
この画像は、フランクフルトリージョンでの TGW の static route 追加画面です。
今回は「172.16.0.0/16」を全て TGW Inter-Region Peering のアタッチメントへと流す経路を記載します。
正しく経路が設定されると、上画像の通り Peering に Static 経路が記載された状態となります。これをヨーロッパの各リージョンで同様に設定していきます。
東京リージョンでの Static Route の作成
ヨーロッパの各リージョンでは、Peering 先は東京リージョンのみですが、東京リージョンから見た場合、その相手となる Peering アタッチメントが8つになります。
よって、Static Route も8つ必要です。
このため、Static Route の作成画面で8つのアタッチメントが現れますが、Name タグを記載しておくと判別が容易です。
各ヨーロッパのリージョンでは「172.16.0.0/16」を宛先としてざっくり記載していますが、東京リージョンではこの設計は利用できません。
アタッチメントの先に存在する CIDR ごとに、それぞれ正しく8つの Static Route を設定します。
経路の向きは、上図の赤矢印の通り先ほどと逆向きです。
8つ全ての Static Route を東京リージョンで設定したら作業は全て完了です。
これで、Ping を送信するテストの土台が完成しました。
測定
Ping を送るには 各 EC2 インスタンスの IP アドレスが必要なため、以下に IP アドレスの一覧を示します。
| Region | Code | VPC CIDR | EC2 IP Address |
|---|---|---|---|
| Asia Pacific (Tokyo) | ap-northeast-1 | 172.16.100.0/24 | 172.16.100.133 |
| Europe (Frankfurt) | eu-central-1 | 172.16.200.0/24 | 172.16.200.132 |
| Europe (Ireland) | eu-west-1 | 172.16.201.0/24 | 172.16.201.140 |
| Europe (London) | eu-west-2 | 172.16.202.0/24 | 172.16.202.140 |
| Europe (Paris) | eu-west-3 | 172.16.203.0/24 | 172.16.203.134 |
| Europe (Stockholm) | eu-north-1 | 172.16.204.0/24 | 172.16.204.132 |
| Europe (Zurich) | eu-central-2 | 172.16.210.0/24 | 172.16.210.132 |
| Europe (Milan) | eu-south-1 | 172.16.211.0/24 | 172.16.211.140 |
| Europe (Spain) | eu-south-2 | 172.16.212.0/24 | 172.16.212.142 |
Ping を試した結果を以下にざっと記載します。
東京リージョンからフランクフルトリージョン
sh-5.2$ ping 172.16.200.132 PING 172.16.200.132 (172.16.200.132) 56(84) bytes of data. 64 bytes from 172.16.200.132: icmp_seq=1 ttl=124 time=231 ms 64 bytes from 172.16.200.132: icmp_seq=2 ttl=124 time=228 ms 64 bytes from 172.16.200.132: icmp_seq=3 ttl=124 time=228 ms
東京リージョンからアイルランドリージョン
sh-5.2$ ping 172.16.201.140 PING 172.16.201.140 (172.16.201.140) 56(84) bytes of data. 64 bytes from 172.16.201.140: icmp_seq=1 ttl=124 time=218 ms 64 bytes from 172.16.201.140: icmp_seq=2 ttl=124 time=216 ms 64 bytes from 172.16.201.140: icmp_seq=3 ttl=124 time=216 ms
東京リージョンからロンドンリージョン
sh-5.2$ ping 172.16.202.140 PING 172.16.202.140 (172.16.202.140) 56(84) bytes of data. 64 bytes from 172.16.202.140: icmp_seq=1 ttl=124 time=224 ms 64 bytes from 172.16.202.140: icmp_seq=2 ttl=124 time=223 ms 64 bytes from 172.16.202.140: icmp_seq=3 ttl=124 time=223 ms
東京リージョンからパリリージョン
sh-5.2$ ping 172.16.203.134 PING 172.16.203.134 (172.16.203.134) 56(84) bytes of data. 64 bytes from 172.16.203.134: icmp_seq=1 ttl=124 time=238 ms 64 bytes from 172.16.203.134: icmp_seq=2 ttl=124 time=236 ms 64 bytes from 172.16.203.134: icmp_seq=3 ttl=124 time=236 ms
東京リージョンからストックホルムリージョン
sh-5.2$ ping 172.16.204.132 PING 172.16.204.132 (172.16.204.132) 56(84) bytes of data. 64 bytes from 172.16.204.132: icmp_seq=1 ttl=124 time=247 ms 64 bytes from 172.16.204.132: icmp_seq=2 ttl=124 time=245 ms 64 bytes from 172.16.204.132: icmp_seq=3 ttl=124 time=245 ms
東京リージョンからチューリッヒリージョン
sh-5.2$ ping 172.16.210.132 PING 172.16.210.132 (172.16.210.132) 56(84) bytes of data. 64 bytes from 172.16.210.132: icmp_seq=1 ttl=124 time=222 ms 64 bytes from 172.16.210.132: icmp_seq=2 ttl=124 time=220 ms 64 bytes from 172.16.210.132: icmp_seq=3 ttl=124 time=220 ms
東京リージョンからミラノリージョン
sh-5.2$ ping 172.16.211.140 PING 172.16.211.140 (172.16.211.140) 56(84) bytes of data. 64 bytes from 172.16.211.140: icmp_seq=1 ttl=124 time=218 ms 64 bytes from 172.16.211.140: icmp_seq=2 ttl=124 time=216 ms 64 bytes from 172.16.211.140: icmp_seq=3 ttl=124 time=216 ms
東京リージョンからスペインリージョン
sh-5.2$ ping 172.16.212.142 PING 172.16.212.142 (172.16.212.142) 56(84) bytes of data. 64 bytes from 172.16.212.142: icmp_seq=1 ttl=124 time=227 ms 64 bytes from 172.16.212.142: icmp_seq=2 ttl=124 time=225 ms 64 bytes from 172.16.212.142: icmp_seq=3 ttl=124 time=225 ms
所感
最初の ping だけ 2 ms 程度遅くなり、その後安定します。
Ping を実行しなおすとその度に ms が数 ms 前後しましたので、7回程度実行してその幅と平均値を出すことにしました。
その結果が以下の一覧になります。
Ping 測定結果まとめ
| From | Destination | Ping ms | Ping ms (Ave.) |
|---|---|---|---|
| Asia Pacific (Tokyo) | Europe (Frankfurt) | 223～228 ms | 225 ms |
| Asia Pacific (Tokyo) | Europe (Ireland) | 214～217 ms | 216 ms |
| Asia Pacific (Tokyo) | Europe (London) | 221～225 ms | 223 ms |
| Asia Pacific (Tokyo) | Europe (Paris) | 233～238 ms | 235 ms |
| Asia Pacific (Tokyo) | Europe (Stockholm) | 244～248 ms | 246 ms |
| Asia Pacific (Tokyo) | Europe (Zurich) | 219～223 ms | 221 ms |
| Asia Pacific (Tokyo) | Europe (Milan) | 214～217 ms | 216 ms |
| Asia Pacific (Tokyo) | Europe (Spain) | 221～226 ms | 223 ms |
結論としては、東京リージョンとヨーロッパの各リージョン間で TGW Inter-Region Peering を行った場合、Ping 応答に最も遅延がなかったのは「Europe (Ireland)」と「Europe (Milan)」でした。
注意事項
本結果は2023年6月27日時点における結果であり、今後これが変化する可能性があります。
また、利用者のヨーロッパの拠点から AWS の各リージョンに到達する間の Ping 応答については本検証の対象外です。このためアイルランドリージョンを選択したとしても、そもそもアイルランドリージョンまで距離があるということもあるでしょう。
本番での要件定義においては、本情報のみを鵜呑みにするのではなく、実際に POC 等を実施し、実際の通信速度や遅延の測定を行ってください。
余談：東京リージョン TGW での折り返し通信について
今回同時に検証したかったことがあります。
それは上図の赤矢印にある TGW Inter-Region Peering を跨いだリージョン間のヘアピンです。
この経路の実現のために、今回は各ヨーロッパのリージョンにおける「Subnet ルートテーブル」と「TGW ルートテーブル」にそれぞれ「172.16.0.0/16」を記載しました。
構成図に省略したルートテーブルをマッピングすると、上図の通りです。この設定では「172.16.0.0/16」は全て東京リージョンより先にある、という経路になります。
このように記載した状態では、東京リージョンにある TGW で折り返し通信が発生します。具体的には、フランクフルトリージョンからアイルランドリージョンにある EC2 インスタンスに Ping を実行した場合、一度東京リージョンに到達した後、東京リージョンからアイルランドリージョンに入るという経路で、Ping が到達します。
この場合の Ping は「ヨーロッパ⇔東京」間を往復するため、その Ping の応答 ms は「225 ms＋216 ms = 441 ms」程度となりました。
折り返し通信をさせたくない場合の経路
今回のような東京リージョンにある TGW での折り返し通信を発生させたくない場合、それぞれのルートテーブルに記載する経路は「172.16.100.0/24」のみとすべきとなります。
上図の通り、ルートテーブルの設定が「172.16.100.0/24」であれば東京リージョンの CIDR のみとなりますので、折り返し通信は発生しません。
明示的に拒否としたい場合は、TGW でブラックホールルートを記載しても良いでしょう。
遅延最小で通信をさせたい場合はどうすべきか
フランクフルトリージョンとアイルランドリージョン間をもし通信させたい場合は、これらのリージョン間にも TGW Inter-Region Peering を実装して経路を記載すればよいとなります。
まとめ
今回のブログでは、検証として AWS Transit Gateway の Inter-Region Peering を利用し、東京リージョンとヨーロッパにある全8リージョンの VPC 間を相互に接続し、それぞれの Ping 応答速度を測定しました。
実行結果としては、Ping 応答に最も遅延がなかったのは「Europe (Ireland)」と「Europe (Milan)」でした。
以下に測定結果のまとめを再掲しておきます。
| From | Destination | Ping ms | Ping ms (Ave.) |
|---|---|---|---|
| Asia Pacific (Tokyo) | Europe (Frankfurt) | 223～228 ms | 225 ms |
| Asia Pacific (Tokyo) | Europe (Ireland) | 214～217 ms | 216 ms |
| Asia Pacific (Tokyo) | Europe (London) | 221～225 ms | 223 ms |
| Asia Pacific (Tokyo) | Europe (Paris) | 233～238 ms | 235 ms |
| Asia Pacific (Tokyo) | Europe (Stockholm) | 244～248 ms | 246 ms |
| Asia Pacific (Tokyo) | Europe (Zurich) | 219～223 ms | 221 ms |
| Asia Pacific (Tokyo) | Europe (Milan) | 214～217 ms | 216 ms |
| Asia Pacific (Tokyo) | Europe (Spain) | 221～226 ms | 223 ms |
Submarine Cable Map
海底ケーブルを想像すると、地中海に面しているであろうイタリア（ミラノ）が最速になるのではという事前想定がありましたが、測定してみるとミラノとアイルランドリージョンは同値だったので少々意外な結果でした。
ということで、Layer 1 （物理層）の勉強のために 「Submarine Cable Map」 もみてみます。
どうでしょう。
イタリア周辺を拡大してみてみると、地中海にある海底ケーブルから Milan は結構遠い上に内陸のため、その点で少し遠いのかもしれません。
Google Maps の画像も合わせて紹介すると、Milan の場所は上画像の通りです。
というわけで終わりにしたいと思います。本検証結果が、ヨーロッパリージョンの選択における何らかの参考となれば幸いです。
では、またお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023 Japan AWS Top Engineers/2020-2023 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
