【レポート】Transit Gateway, PrivateLink VPC アーキテクチャー deep dive #AWSSummit

はじめに

大阪オフィスの川原です。

みなさん AWS Summit Online 楽しんでいますでしょうか。

本記事は AWS Summit Onlineの セッション Transit Gateway, PrivateLink VPC アーキテクチャー deep dive のレポートとなっています。 Transit Gatewayと PrivateLinkのそれぞれのユースケース・使い分けが理解できる、とても良いセッションでした。

セッション概要

スピーカー

アマゾン ウェブ サービス ジャパン株式会社 技術統括本部レディネスソリューション本部 ソリューションアーキテクト ネットワークスペシャリスト

菊池 之裕 さん

概要

Transit Gateway,PrivateLink など、VPC にまつわるサービスが複数存在し、 問題解決の方法が複数あり迷われている方も多くいらっしゃると考えます。 そこで、ユースケースを交えて適材適所のネットワーキング構成をより深くご紹介します。

セッション視聴のリンクは こちら。

セッションレポート

アジェンダ

• Transit Gatewayの適材適所な使い方
  • VPC Peering の置き換え
  • VPC間通信を禁止、エンドポイントの統合
  • インターネット接続やインスペクション
  • リージョン間通信
  • 注意する点
• PrivateLinkの適材適所な使い方
  • SaaS としてのAPI提供
  • 事業会社やサービスの統合
  • 注意する点

[TGW] Transit Gateway の適材適所な使い方

まずは Transit Gateway(TGW) の活用についての説明です。

以下、TGWをコアとして実現できる構成を 1枚にまとめた「リファレンスアーキテクチャ」です。

また、最近のアップデートで Transit Gateway インターリージョンピアリング が提供されました。 他リージョンのTGWを介した通信も可能になっています。

[TGW] VPC Peering の置き換え

すべてのVPC間の通信、オンプレミスへのアクセスが可能になる構成です。

ルートテーブルは 1つのみ。 デフォルトの設定で TGWを作成で実現できます。 特に考慮することなく相互の通信が可能になります。

• メリット
  • マルチアカウントでルーティングテーブルを気にしない
  • 1ルーティングテーブルですべてを処理
• デメリット
  • TGWでVPC間アクセス管理はできない
    • VPC内の NACL, Security Group で制御する代替案はあります
  • 複数ルーティングテーブルの構築に不向き

[TGW] VPC間通信を禁止、エンドポイントの統合

共通サービスVPC(画像: Shared services, VPC4) を作成しています。 他 VPC(画像: VPC1, VPC2, VPC3) の相互通信を拒否しながら、 共通サービスVPCへのアクセスを可能にする構成です。

ルートテーブルは 2つ、他VPC(VPC1,2,3) に関連付けたルートテーブルと、 共通サービスVPCに関連付けたルートテーブルです。

• メリット
  • TGWですべての VPC/DX/VPN間の通信を制御
  • マルチアカウントでVPC内を制御できないときに最適
• デメリット
  • ルーティングテーブルが複数必要になるため、ルーティングの知識がある程度必要
    • TGWをインフラ部隊が管理して、VPCを各開発部隊が自由に利用する場合におすすめ

[TGW] インターネット接続/インスペクション

▼ インターネット接続

アウトバウンドサービスVPC(画像: VPC4) を作成して、 他VPC(画像: VPC1/2/3)のインターネットへの通信を 「アウトバウンドサービスVPC内のNATゲートウェイ」経由に集約する構成です。

▼ インスペクション

VPC間の通信を「ミドルボックス(画像: 10.4.0.0/16のVPC)経由」で行うようにする構成です。 トラフィックを特定のセキュリティアプライアンスで監査したい場合に有用です。

• メリット
  • 個別のIGWではなくインターネット向け通信を統合することができる
  • いままでできなかったインライン監視が実現可能に
• デメリット
  • ルーティングテーブルが複数必要になるため、ルーティング知識がある程度必要
  • インスペクションをするインスタンスの冗長を考える必要あり

[TGW]リージョン間通信

上図は東京リージョン、シンガポールリージョン、オンプレミスを接続するTGW構成です。 TGWインターリージョンピアリングを活用しています。

ピアリングアタッチメント を作成することで東京リージョンTGWとシンガポールリージョンTGWを接続しています。 リージョン間通信はルート伝播ができないため、スタティックに経路を書く必要があります。

[TGW] 注意点: TGWアタッチメントの設計

上図のように TGWのアタッチメントENI専用のサブネット を作ることがオススメです。

[PL] PrivateLink の適材適所な使い方

次は PrivateLinkについて。

AWS PrivateLinkはネットワークトラフィクを AWSネットワーク内 に限定して、 AWSでホストされているサービスに簡単かつ セキュアにアクセス するための機能です。

290の PrivateLinkパートナーがあり、 AWSのマーケットプレイスからこれらサービスを PrivateLink経由で簡単に利用可能です。

[PL] SaaS としてのAPI提供

Webアプリを PrivateLink経由で公開できます。

プロバイダー側に「サービスを提供するインスタンス」と「Network Load Balancer(NLB)」を配置、 カスタマー側にNLBに接続するための VPCエンドポイントを配置します。

[PL] 事業会社やサービスの統合

上図はエンドポイントサービス(画像右: Endpoint Service) を公開して、 オンプレミス(画像左: DC1/2) から DirectConnect経由でアクセスできるような構成です。

オンプレミス、VPC間のIPアドレス重複可 が PrivateLinkのメリットの1つです。 サービスを公開しているVPCと、それを利用するオンプレミス間のIPアドレスが被っていないか、 考慮する必要がありません。

[PL] 注意点: エンドポイントのAZ制約

PrivateLinkの ENIは同一AvailabilityZone(AZ)内にサービスプロバイダー(NLB)がある場合のみ作成可能です。 AZにNLBが無い場合は、そのAZにPrivateLinkを作成できません。

ベストプラクティスとして、サービスプロバイダーは すべてのAZにNLB を配置することが望ましいです。 また、コンシューマー側はエンドポイントの名前解決で リージョンDNS名 を使うようにしましょう。

まとめ

Transit Gateway と PrivateLinkのまとめです。

• Transit Gateway は集中管理できる組織、IPアドレスの重複がないネットワークに有用
• 他企業へのSaaS, Webサービス提供, IPアドレスの重複のあるネットワークにおすすめ

おわりに(所感)

Transit Gateway, PrivateLink VPC アーキテクチャー deep dive セッションレポートでした。

Transit Gateway はルート設計をする必要はありますが、従来のサービスではできなかった 柔軟なネットワーク制御を実現できる、素晴らしいサービスですね。最近のアップデート(TGWインターリージョンピアリング) でできることの幅が更に広がりました。 PrivateLinkも オンプレミスとのIPアドレス重複を考慮する必要なく、サービスを展開できることはとても良いメリット だと感じました。

以上、Transit Gatewayと PrivateLinkのユースケースを良く理解できる良いセッションでした。 是非実際のセッション動画もご視聴ください。

セッション視聴のリンクは こちら。