Amazon ANS-C01: Transit Gatewayとネットワークトポロジー — 学習ガイド
こちらの一部です： AWS Advanced Networking Specialty ANS-C01 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.
コアコンセプト
AWS Transit Gateway (TGW) は、Amazon VPC、VPN、Direct Connect ゲートウェイ、および他の Transit Gateway 間のルーティングを一元化する、リージョナルなネットワークトランジットハブです。最も単純な形では、TGW はルーティングプレーンとして機能します。アタッチメントを作成し (例えば、VPC には EC2 API コールの CreateTransitGatewayVpcAttachment、アプライアンスには CreateTransitGatewayAttachment、ピアリングには CreateTransitGatewayPeeringAttachment を使用)、それらのアタッチメントが1つ以上の Transit Gateway ルートテーブルへの関連付けと伝播を通じてルートを交換する方法を制御します。TGW 上のルートテーブルは、TGW が複数の仮想ルーター (VRF) のように機能することを可能にする、分離とセグメンテーションのプリミティブを提供します。各アタッチメントについて、どの TGW ルートテーブルに関連付けるか (AssociateTransitGatewayRouteTable を使用)、そしてどのアタッチメントがどのテーブルにルートを伝播させるか (ルートテーブルの伝播設定経由) を決定します。TGW は、ソースアタッチメントが関連付けられているすべてのルートテーブルにわたって最長プレフィックス一致に基づいてパケットを転送するため、関連付け/伝播の境界を慎重に設計することが、ハブアンドスポーク、セグメント化されたハブ、またはパーシャルメッシュを実装する方法となります。
Transit Gateway ピアリングは、TGW 間に暗号化されたプライベートなリージョン間またはアカウント間のパスを作成しますが、トラフィックフローを有効にするためには依然としてルートテーブルの設定に依存します。リクエスタ側から CreateTransitGatewayPeeringAttachment でピアリングを作成し、アクセプタ側で AcceptTransitGatewayPeeringAttachment を実行します。その後、ピアリングアタッチメントが使用されるように、適切な TGW ルートテーブルにルートを追加する必要があります。ピアリングは推移的ではありません。つまり、明示的なピアリングとルートテーブルのマッピングが許可しない限り、トラフィックは TGW-B を経由して TGW-A から TGW-C へは流れません。TGW はまた、SD-WAN やサードパーティ製アプライアンスへの高性能な接続性のために Connect アタッチメントもサポートしています。これは CreateTransitGatewayConnect API で作成され、カプセル化 (GRE, VXLAN) と特殊なデバイスへの高スループットの転送を可能にします。
主要なサービスと設定
CreateTransitGatewayVpcAttachment を使用して VPC アタッチメントを設定し、必要なアタッチメントオプションを必ず設定してください。例えば、ネットワークアプライアンスにトラフィックを転送する VPC アタッチメントで ApplianceModeSupport を有効にすると、TGW はアプライアンスにトラフィックを送信する際に元の宛先を保持します。アタッチメントを作成した後、CreateTransitGatewayRouteTable を使用してデフォルト以外の追加の TGW ルートテーブルを作成し、次に AssociateTransitGatewayRouteTable を呼び出して、選択したアタッチメントの伝播を有効にして、そのプレフィックスがルートテーブルに表示されるようにします。マルチキャストのユースケースでは、CreateTransitGatewayMulticastDomain でマルチキャストドメインを作成し、次に参加するアタッチメントに対して AssociateTransitGatewayMulticastDomain を実行し、RegisterTransitGatewayMulticastGroupMembers と RegisterTransitGatewayMulticastGroupSources を使用してグループメンバーシップとソースを確立します。マルチキャストドメインはユニキャストのルートテーブルとは別のものであり、VPC やアプライアンスをまたいだ IGMP スタイルのグループ配信に必要です。
グローバルなトポロジーの可視性とポリシー適用のためには、AWS Transit Gateway Network Manager (AWS Network Manager の一部) を使用します。Network Manager で Global Network を作成し (コンソールまたは networkmanager:CreateGlobalNetwork)、Transit Gateway を登録することで、リージョンやオンプレミス接続をまたいだ north/south (南北) のビューを得ることができます。Network Manager は、自動化されたパフォーマンスモニタリング、コア-ペリフェリの可視化、ルート分析を提供します。CloudWatch メトリクスと VPC フローログを取り込み、それらを TGW アタッチメントや VPN/Direct Connect リンクと関連付けることができます。AWS Resource Access Manager (RAM) との統合により、CreateResourceShare と適切なプリンシパルアタッチメントを使用して、一元管理された TGW を他の AWS アカウントと共有できます。TGW オプションの AutoAcceptSharedAttachments を設定するか、承諾をプログラムで管理することを忘れないでください。
設計パターンとトレードオフ
単一のTransit Gatewayで実装されたハブアンドスポークトポロジーは、接続性を一元化し、ルート配布を簡素化し、共有サービス、セキュリティアプライアンス、オンプレミス接続を集約できるため、マルチVPC、マルチアカウントアーキテクチャで最も一般的なパターンです。1つ以上のTGWルートテーブルを使用してビジネスユニット間のセグメンテーションを提供します。スポークをスポーク専用のルートテーブルに関連付け、共有サービスのプレフィックスは、それらを参照すべきテーブルにのみ伝播させます。トレードオフとして、一元化はトラフィックの単一のチョークポイントとなり、設定ミスの影響範囲（ブラスト半径）が単一で大きくなる可能性があります。TGWを通過する大規模なEast-Westフローには、慎重なトラフィックエンジニアリング、高スループットのアプライアンスのためのConnectアタッチメントのデプロイ、またはトラフィックをローカルに保つためのリージョナルTGWの配置が必要になる場合があります。
フルメッシュ（TGW間のペアワイズピアリングや多数のVPCピアリングリンク）は、直接接続を提供し、一部のトラフィックパターンにおいて中央ハブへの依存を減らしますが、リンク数が増えるにつれて運用が複雑になり、多くの管理ドメインにまたがるセキュリティポリシーの適用を複雑にします。Transit Gatewayピアリング（CreateTransitGatewayPeeringAttachment + AcceptTransitGatewayPeeringAttachment）は、AWSグローバルネットワークを介した暗号化付きのリージョン間バックボーン接続を可能にし、リージョナルな分離といくつかの共有サービスを両立させたい場合に便利です。しかし、ルートテーブルのマッピングを明示的に管理し、ピアリングが推移的でないことを受け入れる必要があります。パターンを組み合わせることも可能です。各リージョンにリージョナルなハブアンドスポークTGWを配置し、リージョン間のトラフィックのためにハブ間をピアリングする構成は、多くの場合、スケール、レイテンシー、障害ドメインのバランスを取るのに役立ちます。
オンプレミスネットワークを統合する場合、Direct Connectのアソシエーション（関連付け）機能を使用して、Direct Connect GatewayをTGWにアタッチします（Direct Connectでプライベート仮想インターフェイスを設定し、Direct ConnectコンソールまたはAPI経由でTGWとのアソシエーションを作成します）。動的ルーティングにはルートベースVPN（BGP over IPSec）を、厳密に制御されたフローには静的ルートを使用するかどうかを検討してください。アプライアンスベースのインスペクションや相互TLS終端のユースケースでは、クライアントとバックエンド間でエンドツーエンドの暗号化が必要な場合、中央のアプライアンスでTLSを終端させることは避けてください。代わりに、アプリケーション層（例えば、EKSのPodなど）でTLS終端を行い、TGWルーティングを使用してトラフィックをALBまたはNetwork Load Balancerに転送し、Proxy ProtocolでクライアントIPを保持するか、ALBのX-Forwarded-Forヘッダーを使用します。
一般的な落とし穴と判断基準
運用上よくある間違いは、TGWが暗黙的なセグメンテーションを提供すると仮定することです。実際にはそうではありません。どのアタッチメントがどのプレフィックスに到達できるかを制御するには、ルートテーブルを明示的に作成・関連付けし、伝播を有効にする必要があります。もう一つのよくある落とし穴は、セキュリティグループとNACLの誤設定です。TGWはルーティングのみを処理するため、すべてのVPCセキュリティグループとNACLは引き続き適用され、意図したエンドツーエンドの接続性と整合させる必要があります。ステートフルなセキュリティグループはインスタンスまたはロードバランサーで評価されることを想定してください。ALBでのTLS終端を越えてクライアントIPを保持する必要がある場合は、ALBのX-Forwarded-Forを有効にし、Network Load Balancerの場合は、ターゲットタイプをIPにし、必要に応じてproxy-protocolを使用してソースIPを保持します。
スケールの決定は、多くの場合、トラフィック量と管理境界に左右されます。単一のTGWを介して多くの高スループットフローを集中させると、パフォーマンスと障害復旧が複雑になる可能性があります。高帯域幅のアプライアンスリンクにはTransit Gateway Connectアタッチメントを使用し、分離のためには複数のTGWをピアリングで接続することを検討し、Network Managerを使用して飽和状態を監視し、アラームをトリガーします。アタッチメント、ルートテーブル、マルチキャストドメインの数のソフトリミットを常に確認し、デフォルトのクォータに依存するのではなく、必要に応じて引き上げをリクエストしてください。
実践的な問題：ユースケースシナリオ
会社：Atlas Financial Services。課題：Atlasは、us-east-1にある10の事業部門VPCを中央の共有サービスVPCに接続し、部門と共有サービス間の最小権限ネットワークアクセスを強制し、将来的には数十の事業部門にスケールさせ、時折Direct Connectリンクを飽和させるバーストをトラブルシューティングするために、事業部門ごとのトラフィックアカウンティングを提供する必要があります。
アプローチ（番号付き）： 1.
undefined
でリージョナルなTransit Gatewayをプロビジョニングし、
undefined
を使用して各事業部門ごとに専用のTransit Gatewayルートテーブルと共有サービス用に1つのルートテーブルを作成します。これにより、VPCピアリングの爆発的な増加なしに部門ごとのセグメンテーションが可能になります。 2. 各事業部門VPCを
undefined
でアタッチし、
undefined
で部門ごとのルートテーブルに関連付けます。共有サービスVPCをアタッチし、共有サービスルートテーブルにのみ関連付けます。 3. 伝播を選択的に有効にします。各事業部門のアタッチメントは自身のルートテーブルに伝播させ、共有サービスのアタッチメントはそのプレフィックスを別の共有サービスルートテーブルに伝播させます。次に、各部門のルートテーブルに、許可されたプレフィックスに対して共有サービスアタッチメントを指す静的ルートを追加し、部門のプレフィックスを共有サービスルートテーブルに伝播させないことで最小権限を強制します。 4. AWS RAM (
undefined
) を使用してTGWを他のAWSアカウントと共有します。これにより、新しい事業部門のオンボーディングはVPCアタッチメントとルートテーブルの関連付けだけで済み、管理オーバーヘッドを最小限に抑えられます。 5. トラフィックアカウンティングとトラブルシューティングのために、TGWと関連VPCでフローログを有効にし、AWS Network Manager (
undefined
でTGWを登録) にTGWをオンボードして、トポロジーの可視化と帯域幅のモニタリングを行います。TGWのフローログとCloudWatchメトリクスを関連付けて、どのアタッチメントがDirect Connectの飽和を引き起こしているかを特定します。 6. 予測可能なピーク時にDirect Connectのキャパシティが飽和する場合は、Direct Connect Gatewayを作成し、TGWへのDirect Connect関連付けを使用します。事業部門ごとのルートタギングを実装し、必要に応じてDirect Connectゲートウェイでルーティングポリシー（オンプレミスのBGPコミュニティやルートフィルター）を設定して、部門ごとのトラフィックを制限またはシェーピングします。
AWSの論理的根拠：部門ごとのルートテーブルを持つTGWを使用することで、強力なセグメンテーションが提供され、ピアツーピアの複雑さなしに部門が追加されるにつれて線形にスケールします。AWS RAMでTGWを共有することで、クロスアカウント管理が最小限に抑えられます。選択的な伝播と静的ルートエントリはルーティングプレーンで最小権限を強制し、セキュリティグループとNACLはインスタンスレベルでアクセスを強制します。フローログとNetwork Managerを組み合わせることで、どのアタッチメントや事業部門がDirect Connectを飽和させているかを特定するために必要な可視性が得られ、Atlasは問題のある部門を対象にクォータ制御を適用したり、キャパシティの増加をリクエストしたりできます。
← ハイブリッド接続: VPNとDirect Connect · すべてのドメイン · DNSとRoute 53 →
これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
試験に合格する →