アーキテクチャ 3: AWS Transit Gateway - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

アーキテクチャ 3: AWS Transit Gateway

AWS Transit Gateway は、VPC とオンプレミスネットワークを接続するマネージドルーティングサービスです。Transit Gateway は、ネットワークトポロジを簡素化し、多数の VPC 間の複雑なピアリング関係を回避するのに役立ちます。

Transit Gateway はクラウドルーターとして機能します。VPC と Transit Gatewayの間では、新しい接続が 1 回だけ行われます。Transit Gateway を推移的ルーティングをサポートするハブとして使用することで、メッシュトポロジ内の各単一 VPC 間にピア関係を追加する必要がなくなります。Transit Gateway とそのクォータの詳細については、「Transit Gateway のクォータ」を参照してください。

Transit Gateway を使用してサードパーティサービスを統合すると、以下の利点があります。

  • VPC とサードパーティネットワーク間の双方向トラフィックをサポートします。

  • あらゆる種類の IP トラフィック (TCP と UDP の両方) をサポートします。

  • VPC とサードパーティネットワークの間に集約型のトラフィック検査ポイントをデプロイします。

  • 統合に関係する VPC の数が変化しても簡単にスケールできます。

Transit Gateway ソリューションを使用する際の欠点は、以下のとおりです。

  • 通常、このオプションはダイレクトピアリングオプションよりもコストがかかります。

  • CIDR ブロックの重複はサポートされません。

  • 多くのサードパーティプロバイダーは、完全な制御を維持し、顧客とのコンポーネント共有を最小限に抑えたいため、このソリューションをサポートしていません。

次のアーキテクチャ図は、Transit Gateway を使用して VPC をサードパーティプロバイダーの VPC に接続する方法を簡単に表したものです。各 VPC は Transit Gateway に接続し、ゲートウェイはアタッチされているすべての VPC 間の推移的ルーティングをサポートします。

Transit Gateway を使用して異なる AWS アカウントにVPCを接続する

ただし、実際の設定はより微妙で、このアーキテクチャはデプロイに関するさまざまな考慮事項とオプションに分けられています。

ネットワーク検査の集約

Transit Gateway を使用すると、集約型ネットワークトラフィック検査ポイント、つまり専用の検査 VPC をデプロイできます。リージョン内ピアリングアタッチメントに関連付けられたルートテーブルで静的ルートを使用することで、サードパーティネットワークからのトラフィックをインスペクション VPC に転送できます。トラフィックを検査する場合、AWS Network Firewall またはAWS ゲートウェイロードバランサーを、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにデプロイされた仮想セキュリティアプライアンスと組み合わせて使用できます。詳細については「AWS Network Firewall のデプロイモデル」(AWS のブログ記事) の「集約型デプロイモデル」を参照してください。

Transit Gateway は、双方向トラフィックを対称的にルーティングするインスペクション VPC アタッチメントのアプライアンスモード内にある必要があります。次のアーキテクチャ図に示されているように、Transit Gateway は、アタッチされた VPC からインスペクション VPC の Elastic Network インターフェイスにトラフィックを転送します。

専用 VPC に集約された検査ポイントを作成する

デプロイオプションの選択

最初に検討するべきことは、ネットワーク内の既存の Transit Gateway を使用するか、新しい専用 Transit Gateway を作成するかということです。この場合、より詳細に制御し、サードパーティーネットワークから分離できる専用 Transit Gateway を新たにデプロイすることをお勧めします。このガイドのサンプルアーキテクチャでは、新しい Transit Gateway を作成し、既存のゲートウェイと新しいゲートウェイの間にピアリング接続を作成します。

次に、ユースケースに最適なアーキテクチャを検討します。

  1. アーキテクチャ 3.1: AWS RAM による Transit Gateway — このデプロイオプションでは、単一の Transit Gateway をサードパーティアカウントと共有します。AWS Resource Access Manager (AWS RAM) を使用して、共有関係を設定します。

  2. アーキテクチャ 3.2: Transit Gateway ピアリング — このデプロイオプションでは、2 つの Transit Gateway 間にピアリング接続を作成します。1 つはユーザーアカウント内、もう 1 つはサードパーティアカウント内に作成します。

これらのオプションから選択する際は、以下の利点と欠点を考慮してください。

  アーキテクチャ 3.1: AWS RAM による Transit Gateway アーキテクチャ 3.2: Transit Gateway ピアリング
利点 サードパーティアカウントでは Transit Gateway が不要なため、アーキテクチャが合理化されます。 サードパーティはネットワーク設定をより細かく制御できるため、このソリューションの方が受け入れやすいと感じるかもしれません。
共有 Transit Gateway の所有者として、制御と可視性が向上します。 サードパーティは独自の VPC アタッチメントを保持しているため、運用上の労力が軽減されます。
欠点 サードパーティではネットワーク設定の制御が低下するため、消極的になる可能性があります。 ネットワークアーキテクチャはより複雑です。
サードパーティアカウントの VPC に Transit Gateway アタッチメントを設定する必要があります。 このアーキテクチャでは、トラフィックパスに余分なホップが作成されます。

コストに関する考慮事項

これらのオプションを選択する際は、以下のコスト上の影響も考慮してください。

  • Transit Gateway アタッチメントの時間単位の料金は、アタッチメント (または VPC) のアカウント所有者に課金されます。コストの一部はユーザーが負担し、残りはサードパーティが負担します。

  • データ処理は、Transit Gateway 経由でトラフィックを送信する VPC の所有者に課金されます。Transit Gateway からのデータ受信には課金されません。

  • ピアリングされた 2 つの Transit Gateway 間で送信されるデータには、データ処理料金はかかりません。

詳細については、「Transit Gateway の料金」を参照してください。