DX系サービスの変遷とAWS Transit Gatewayの嬉しいところ

AWS運用自動化サービス「Cloud Automator」

杉村です。re:InventでAWS環境のネットワークアーキテクチャを大きく変えるサービスがローンチされました。
既に随所で話題になっているAWS Transit Gatewayです。
概要はAWSの公式発表や各社のブログで明らかになっていますので、私は「今までと何が違うの?どうして嬉しいの?」にフォーカスして考えてみたいと思います。

参考
新機能 – トランジットゲートウェイでネットワークアーキテクチャをシンプルに
AWS Transit Gateway

できること

まず簡単に言うと、下記のようなネットワーク構成が可能になります。

今までとちがうところ

特にDirect Connect(以下、DX)をご利用の方向けに、以下にAWSサービスの変遷を記載します。

すごく以前(2017/10以前)

DXを引いたら、全てのVPCのVGWに対してVirtual Interface(以下、VIF)を紐づけなければいけませんでした。
そのたびにルータの管理をしている業者に作業を依頼しなければいけない場合もお客様によってはあったと思います。またルータの機種によっては再起動が必要とされ瞬断が起きたりしていました。
当然、VPC同士はVPC Peeringで相互に繋いでいなけば通信できません。

ちょっと以前(2017/11以降)

Direct Connect Gateway(以下、DXGW)がリリースされました。
各VPCに対してVIFを作らなくても、DXGWに対してVIFを紐づければ、あとはDXGWから各VPCに接続できるようになりました。
これでルータ管理をしているベンダへの作業依頼は不要です。
しかもリージョンをまたいで接続が可能になります。
ただし現在のところ、DXGWから接続できるのは同じAWSアカウントの中のVPCだけです。
またDXGWに紐づけられたVPC同士の通信もできません。
(すべてのVPC間で通信できるようにするにはVPC Peeringをフルメッシュで繋ぐ必要がありました)

AWS Transit Gateway以降(2018/12以降)

AWS Transit Gateway(以下、TGW)がリリースされました。
TGWに接続されているVPN、DXGW、VPC同士が相互に接続可能になります。
(残念ながら現在はVPCとVPNのみ。DXは来年対応予定)
内部に複数のルートテーブルを持ちVPCやVPNごとに関連付けを指定できるので、セグメント化が可能です。
(VPC01とVPC03は相互にアクセスさせたくない、といった制御が可能)

今後に期待

VPCがどんどん増えていき100, 200となったときにフルメッシュのVPC Peering運用はワークしません。
そもそもルートテーブルのルール数上限にひっかかるし、大変すぎます。(Peeringが n*(n-1)/2 の数になってしまいますからね。)
前述のように少ない労力で、かつ細かい制御が可能になった点が大きく違うということです。

残念ながら肝心の東京リージョンにはまだリリースされていませんが、Direct Connectへの対応と併せて、期待が高まります。

AWS運用自動化サービス「Cloud Automator」