概要
先日のAWSアップデートで、Trainsit Gatewayが一部リージョンでDirect Connect(Gateway)に対応しました。
(2019/05/14時点では Tokyoリージョンはまだのようです)
それに伴い、Trangit GatewayとDirect Connect GatewayとVPCの組み合わせで、今後良く見られそうなパターンを書いてみました。
参考
クラスメソッドさんのblogを参考にしました
(構成や制限なども勉強になりました)
blog
#ベース構成
基本は上図のようなパターンになると思います。
オンプレミス側のルータとBGPで接続するのは、Direct Connect Gatewayになります。
Direct Connect Gateway と Transit Gateway の接続は、マネジメントコンソールからポチポチで完了できます。
Transit Gatewayには、数千を超えるVPCを接続することが可能です。(図ではスペースの関係上、3つのみ接続しています) こちらもマネジメントコンソールからポチポチで完了できます。
マルチアカウントパターン
上図の構成を全て1つのAWSアカウントでやることはそれほど多くないかと思います。
つまり、以下のようにアカウントが細かく分かれている可能性があります
Direct Connectの物理回線を持っているアカウント(Account 1)
Direct Connect GatewayとDirect Connect GatwayにアタッチするVIFを持っているアカウント(Account 2)
Transit Gatewayを持っているアカウント(Account 3)
VPCを持っているアカウント(Account 4,5,6)
図で書くとこんな感じです。
結論から言うとこの接続は、可能です。
いくつか条件があり、そのほとんどは上記のblogに書いてありますが、現時点で記載のない条件だと
Direct Connect Gateway(Account 2) と Transit Gateway(Account 3)は同じ、AWS Organizationsに入ってる必要があります。
ただ、マスターアカウント(支払いアカウント, Payerアカウント)である必要はないので、例えば、Account 2 と Account 3 がそれぞれリセラーから払い出されたアカウントでも、マスターアカウントが同じあれば、上図の構成は可能です。
また、Transit Gateway(Account 3) と VPC(Account 4~)は、Organizationsに所属しているかどうかに関係なく、Transit Gatewayの別アカウントへの共有機能を使うことにより可能です。
長くなりましたが、つまりは、Account 2 と Account 3 が同じOrganizationsに所属してさえ入れば、
上図のような極端なマルチアカウントは可能です。
冗長化パターン
Transit VIFを2本持つパターン
Direct Connectの Connection(物理回線)は、文字通り物理回線なので、メンテナンスが発生したり・接続障害が発生したりする可能性があります。その影響を極力抑えるために、複数のtransit VIFを作成(冗長化のため、それぞれのtransit VIFは別のConnectionから作成する必要あり)する構成もあります。
図だと、同じDirect Connect Locationですが、Location自体の障害に対してもケアする必要があれば、以下のように、別のDirect Connect Locationを使うという方法もあります。
ただ、いずれのパターンも物理接続を2本以上持つことに変わりないので、お値段によって以下のVPNパターンもあるかと思います。
バックアップ回線はVPNパターン
物理回線は1本のみ。その回線にメンテナンスやトラブルが発生した場合は、バックアップとしてInternet VPNを利用するという方法もあるかと思います。
以下に2パターン記載しましたが、オンプレミス側のVPNの終端が、Direct Connect Location か オンプレミスDC(Office)かの違いですので、本質的には同じです。
通常時は、Direct Connectを優先経路にして、切断時にVPNへの自動切り替えを送る方法は、私自身は、試したことはないですし、オンプレミス側のNW設定によるので一概には言えませんが、従来どおり、Local Preferenceと ASPath prepend で制御する気がします
Direct Connect Gateway 単体との違い
Direct Connect Gateway 単体、つまり、Transit Gatewayを使わない構成でも、似たような構成は可能です。
こんな感じですね。
大きな違いがいくつかあります。全ては網羅しきれないですが、主要な箇所だけ。(思いつくたびに更新します)
マルチアカウント対応とその数の違い
Direct Connect Gatewayのみの場合
Direct Connect Gatewayもマルチアカウント対応。つまり、Direct Connect Gatewayとそれに接続するVPCは別のAWSアカウントでもOKです。ただし、同じ AWS Organizationsに属している必要があり、かつ、1つのDirect Connect Gatewayに接続できるVPCは10つまでになります。
Transit Gatewayも使う場合
Transit Gatewayは、Organizationsに関係なく別アカウントに共有でき、かつ、接続可能なVPCの数は数千以上です。
バックアップ回線としてVPNを張る場合
Direct Connect Gatewayのみの場合
Direct Connect GatewayにはVPNを終端する機能がないので、Site-to-Site VPNが必要な場合は、各VPCとVPNを張る必要があります。つまり、VPCが10個あれば、VPNも10本必要です。
Transit Gatewayも使う場合
Transit Gatewayは、VPNも終端できるため、パフォーマンスは別にして、VPCがいくつあっても、VPNは1本でOKです。
リージョンまたぎの接続
Direct Connect Gatewayのみの場合
Direct Connect Gateway はグローバルサービスのため、Direct Connect Gatewayと接続するVPCは、東京だったり、オレゴンだったり、シンガポールだったり、リージョンをまたぐことが可能です（中国リージョンは除く)
Transit Gatewayも使う場合
Transit Gatewayは、リージョンサービスのため、現時点では、Transit Gatewayに接続するVPCは必ず同じリージョンである必要があります。
最後に
Transit Gatewayは便利ですが、かなり高等なNWスキルが要求されるので、Transit Gatewayを使わないと必要な要件を満たすことができない or 使わないと逆にNW構成が複雑になるといった場合に、検討するものだと思います。