はじめに
VPCピアリングとTransit Gatewayを比較検討する機会があったので、その結果を残しておきます。
比較観点はたくさんあると思いますが、コスト、非機能、運用性といったあたりに焦点を当てています。
前提となる構成は以下のとおりです。
※前提条件
接続するVPC間でプライベートIPアドレスが重複していないこと。
目次
1.この記事を読んでほしい人
2.VPCピアリングとは
3.Transit Gatewayピアリングとは
4.（おまけ）Transit Gatewayリソース共有とは
5.VPCピアリングとTransit GatewayピアリングとTransit Gatewayリソース共有の比較
6.VPCピアリングとTransit GatewayピアリングとTransit Gatewayリソース共有の運用性とセキュリティについて深掘り
7.まとめ
8.参考資料
1. この記事を読んでほしい人
- VPC間の接続方式について詳しく知りたい人
- VPCピアリングやTransit Gatewayピアリングによる接続を検討している人
- VPCピアリングやTransit Gatewayピアリングについて、コスト・非機能・運用性に焦点を当てた比較結果を知りたい人
2. VPCピアリングとは
2つのVPC間を安全にかつ簡単に接続することができるサービスです。主に、接続するVPCの数が少ない際には有力な選択肢になります。AWS公式ドキュメントでは以下のように説明されています。
VPC ピアリング接続は、プライベート IPv4 アドレスまたは IPv6 アドレスを使用して 2 つの VPC 間でトラフィックをルーティングすることを可能にするネットワーク接続です。どちらの VPC のインスタンスも、同じネットワーク内に存在しているかのように、相互に通信できます。VPC ピアリング接続は、お客様の VPC 間や、他の AWS アカウントの VPC との間に作成できます。VPC は複数の異なるリージョンに存在できます (これはリージョン間 VPC ピアリング接続とも呼ばれます)。
3. Transit Gatewayピアリングとは
Transit Gatewayピアリングは、複数のVPCをシンプルに接続し、ルーティングを一元管理できる機能です。Transit Gatewayを中心に、異なるVPCをピアリングすることで、複雑な接続を簡単に構築できます。AWSの公式ドキュメントでは以下のように説明されています。
リージョン内 Transit Gateway とリージョン間 Transit Gateway の両方をピアリングし、IPv4 および IPv6 トラフィックを含むそれらの間でトラフィックをルーティングできます。これを行うには、Transit Gateway にピアリングアタッチメントを作成し、Transit Gateway を指定します。
Amazon VPC Transit Gateway の Transit Gateway ピアリングアタッチメント
4. （おまけ）Transit Gatewayリソース共有とは
Transit Gatewayを使ったVPC間の接続では、Transit Gatewayのリソース共有も候補に挙がるかと思います。今回はそちらも候補に入れて比較していきます。
5. VPCピアリングとTransit GatewayピアリングとTransit Gatewayリソース共有の比較
さて、本題に入りますが、主にコスト・非機能・運用性の観点で比較してみました。
コスト観点では、VPCピアリングが優りますが、拡張性や運用性を考えるとTransit GatewayピアリングやTransit Gatewayリソース共有のほうが優れていそうです。ただ、運用性についてはイメージしづらいかと思いますので、実際に設定項目や設定回数等を次項で詳しく説明します。
また、セキュリティに目を向けると、Transit GatewayピアリングやTransit Gatewayリソース共有の違いが見えてきます。Transit Gatewayリソース共有では、リソース共有した側のアカウントにてどういった操作まで許可するのかといったような権限に関する設計も追加で必要になってきます。
| 比較項目 | VPCピアリング | 評価 | Transit Gatewayピアリング | 評価 | Transit Gatewayリソース共有 | 評価 |
|---|---|---|---|---|---|---|
| コスト | - データ転送料 | 〇 | - データ転送料 -データ処理料 - Transit Gateway使用料 |
△ | - データ転送料 -データ処理料 - Transit Gateway使用料 |
△ |
| 可用性 | - SLAの設定はないが、AWS内部で冗長化されている | 〇 | - マルチAZで99.99% | 〇 | - マルチAZで99.99% | 〇 |
| 性能 | - 帯域幅に制限がない - 低レイテンシ - ルート情報の追加に伴う性能劣化の可能性がある。 |
〇 | - 最大帯域幅が50Gbps | 〇 | - 最大帯域幅が50Gbps - 同リージョン間の通信ではTransit Gatewayピアリングよりもレイテンシが抑えられる |
〇 |
| 拡張性 | - VPC接続数は最大で125 - CIDRが重複したVPC間で接続不可能 |
△ | - VPC接続数は最大で5000個 - CIDRが重複したVPC間で接続不可能 |
〇 | - VPC接続数は最大で5000個 - CIDRが重複したVPC間で接続不可能 |
〇 |
| 運用性 | - 設定変更作業において設定項目は少ないが、ピアリングの設定箇所はVPC数に比例する - NW構成（VPC間の接続状況等）確認する際に、各VPCの設定等を確認する必要があり負担が大きい |
△ | - 設定変更作業において設定項目はVPCピアリングより多いが、ピアリング設定箇所はVPCの数によらず1回でよい - NW構成（VPC間の接続状況等）確認する際に、Transit Gatewayの設定を確認するだけで良いため負担が小さい |
〇 | - 設定変更作業において設定項目はVPCピアリングより多いが、ピアリング設定箇所はVPCの数によらず1回でよい - NW構成（VPC間の接続状況等）確認する際に、Transit Gatewayの設定を確認するだけで良いため負担が小さい |
〇 |
| セキュリティ | - AWS内の通信 - 同リージョン内であれば、対向先とのセキュリティグループの相互参照が可能。VPC間のリソース単位でのアクセス制御が可能。（クロスアカウントでも可能） |
〇 | - AWS内の通信 - 各VPCでリソース間の細かいアクセス制御が必要な場合は、セキュリティグループの設定が必要 |
〇 | - AWS内の通信 - 各VPCでリソース間の細かいアクセス制御が必要な場合は、セキュリティグループの設定が必要 - リソース共有したTransit Gatewayの操作権限等についてセキュリティ設計（IAMロールの作成等）が必要 |
△ |
| 備考 | - | - | - リソース共有部分は、アカウント間でコストの負担について調整が必要となるケースがある | - |
6. VPCピアリングとTransit GatewayピアリングとTransit Gatewayリソース共有の運用性とセキュリティについて深掘り
前項にて紹介した運用性とセキュリティについて、さらに詳細化したいと思います。
既に接続されているシステムにVPCが追加された場合と新たにAWSシステムが接続してくる場合に必要な設定についてそれぞれまとめました。
VPCピアリング
Transit Gatewayピアリング
Transit Gatewayリソース共有
7. まとめ
本記事では、VPCピアリング、Transit Gatewayピアリング、およびTransit Gatewayリソース共有について、コスト、非機能要件、運用性、セキュリティの観点から比較しました。主なポイントは以下の通りです：
-
コスト面では、VPCピアリングが最も優位ですが、拡張性や運用性を考慮すると、Transit Gatewayを使用する方法がより適している場合があります
-
拡張性においては、Transit GatewayピアリングとTransit Gatewayリソース共有が優れており、最大5000個のVPC接続が可能です
-
運用性の観点では、Transit Gatewayを使用する方法が、設定の一元管理や接続状況の確認が容易であるため、優位性があります
-
セキュリティ面では、VPCピアリングが同リージョン内でのセキュリティグループの相互参照が可能であるという利点がありますが、Transit Gatewayリソース共有を使用する場合は、追加のセキュリティ設計が必要になる点に注意が必要です
-
新規VPCの追加や新たなAWSシステムの接続時の作業量を比較すると、Transit Gatewayを使用する方法が、設定箇所が少なく、作業効率が高いことがわかります
結論として、小規模なVPC接続や単純な構成では、コスト面でVPCピアリングが有利ですが、大規模で複雑なネットワーク構成や、将来の拡張性を考慮する場合は、Transit Gatewayを使用する方法がより適しているといえます。ただし、具体的な選択は、各組織の要件、予算、運用体制などを総合的に考慮して決定する必要があります。
最後に、この比較結果は一般的な状況を想定したものであり、実際の適用にあたっては、個別の状況や要件に基づいて慎重に検討することをお勧めします。
8. 参考資料
本ブログに記載した内容は個人の見解であり、所属する会社、組織とは全く関係ありません。