この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんばんわ、札幌のヨシエです。 AWS Summit Tokyo 2019 初日のB1-05で行われたセッションのレポートを書きましたのでご査収頂ければと思います。
登壇者
アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト 菊池 之裕
AWS Transit Gateway はお客様が複数のAmazon Virtual Private Cloud (VPC) とオンプレミスネットワークを単一のゲートウェイに接続できるようにするサービスです。AWS で実行するワークロードの数が増えるにつれ、その増加に対応できるよう複数のアカウントと Amazon VPC 間のネットワークをスケールする能力が必要になります。このセッションでは、AWS Transit Gatewayのアーキテクチャおよびユースケースをより深く説明し、Transit Gatewayを理解し使いこなせるようにご説明いたします。
アジェンダ
- TransitGatewayとは
- 用語と動作
- ユースケース
- 注意するところ
- 新機能、TransitGatewayとDXの連携
- まとめ
TransitGatewayとは
- リージョナルゲートウェイ
- 東京リージョンなどのリージョンに紐付いたゲートウェイの意味
- 大規模
- VPCつなぐところ、VGWやDXの接続で数千の接続が出来るようになった
- ルーティングドメイン
- VPCのルーティングが一つだったが、複雑なことが出来るようになった
- アタッチメント毎のルーティングを可能にするルーティングドメインのサポート
- VRFが使えるようになった
- パートナー連携
- ミドルボックスとしてサポートしている
- インスタンス間の通信で監視などを実施するパートナー製品が使える
これまでのAWSネットワーク
- VPC同士はこれまでVPC Peeringで接続していた
- 2箇所,3箇所に増えた場合、フルメッシュで非常に接続するポイントが増えていく
- VPN拠点やDirectConnectを接続すると構成が複雑な悩みに変わっていく
TransitGatewayの登場
- これまでVPC Peeringで接続していたVPC同士の接続をTransitGatewayに集約、接続が出来る
- VPCが増えてもTransitGatewayに接続することで対応完了となる
- 接続するパスの本数が劇的に減り、運用が簡単になる
- また、InlineServiceとしてトラフィックを一時的に取得して監査等が出来るようになる
TransitGatewayの用語と動作
- アタッチメント
- VPC,VPNをTransitGatewayとくっつけるアクション
- アタッチメントすることにより、VPCやVPN同士で通信できる準備
- L3スイッチにポート接続した状態(準備段階のイメージ)
- ルートテーブル
- 経路情報テーブル
- 一つではなく複数のルートテーブルが作れる
- アソシエーション
- アタッチメント済みのVPCをルートテーブルに結びつける
- アソシエートしたルートテーブルにパケットが送信されるようになる
- アソシエーションは1つのルートテーブルにしか適用ができない
- プロパゲーション
- アタッチメントされたVPCからルートテーブルに経路を伝播する
- ルートテーブルに伝播した経路が登録され、ルーティングの際に参照される
- プロパゲートはアソシエートに関係なく複数のルーティングテーブルに設定が可能
- 複数のルートテーブルに伝播可能
- スタティックルート
- 特定のネットワークへの静的ルーティングを指す
VPC内部の通信は？
- VPC内ではTGW向けのルートテーブルを書く必要がある
- 自動でルートテーブルが伝播されない
- スタティックルートでTransitGatewayIdをターゲットにする必要がある
デフォルトの動作
- すべてのアタッチメントは単一のTransitGateway RouteTableに関連付けられる
- すべてのアタッチメントが同じ単一ルートテーブルにルートを伝播する
-
ルートテーブルのスタティックルート
- スタティックルートがかける
- インターネットへのトラフィックなどで使いやすい
- 設定できる経路情報はアソシエートしていないNextHopのVPC/VPNじゃなくてもかける
- ブラックホールルートもかける
-
経路情報さえあれば通る
-
インターネット接続集約構成
- インターネット向けVPCを経由するような経路集約が可能
- ルートテーブルのデフォルトルートをスタティックで書く
- スタティックルートの宛先のVPCでNATGW →IGW
- パケットの戻り経路をTransitGatewayにむける
ユースケース
自由に通信が出来るRouteDomain
- デフォルトの経路設計、TransitGatewayに接続されているすべてのVPCを接続出来る
- ルートテーブルをそれぞれのVPC向けにしたルーティングを入れる
- VPNも同じように設定が可能
- VPCを追加するとルーティングテーブルに自動追加される
VPC間の通信を制限するRouteDomain
- VPC間の相互通信を拒否する設計
- ADや認証系をSharedServiceへのルーティングを入れることで参照が可能
- 2 つのルーティングテーブルを使うことで実現
- VPC → ルーティングテーブル1 (共有サービス と VPN へのルーティングのみ)
- VPN → ルーティングテーブル2 (各VPC へのルーティング)
インターネットに自由に通信できるOutbound Route Domain
- 一つのDefault Routing domainをつなげる
- 一つのrouting domainを用意し、インターネットへ接続できるVPCを0.0.0.0/0に入れることでインターネットが存在するVPC経由でインターネットへ抜ける
- 戻りの経路をスタティックルートで書いてあげる
VPC間のトラフィックをインライン監査するRouteDomein
- VPC間はミドルボックス(用のルート)を適用することでVPC感はミドルボックス経由で接続が出来る
- TransitGatewayに適用するルーティングはそれぞれのVPCごとに書いてトラフィックをやり取りする
- 注意点として、インスタンスが一つだとSPOFになるので、マルチAZでやることが推奨される
- インスタンスのリカバリーのためには、昔のNATインスタンスのように監視とルーティングテーブルを変更するLambdaなどを作って監視する必要がある
注意するところ
- TransitGatewayは作った時に簡単にできる
- DefaultRouteアソシエーションとプロパゲートがDefault enableの状態なので経路制御したいときにはチェックを外す
-
TransitGateway自体を作成した後に変更することが出来ない
-
特にVPC同士を接続する目的の場合はDefault Route TableのEnableで作成することでも運用負荷の軽減につながる
- ただし、上記のユースケースのようにNATgatewayを使ったり、インライン監査といったトラフィックを曲げる必要があるような場合は注意が必要
新機能 TransitGatewayとDirectConnectの連携
- 東京リージョンではまだTransitGatewayとDirectConnectの接続がサポートされていないが、USリージョンでは使用することが可能
- DirectConnectは使えないが、DirectConnect→DirectConnectGatewayの構成であれば利用可能
- トランシット仮想インターフェース(Transit VIF)という専用仮想インターフェースを使う
- US4リージョンで使用できる
最後に
TransitGatewayが登場した際には主に運用負荷軽減の印象がありましたが、監査対応や特定のサービス利用のために使用できる点で勉強になりました。 今後に備えて上記のパターンに関して手を動かして、より理解していきたいと思います。
4
