AWS Transit GatewayとDirect ConnectのマルチAWSアカウント構成

技術三課の杉村です。2019年9月、AWS Transit GatewayでDirect Connect Gatewayを利用できる機能が発表されました。 待望のアップデートです。 AWS Direct Connect の AWS Transit Gatewayサポートが東京リージョンに対応しました

このアップデートにより、AWS Transit Gatewayをハブとして、オンプレミスとマルチアカウントのAWS環境をより簡単に専用線で接続できるようになりました。 構成の特徴や注意点を解説します。

1. 構成イメージ図

上記のような構成図の構成が可能になります。

従来まで（本アップデートの登場まで）

従来までは、複数のAWSアカウントに Direct Connect を引こうと考えた場合、2つの方法がありました。

1. 各AWSアカウントにVirtual Interfaceを作成する => オンプレ側ルータの設定変更が必要
2. Direct Connect Gatewayのマルチアカウントサポートを利用する => ルータ設定変更は不要だがVPC間の通信は不可（ハブにならない）

これから

今回の構成、つまりTransit GatewayのDirect Connect Gateway利用では、以下のメリットがあります。

• AWS側の操作だけで複数のAWSアカウントにDirect Connectを伸ばせる
• Transit Gatewayをハブにして「VPC」「オンプレ（VPN）」「オンプレ（Direct Connect）」間の通信ができる
• Transit GatewayのRoute Tableで前述の通信の制御を細かく設定できる

なおTransit GatewayとVPCを紐づける際は "Transit Gateway Attachment" という関係リソースを、VPCが存在する各AWSアカウントに作成することになります。 ルーティングの制御は各AttachmentにTransit Gateway Route Tableを紐づけることになりますが、それができるのはTransit Gateway本体を作成したアカウントからのみになります。

つまり、中央AWSアカウントでルーティングの制御が集約できる一方、各AWSアカウントの管理者にDelegationするような運用は現状できません。

2. 前提条件

この構成にするには、以下の前提条件をクリアしている必要があります。

• 1. 接続する全てのVPCが同一リージョンにある
• 1. Transit Gatewayが利用できるAvailability Zoneでの利用である（古いAZではない）
• （補足）同じOrganizationsに所属している必要はない

A. 接続する全てのVPCは同一リージョンにあること

Transit Gatewayではリージョンをまたいだアタッチメント(VPC, VPN, Direct Connect Gateway)作成はできません。

ただし、その手前のDirect Connect Gatewayはリージョン間で利用ができます。つまりオンプレからDirect Connect Gatewayまで来て、そこで分岐して各リージョンごとのTransit Gatewayに繋ぐような構成は可能です。 ただし、この構成の場合は異なるリージョン間のVPCで通信はできませんため、ご注意ください。（あくまでオンプレイス～各リージョンのVPC間で通信が可能になる） つまりは現在、Transit Gatewayで実現できるのはリージョン内通信のみです。

2019/12のアップデートにて、別リージョンにあるTransit Gateway同士を接続することができるようになりました。 リージョンごとにTransit Gatewayを構築し、Transit Gateway同士を繋げることで、リージョン間通信が可能です。 AWS Transit Gatewayにマルチキャストとインターリージョンピアリング機能を追加 Transit Gatewayには同一リージョンにあるVPCだけしか接続できない、という点は変わりません。 また、関連ブログへのリンクを本ページの末尾に記載しています。

B. Transit Gatewayが利用できるAvailability Zoneでの利用であること（古いAZではないこと）

Transit Gatewayの制約として、古いAZではTransit Gatewayが利用できません。 東京リージョンでいえば多くのAWSアカウントで「ap-northeast-b」として認識されるapne1-az3が該当します。 別のAZでTransit GatewayのAttachmentを作ってもだめです。 なぜならTransit Gatewayを通じて通信するリソース（EC2やRDS等）のあるすべてのAZと、Transit Gatewayが紐づけられている必要があるからです。（後述） この東京リージョンの旧AZは現在では利用できなくなっていますが、古くからAWSをご利用のAWSアカウントでは、既存リソースが残っている可能性がありますのでご注意ください。 東京リージョンの旧AZ（apne1-az3)の制約に関しては、弊社の渡辺が書いたブログを参考に載せておきます。 旧AZ(apne1-az3)でできないこと

（補足）同じOrganizationに所属している必要はない

Transit Gatewayを複数AWSアカウントで共有するにはAWS Resource Access Manager（以下、AWS RAM）を利用します。 What Is AWS RAM? AWS RAMは異なるAWSアカウント間でAWSリソースを共有するAWSサービスです。 同一Organization内でリソース共有をする設定なども可能ですが、Transit Gatewayに関しては、シェアするAWSアカウントが同一Organiztionに所属している必要はありません。

