Transit GatewayとVPC Peeringを比較してみた
こんにちは!AWS事業本部コンサルティング部のたかくに(@takakuni_)です。
タイトルの通り、Transit GatewayとVPC Peeringを比較してみようと思います。
Transit Gatewayは多くの接続オプションがありますが、今回はVPC Peeringとの比較のため、「異なるVPC間の接続」に重きを置いて比較してみようと思います。
共通点
IPv4/IPv6アドレスの対応可否
どちらも、IPv4/IPv6アドレスに対応しています。
Transit Gateway
Transit Gateway は、Transit Gateway ルートテーブルを使ってアタッチメント間で IPv4 と IPv6 パケットをルーティングします。これらのルートテーブルを設定して、アタッチされている VPC、VPN 接続、Direct Connect ゲートウェイのルートテーブルからルートを伝播できます。
VPC Peering
VPC ピアリング接続は、プライベート IPv4 アドレスまたは IPv6 アドレスを使用して 2 つの VPC 間でトラフィックをルーティングすることを可能にするネットワーク接続です。
異なるアカウント/リージョンへの接続
Transit Gateway
Transit Gatewayはリージョナルサービスです。
そのため、別リージョンのTransit GatewayにVPCをアタッチ出来ません。
各リージョンでTransit Gateway作成後に、「Transit Gateway Peering」を行うことでリージョンをまたいだ、異なるVPC間の通信が可能になります。
AWS Resource Access Manager (RAM) を使用して、アカウント全体、またはAWS Organizationsの組織全体で VPC アタッチメントの Transit Gateway を共有できます。
VPC Peering
VPC ピアリング接続は、お客様の VPC 間や、他の AWS アカウントの VPC との間に作成できます。VPC は複数の異なるリージョンに存在できます (これはリージョン間 VPC ピアリング接続とも呼ばれます)。
異なる点
帯域幅
帯域幅に違いがあり、高帯域な要件では検討が必要そうです。
Transit Gateway | VPC Peering | |
---|---|---|
帯域幅 | 50Gbps | 制限なし |
Transit Gatway:帯域幅
VPC Peering:VPC ピア機能とは
VPC 接続数
Transit Gatewayでは、「1つのTransit Gatewayあたりの最大5,000アタッチメント」までサポートしています。
対して、VPC Peeringでは「1つのVPCあたりの最大125接続」までサポートしています。
多くのVPC間で通信したい場合はTransit Gatewayが有効です。
コスト面
課金単位も異なります。
Transit Gatewayは、時間単位のアタッチメント数、トラフィック量に対して課金されます。
VPC Peeringは、接続に対して課金は発生せず、異なるAZ間のトラフィック量に対して課金されます。
Amazon VPC が VPC ピアリングの料金変更を発表
セキュリティグループの参照
セキュリティグループは、VPC内リソースに対してファイアーウォールを実装する機能です。
通常、アクセスを許可する対象に、同一VPC内のセキュリティグループを含めることができます。
VPC Peeringを使用すると、VPC間が同一リージョンの場合、ピアリング先の異なるVPCで作成されたセキュリティグループも対象に拡張できます。
しかし、Transit Gatewayでは対象に拡張できないため設計時に注意が必要です。
結局どちらを使えばいいのか
運用を意識したブログがありましたので、ご紹介させていただきます。
私の個人的な感覚ですが、以下の場合は、Transit Gatewayの利用をオススメします。
- 5 VPC以上のフルメッシュ
- S2S VPNでオンプレミスでもフルメッシュする場合
5 VPC以上のフルメッシュ
先程、ご紹介したブログの通り、フルメッシュVPCのPeering数は「n ( n - 1 ) / 2」で計算できます。
例として、5 VPCをフルメッシュで接続した場合、「5 ( 5 - 1 ) / 2 = 10接続数」が必要になります。
余談ですが、マネジメントコンソールでは、VPC Peering接続の見え方が、ケースバイケースで異なります。
同一リージョン、同アカウント間の接続
1接続IDに対して1つ表示されます。
例:リージョンAのマネジメントコンソール
- pcx-AAAAAAAAAAAAAAA
別リージョンの場合、
1接続IDに対して、接続元、接続先のリージョンの1つずつ表示されます。
例:リージョンAのマネジメントコンソール
- pcx-AAAAAAAAAAAAAAA
例:リージョンBのマネジメントコンソール
- pcx-AAAAAAAAAAAAAAA
別アカウントの場合
1接続IDに対して、リージョン関係なく接続元、接続先のアカウントに1つずつ表示されます。
例:アカウントAのマネジメントコンソール
- pcx-AAAAAAAAAAAAAAA
例:アカウントBのマネジメントコンソール
- pcx-AAAAAAAAAAAAAAA
同じ10接続でも、マネジメントコンソールでは10以上表示されるパターンもあるので、注意が必要です。
S2S VPNでオンプレミスも接続する場合
VPC Peering
以下、VPC Peeringを使用した4 VPC、2拠点のS2S VPNをフルメッシュで接続する構成になります。
結構複雑ですね。(線の量が多い...)
VPN 接続料金は、接続ごとに「0.048 USD/時間(東京リージョン:2022年4月現在)」発生します。
よって、上記の場合、「0.384 USD/時間」接続料金が発生する計算になります。
Transit Gateway
一方、Transit Gatewayを使用した4 VPC、2拠点のS2S VPNをフルメッシュで接続する構成になります。
図の書き方が悪いのか、少し複雑に見えますが、線の数は減っていることがわかります。(14接続から10接続へ)
Transit Gatewayを使用しない場合、S2S VPNのフルメッシュ接続は、VPCの数だけVPN接続が必要となります。
その代わり、Transit Gatewayは、図の通り接続数に応じて、「0.07 USD/時間(東京リージョン:2022年4月現在)」発生します。
よって、上記の場合、「0.7 USD/時間」接続料金が発生する計算になります。
料金を許容できるお客様なら、よりシンプルな構成になるTransit Gatewayをオススメします。
※ 設計には別途「データ転送量」も考慮する必要がございます。
まとめ
以上、Transit GatewayとVPC Peeringをまとめてみました。
弊社ブログでは、「VPC間の通信」を意識して韓国版で既にまとめられていましたが、日本語版がなかったため逆輸入してみました。
Transit GatewayとVPC Peeringどちらを使えば良いのか判断材料にしていただけますと幸いです。
以上、AWS事業本部コンサルティング部のたかくに(@takakuni_)でした!