TL;DR
- VPC間を接続した際のレイテンシは
TGW > VPC Peering - TGWでVPC間を接続すると、VPC PeeringでVPC間を接続した場合と比較して、レイテンシが10倍以上!!
はじめに
いきなりですが、皆さんは以下のような2つのVPC間を接続する際、どの様な方法で接続するでしょうか？(オレンジ矢印部分)
前提や要件により様々な接続方法が考えられますが、AWS公式:Amazon VPC-to-Amazon VPC connectivity optionsには、VPC間を接続する際の選択肢については以下5つが挙げられています。
AWS公式ドキュメントには選択肢として記載されていないですが、以下2つの方法でもVPC間を接続することが可能です。
なお、AWS公式:Amazon VPC のよくある質問に記載の通り、IGWやNAT GWを経由した場合においてもSourceとDestinationがAWS内である限りは通信がインターネットを経由することはありません(AWS中国リージョンを除く)
Q:
2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスがパブリックな AWS のサービスエンドポイントと通信する場合、トラフィックはインターネットを経由しますか?A:
いいえ。パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。
さらに、データセンターとリージョンを相互接続する AWS グローバルネットワークを流れるすべてのデータは、安全性が保証された施設を離れる前に、物理レイヤーで自動的に暗号化されます。すべての VPC クロスリージョンピアリングトラフィックや、カスタマーまたはサービス間のトランスポート層セキュリティ (TLS) 接続などといった追加の暗号化レイヤーもあります。
今回はVPC間を接続する際によく検討される、VPC PeeringとTGWをレイテンシ観点で比較します。
おことわり
測定結果など注意を払って記載しておりますが、測定結果を利用して生じた一切の責任は負いません。
レイテンシの測定ツールと手法
今回はnetperfのTCP Request/Responseという手法でテストを行います。
通信を行う際にはTCPを利用することが多いかと思いますので、実際のレイテンシに近い値になるように今回の手法を選定しました。
VPC AとVPC BにEC2インスタンス(m7i.large, AmazonLinux2)を以下のように配置し、netperfコマンドを用いて①, ②間のレイテンシ測定を60秒間*2回実施します。
測定コマンド（VPC Aから実行）：
VPC_X_EC2_IP="10.100.x.x" # VPC XのEC2のIPを指定
netperf -H ${VPC_X_EC2_IP} -l 60 -t TCP_RR -w 10ms -v 2 -- -O min_latency,mean_latency,max_latency,stddev_latency,transaction_rate
事前考察
レイテンシを計測する前にVPC Peering, TGWでVPC間を接続した際のレイテンシをAWS公式ドキュメントベースで考察してみようと思います。
VPC Peering
まず、VPC Peeringですが、AWS公式:VPC peeringを見る限り、VPC間が直接接続されている様に見えます。
TGW
次に、TGWですが、AWS公式:TGWを見る限り、VPC間がTGWを経由して接続している様に見えます。
AWS公式:TGW Architecture Diagramに記載の通り、接続する各VPC内のSubnetにTGW Attachment(実態としてはElastic Network Interface(ENI))が作成され、TGW Attachment(ENI)経由でVPC間の通信が行われます。
上記から、VPC間を接続した際のレイテンシとしてはTGW > VPC Peeringとなると考えられます。
測定
netperfによる測定結果(VPC Peering)
2024/07/07 14:00(JST)頃測定
1回目
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.100.0.101 () port 0 AF_INET : spin interval : first burst 0
Minimum Mean Maximum Stddev Transaction
Latency Latency Latency Latency Rate
Microseconds Microseconds Microseconds Microseconds Tran/s
39 49.61 617 8.80 20127.705
2回目
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.100.0.101 () port 0 AF_INET : spin interval : first burst 0
Minimum Mean Maximum Stddev Transaction
Latency Latency Latency Latency Rate
Microseconds Microseconds Microseconds Microseconds Tran/s
41 52.18 599 7.78 19136.958
netperfによる測定結果(TGW)
2024/07/07 14:10(JST)頃測定
1回目
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.100.0.101 () port 0 AF_INET : spin interval : first burst 0
Minimum Mean Maximum Stddev Transaction
Latency Latency Latency Latency Rate
Microseconds Microseconds Microseconds Microseconds Tran/s
348 601.46 2130 97.83 1660.757
2回目
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.100.0.101 () port 0 AF_INET : spin interval : first burst 0
Minimum Mean Maximum Stddev Transaction
Latency Latency Latency Latency Rate
Microseconds Microseconds Microseconds Microseconds Tran/s
401 643.33 1734 92.24 1552.839
平均(Mean)してVPC Peeringの場合は50μs程度, TGWの場合は600μs程度のレイテンシがありました。
おわりに
事前考察通り、VPC間を接続した際のレイテンシはTGW > VPC Peeringとなりました。TGWでVPC間を接続した方がレイテンシが大きくなることは予想しておりましたが、VPC PeeringでVPC間を接続した場合と比較して10倍以上のレイテンシがあったことは想定外でした。改めて実際に測定することが大切だということが良くわかりました。
レイテンシ要件が厳しいシステムにおいてVPC間を接続する場合、VPC Peeringを利用することでレイテンシ要件を満たしやすくなると思います。TGWを利用した場合には、「外部接続用のNAT GWやNetwork Firewallなどを集約することができる」などのメリットもあるため、要件に応じた構成を検討いただければと思います。
今回の記事がVPC間をVPC Peering or TGWどちらで接続しよう...？と迷っている方の参考となれば幸いです。
また、本記事を読んでくださった方が、AWSやネットワークに興味を少しでも持っていただけると嬉しいです。
ここまで読んでくださってありがとうございました。
アクセンチュア株式会社所属の社員有志による運営です。アクセンチュアの社員による様々な発信をまとめています。なお、投稿内容は社員個人の見解であり、所属する組織を代表するものではありません。
Discussion