※1 ※2 ※1 Direct Connect Gatewayをアカウント間共有する際はかつては同一Organization（同一Payer ID）である必要がありましたが、その制限は緩和されました(AWS Direct Connect Announces the Support for Granular Cost Allocation and Removal of Payer ID Restriction for Direct Connect Gateway Association.)。 Transit Gatewayではもともと心配する必要はありません。

※2 AWS RAMを用いてAWSアカウント間でリソースを共有する場合、同じOrganizationに所属している必要があるリソースもあります。例えば Subnet の共有（VPC Sharing, Shared VPC）を利用するにはAWSアカウントが同じOrganizationである必要があります（かつ"全ての機能が有効化"されている必要あり）。Transit Gatewayはそうではありません

3. 注意事項

以下の注意事項に十分ご注意ください。

• 1. 既にDirect Connect(あるいはDirect Connect Gateway)を利用している場合でもTransit Virtual Interfaceの作成が必要
• 1. æ—§AZではTransit Gatewayが使えない、旧AZにあるEC2等のリソースとも通信できない
• 1. 通信先のVPCリソースが存在する全てのAZのサブネットとTransit Gateway Attachmentを紐づけること

A. 既存のDirect Connect(あるいはDirect Connect Gateway)がある場合でもTransit Virtual Interfaceの作成が必要

既にDirect Connect Gatewayをご利用頂いている場合でも、既存のPrivate Virtual InterfaceをTransit Gatewayに利用することはできません。 Virtual Interfaceには "Public" "Private" "Transit" の3種類があり、このうちTransitという種類のVirtual Interfaceを利用する必要があります。 既存Direct Connect構成からTransit Gateway構成に切り替える際は、最初にこのTransit Virtual Interfaceを作成するという作業が必要です。 このときにオンプレ側ルータの設定追加、およびそちらへの経路切替も必要ですので、注意しましょう。

B. 旧AZではTransit Gatewayが使えない、旧AZにあるEC2等のリソースとも通信できない

前述の通りです。 現在ではこの旧AZは利用できないため、最近AWSアカウントを開設された方は問題ありませんが、古くからAWSをご利用のAWSアカウントでは、既存のリソースが残っている可能性がありますのでご注意ください。 旧AZのリソースと通信させたい場合は、従来通りにVPC PeeringやVirtual Private Gateway(VGW)を残しておく必要があるため、混在の構成となる場合は注意深く設計する必要があります。

C. 通信先のVPCリソースが存在する全てのAZのサブネットとTransit Gateway Attachmentを紐づけること

Transit GatewayとVPCを紐づける際は "Transit Gateway Attachment" という関係リソースを作成します。 Transit Gateway Attachment作成の際には、どのサブネットと紐づけるかを選択します。各AZで1つのサブネットが選択できます。 このとき「VPCの中のどれか一つのAZのサブネットとTransit Gateway Attachmentが紐づいていればいい」のではなく「通信させるリソースが存在する全てのAZのサブネットとTransit Gateway Attachmentを紐づける」必要があります。

例えばTransit Gateway AttachmentがAZ-1aのサブネットとだけ紐づいているとします。 この状態でAZ-1cにあるEC2には、Transit Gateway経由では通信できません。 この状態でAZ-1cのサブネットのルートテーブルからTransit Gatewayに対してルートを向けても、通信することができないのです。 AZ-1cのサブネットにも、紐づける必要があります。 なおTransit Gateway Attachmentが紐づいたサブネットにはTransit GatewayのENIが複数作成されPrivate IPアドレスが消費されるので注意が必要です。

4. さいごに

Transit Gatewayを利用することで、VPC-オンプレ間の詳細な経路制御をTransit Gatewayに集約することができます。 また、かつてはDirect Connectを複数AWSアカウントに引こうとするとオンプレルータの設定変更など手間が生じていましたが、Transit Gatewayを利用することでAWS上の操作で実現することができます。 （Direct Connect Gatewayでも実現できましたが、Transit Gatewayにすることでより詳細に経路を制御したり、VPC間通信が実現できたりする） ご参考にお願いいたします。

＜追記＞2019年12月に、Transit Gatewayがマルチリージョンピアリングに対応しました。下記のブログをご参照ください。 Transit Gatewayで実現するマルチリージョン構成・マルチアカウント構成

杉村 勇馬 (記事一覧)

サーバーワークス → 株式会社G-gen 執行役員CTO

2021 Japan APN Ambassadors / 2021 APN All AWS Certifications Engineers

マルチAWSアカウント管理運用やネットワーク関係のAWSサービスに関するブログ記事を過去に執筆。

2021年09月から株式会社G-genに出向、Google Cloud(GCP)が専門に。G-genでもGoogle Cloud (GCP) の技術ブログを執筆中。