https://aws.amazon.com/jp/blogs/aws/use-aws-transit-gateway-direct-connect-to-centralize-and-streamline-your-network-connectivity/

そもそもTransit Gatewayって？

Transit Gatewayはハブ＆スポーク型のネットワークを構築するために便利な機能です。2018年11月のre:Inventで発表されました。

Transit Gatewayがリリースされる前は、複数VPC間で通信をさせたければVPC Peeringを行う必要がありました。VPC Peeringは通信させたいVPCが少なければいいのですが、多くなってきた場合にPeeringが複雑になるという問題がありました。

また、マルチリージョンで災害対策を構築しているようなシステムにおいて、運用面での課題をはらんでいました。つまり、災対リージョンでシステムを復旧する際に、通信したいVPCとVPC Peeringを行う必要性がありますが、相手先のVPCとの調整、相手先VPCも被災している可能性など、ちょっと考えただけでもうんざりしますね。

そこでネットワークの接続と経路制御をTransit Gatewayに丸投げできれば、だいぶすっきりするということが期待されています。

Transit Gatewayリリース時はDirect Connect(オンプレミスと専用線で接続するサービス)との接続ができませんでしたが、この度できるようになったということです。

Transit Gateway & Direct Connect対応リージョン

残念ながらまだ東京リージョンでは使えません。

この度発表された対応リージョンは、

• バージニア
• オハイオ
• カルフォルニア
• オレゴン

の4つです。残念です。東京リージョンが対応するまで待ちましょう。

Transit Gateway & Direct Connectの構成

User Guideによると、

• Direct Connect GatewayとTransit Gatewayを接続する。
• Direct Connect Gatewayは「Transit Virtual Interface」を接続したものでなくてはならない。つまり、キャリアを始めとする第三者のサービスでDirect Connectの提供を受けている場合、サービサー側の対応が必要となります。
• Direct Connect GatewayとTransit Gatewayの所属するAWSアカウントは異なってても良い。ただし、同じpayer IDである必要がある。
• 1つのTransit Gatewayに1つのDirect Connect Gatewayしか接続できない。また1つのTransit VIFは1つのDirect Connect Gatewayにしか接続できない。

マルチリージョンでのTransit GatewayとDirect Connectの可能性

今のところ、「複数のTransit VIFを1つのDirect Connect Gatewayに接続できるのか」「複数のTransit Gatewayを1つのDirect Connect Gatewayに接続できるのか」がわかりません。

一応、下記の文で単数形ではなく複数形になっていることからサポートされていると期待しています。むしろサポートされていないのであればTransit Gatewayのメリットがほとんどありません。

「A Direct Connect gateway supports communication between attached transit virtual interfaces and associated transit gateways only. 」

上記がサポートされているとすれば、ユースケースはこんな感じでしょうか。

構成を補足しますと、

• ポリシーとしてリージョンAをメインとし、リージョンBを災対リージョンとしている（別にそうでなくともいいのですが、説明の都合上そうしました）
• メイン、災対それぞれにTransitGatewayを構築し、両方ともDirect Connect Gatewayと接続する
• 災対側のVPCは構築しておくが、Transit Gatewayとは接続しない（点線部分）
• Direct Connect Gatewayは2つのDirect Connect Locationと接続する。各Locationに2つのTransit VIFを用意する。つまり合計4つのTransit VIFと接続する。日本だとLocation XをTY2またはCC1にし、Location YをOS1にするのがよろしいのではないでしょうか。

この構成とすることで、

• VPCを単位とした災対発動が可能となる。IPアドレスはメイン側と同じものを使う。
• 災対発動時に必要なのは、災対リージョンでのシステム復旧と、VPCとTransit Gateway Bとの接続の2点となる。（細かいことを言えばいろいろありますが）
• 他のVPCと調整したり、被災しているかなどを気にする必要はない。

という構成を実現することができます。運用上課題となりそうなのは、黄色で書いた「VPCとTransit Gateway Bとの接続」の部分ですね。互いに操作が必要となるので、運用組織が別だと手順や責任分解を決めておく必要があります。

まとめ

上記のような妄想は実際に東京リージョンやらで使えるようになっていろいろと試せるようになってからですね。

こういうことがすんなりできるのが当たり前だと思うのですが、これまで後手に回ってた感があるので、ここから使いやすくなるといいですね。