[レポート] 新サービスの紹介も！複数 VPC における Transit Gateway のリファレンスアーキテクチャ #NET406 #reinvent

こんにちは、菊池です。

本記事は、re:Invent 2019のセッション、NET406 AWS Transit Gateway reference architectures for many VPCs の聴講レポートです。400番台とあって、Transit Gatewayの既存の機能は知っている前提となる、レベルの高い内容でした。

セッション概要

In this advanced session, we review common architectural patterns for designing networks with many VPCs. Segmentation, security, scalability, cross-region connectivity, and flexibility become more important as you scale on AWS. We review designs that include AWS Transit Gateway, AWS Direct Connect, VPN, AWS PrivateLink, VPC peering, and more.

スピーカーは Nick Matthews - Principal Solutions Architect, Amazon Web Services です。

レポート

• セッションの内容
  • Transit Gatewayがどのように動作するか
  • アーキテクチャ
    • アカウント戦略
    • セグメンテーション
    • 接続性
    • ネットワークサービス
    • マルチリージョン
    • コスト
• Before Transit Gateway
  • Transit Gateway登場以前は、VPCやオンプレミスをフルメッシュで接続する必要があった。そのため、環境が大きくなると接続が複雑化するという課題があった。

• After Transit Gateway
  • Transit Gatewayの登場により、ハブ型の構成が可能になり、シンプルで管理性の高い構成をとれるようになった。

構成例

全てのVPCが相互に通信する場合、デフォルトルートドメインにアソシエイトする。

通信を分離する、例えば以下のようにVPN接続を共有し、VPC間の通信は許可したくない場合、ルートドメインを分割することで経路の制御が可能である。

リファレンスアーキテクチャ

• 要素
  • VPC間の通信
    • ステージごととシェアードサービスに分離されたVPC
    • RAMによるサブネットの共有
  • DX/VPN
  • インラインサービス
  • アウトバウンド
  • インバウンド（エッジサービス）

セグメンテーション

• 考え方
  • アカウント、VPC、テナントの関係は？
    • お互いに信頼できるか
    • 今の構成は狙ったものか、それとも副次的なものか
  • セキュリティとネットワークの管理体制は？
    • それぞれのチームか、集約されたチームか
  • コンプライアンスとガバナンスの要件は？
    • スコープを単一アカウント/VPCに絞れるか
• セグメンテーションの選択肢
  • アカウント：ベースラインセキュリティ
    • IAMによる保護
    • SecurityGroupによる保護
  • VPC：ネットワークセキュリティ
    • ルートテーブル
    • ネットワークACL
    • VPCの分割
  • Transit Gateway
    • ルートテーブル
  • セキュリティサービス
    • Firewall
    • プロキシ

要件と構成例

シェアードサービスとVPNを共有し、他のVPC間の通信は禁止するパターン。VPCからのルートテーブルには、VPNとシェアードサービスのみを記載します。

上記から、それぞれのVPN間およびシェアードサービスの間での通信許可を追加。VPNとシェアードサービスのルートドメインにそれぞれを追加します。

PrivateLink VS Transit Gateway

PrivateLinkとTGWをどのような観点で使い分けるべきか。PrivateLinkは1対多に対してTGWは多対多にも対応している。

• PrivateLink
  • スコープ：アプリケーション単位
  • 信頼モデル：手動制御は不可能（アカウント単位は可能）
  • 依存：ロードバランサとアプリケーション
  • スケール：数千VPC
  • コスト：NLBとエンドポイント単位
• Transit Gateway
  • スコープ：VPC
  • 信頼モデル：VPC単位、集中管理可能
  • 依存：TGWによる集中管理
  • スケール：数千VPC
  • コスト：アタッチメント単位

DirectConnect

DX Gatewayを経由して、アカウント・リージョンをまたがる500（50のVIFとVIFあたり10VPC）のVPCと接続が可能です。

Transit Gatewayからは、Transit VIFを経由してDX Gatewayと繋がります。Transit VIFは1ポートにつき1つの制限があることに注意が必要です。以下は、1つのDXが DX Gatewayを経由して3つのTransit Gatewayに繋がる構成です。

DXの他の利用方法として、以下のパターンもあります。

• 並行利用：DXはTGWを経由しない既存の接続
• パブリック接続のDXを経由し、VPN接続

ネットワークサービスの構成パターン

アウトバウンド通信の集約パターン。シェアードVPCのNATインスタンスやNAT Gatewayを経由してアウトバウンドの通信を行います。

インバウンド通信の集約パターン。エッジVPCを経由して、各VPCに通信をルーティングします。

PrivateLinkの集約パターン。シェアードVPCが持つインターフェースエンドポイントを共有します。

ここでNAT Gatewayの仕組みを解説。Transit Gatewayのルーティングを理解する上で、各ホップでSource/DestinationのIPがどのようになっているかイメージできていることは非常に重要かと思います。

新機能の紹介

ここから、キーノートでは名前だけスクリーンに表示された、Transit Gatewayの新機能の紹介です。

まずは、Multicastのサポート。複数のVPCに対するマルチキャストが可能になります。

2つ目はクロスリージョンピアリング。複数のTransit Gatewayを、リージョンをまたいでピア接続できます。新しいアタッチメントのパターン登場しました。

最後は、Global Acceleratorと統合されたVPN接続。AWSのグローバルネットワークを利用して、低レイテンシ/低ジッターで一貫したVPN接続が可能になります。

まとめ

Transit Gatewayの構成パターンを網羅したセッションでした。自分の中での理解が正しいことを再確認できました。