AWS
DirectConnect
vpc
TransitGateway

Transit GatewayとDirect Connect GatewayとVPCの接続パターン


概要

先日のAWSアップデートで、Trainsit Gatewayが一部リージョンでDirect Connect(Gateway)に対応しました。

(2019/05/14時点では Tokyoリージョンはまだのようです)

それに伴い、Trangit GatewayとDirect Connect GatewayとVPCの組み合わせで、今後良く見られそうなパターンを書いてみました。


参考

クラスメソッドさんのblogを参考にしました

(構成や制限なども勉強になりました)

blog


ベース構成

image.png

基本は上図のようなパターンになると思います。

オンプレミス側のルータと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)

図で書くとこんな感じです。

image.png

結論から言うとこの接続は、可能です。

いくつか条件があり、そのほとんどは上記の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本持つパターン

image.png

Direct Connectの Connection(物理回線)は、文字通り物理回線なので、メンテナンスが発生したり・接続障害が発生したりする可能性があります。その影響を極力抑えるために、複数のtransit VIFを作成(冗長化のため、それぞれのtransit VIFは別のConnectionから作成する必要あり)する構成もあります。

図だと、同じDirect Connect Locationですが、Location自体の障害に対してもケアする必要があれば、以下のように、別のDirect Connect Locationを使うという方法もあります。

image.png

ただ、いずれのパターンも物理接続を2本以上持つことに変わりないので、お値段によって以下のVPNパターンもあるかと思います。


バックアップ回線はVPNパターン

物理回線は1本のみ。その回線にメンテナンスやトラブルが発生した場合は、バックアップとしてInternet VPNを利用するという方法もあるかと思います。

以下に2パターン記載しましたが、オンプレミス側のVPNの終端が、Direct Connect Location か オンプレミスDC(Office)かの違いですので、本質的には同じです。

通常時は、Direct Connectを優先経路にして、切断時にVPNへの自動切り替えを送る方法は、私自身は、試したことはないですし、オンプレミス側のNW設定によるので一概には言えませんが、従来どおり、Local Preferenceと ASPath prepend で制御する気がします

image.png

image.png


Direct Connect Gateway 単体との違い

Direct Connect Gateway 単体、つまり、Transit Gatewayを使わない構成でも、似たような構成は可能です。

こんな感じですね。

大きな違いがいくつかあります。全ては網羅しきれないですが、主要な箇所だけ。(思いつくたびに更新します)

image.png


マルチアカウント対応とその数の違い


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構成が複雑になるといった場合に、検討するものだと思います。