Transit GatewayとRAMでマルチアカウントVPCを接続させてみた
はじめに
こんにちは。コンサルティング部の津谷です。
みなさんは、Transit Gatewayを使って、AWSとオンプレミス環境を接続したことはありますでしょうか。DirectConnectを使った専用線での接続も選択肢としてありますが、複数のAWS環境、複数のオンプレミス環境を相互接続するにはTransit Gatewayをつかって拡張性をあげるとよいかと思います。
検証の前に、なぜTransit Gatewayを使うとよいのかを簡単に調査してみます。
TransitGatewayを使うメリット
Direct Connectは専用線を直接AWS環境とオンプレ環境の中に敷設することで、高可用かつ、広帯域の通信を実現します。しかし、システム数が増え、環境をシステムごとに切るような場合、すべてDirectConnectで賄うのは大変です。（専用線を敷くので、お金も時間もかかる）
また、専用線を敷設した場合、接続のハブとしてDirectConnect Gatewayを利用しますが、こちらは各ネットワークを最大20までしかサポートしておらず、それ以上のシステム間接続は難しいです。
そのため、DirectConnectやSite to Site VPNで接続した数多くのシステムを双方向に接続するには中間にハブを用意することで管理しやすくなります。この中間ハブの役割を担うのがTransit Gatewayになります。
Transit GatewayはVPC間の直接接続も可能ですが、Direct Connect GatewayやVPN Gateway（Customer Gateway）との接続もサポートしており、システム間はTransit Gateway Attchmentを介して通信を実装します。
公式情報をご参照ください。
構成図
今回の検証構成図は下記のようになります。
異なるアカウント間のVPCをTransit Gatewayでつないでみようと思います。
VPC２つだけだったら、VPCPeeringでもよいのですが、今後のシステムスケールに合わせてTransit Gatewayを採用するという設定です。ちなみに、VPC Peeringはハブアンドスポーク構成は取れません。
今回はアカウントAをHubアカウントとし、アカウントBをSpokeアカウントとします。アカウントAで作成したTransit GatewayをResource Access Managerで共有し、アカウントＢでも利用できるようにします。Gatewayへ通信するためには、必ず同一VPC内にあるAttachmentを経由して通信する必要があります。そのため、Attachmentは各アカウントに作成いたします。
プライベートな通信を行うので、疎通確認用のEC2にはSSMエージェント経由でログインを行い、Pingで別アカウントのEC2にパケットが届くか確認してみます。
構築してみた
事前準備として下記は作成しておきましょう。
-
アカウントA
①VPC：10.1.0.0/16（名前はhub-vpc)
②EC2用サブネット：10.1.1.0/24（名前はhub-ec2-subnet)
③TGW用サブネット：10.1.2.0/24（名前はhub-tgw-subnet)
④NACL：デフォルトのものを利用（インバウンド・アウトバウンドそれぞれ0.0.0.0/24)
⑤EC2用SG（名前はhub-sg-ec2)
アウトバウンド：アカウントBのEC2へのICMPv4接続、SSＭ接続するのでエンドポイントへのHTTPS接続
⑥SSMエンドポイント用SG（名前はhub-sg-endpoint)
インバウンド：EC2からのHTTPS接続
⑦SSMエンドポイント
・ssmmessage(名前はhub-endpoint-ssm)
・ssm（名前はhub-endopoint-ssmmessage)
・ec2message（名前はhub-endpoint-ec2message)
⑧SSM接続用のIAMロール（名前はtest-ec2-role)
EC2に下記の管理ポリシーを付与する
・SSMManagerdInstanceCore -
アカウントB
①VPC：10.2.0.0/16（名前はspoke-vpc)
②EC2用サブネット：10.2.1.0/24（名前はspoke-ec2-subnet)
③TGW用サブネット：10.2.2.0/24（名前はspoke-tgw-subnet)
④NACL：デフォルトのものを利用（インバウンド・アウトバウンドそれぞれ0.0.0.0/24)
⑤EC2用SG（名前はspoke-sg-ec2)
インバウンド：アカウントAのEC2からのICMPv4接続
準備ができたら、実際にTransit Gatewayの構築に進みます。
アカウントA側でTransitGatewayの本体を作成します。
名前は「hub-tgw」とします。自立システム番号は空欄で作成すると、デフォルトの「64512」が適用されます。こちらのASはBGPルーティングで異なるネットワークの機器間で経路情報を伝搬してくれます。単にVPC間接続の場合は、BGPは利用せず、VPC側からTransit Gatewayへの静的ルートを追加することで通信が可能になります。（こちらは後ほど設定します）
公式情報もご確認ください。
BGPやASに関してはこちらの記事も大変勉強になります。
【チェック項目の補足】
・DNSサポートは異なるVPCへの名前解決が必要な場合設定しますが、今回の場合はPingで疎通確認するだけなので、必須ではありません。
・異なるVPCのセキュリティグループ名を設定参照する場合は有効化します。今回はCIDRで指定するので、必須ではないです。
・ECMP(Equal Cost Multi Path）は、単にVPC間接続の場合は必須ではありません。接続経路が冗長化されている場合は、冗長経路で負荷分散を自動的に行う設定になります。
・デフォルトのルートテーブルと伝搬は有効化しておきます。自動でルートテーブルを作成し、関連付けられるのと、伝搬することで各VPCへのルーティング情報を自動で登録してくれます。
・データの複数同時配信なども行わないので、マルチキャストも無効化で問題ないです。
・クロスアカウント共有は、RAMで共有したTGWを基に、アカウントB側でアタッチメント作成をした場合、アカウントA側での承認が必要になります。この承認プロセスを省略できるというものになります。今回は承認プロセス含めてTGWの機能を確かめるために無効化しておきます。
次に、アカウントA側でアタッチメントを作成していきます。
名前は「hub-tgw-attachment」とし、事前作成したサブネット「hub-tgw-subnet」に配置します。
作成が完了したら、アカウントBにRAMでTGWを共有していきます。
名前は「tgw-ram」にします。共有対象のリソースとしてTransit Gatewayを指定し、作成したIDを選択します。
共有されたTransit Gatewayで実行可能なアクションが指定されていますね。アカウントB側でもこのTransit Gatewayを指定してアタッチメントの作成が可能なことがわかります。
共有先のアカウント番号（今回はアカウントBの番号）を記載します。
RAMの作成後、リソースへの招待をアカウントB側で受けているので、承諾しましょう。
次にアカウントB側で同様にアタッチメントを作成しましょう。
名前は「spoke-tgw-attachment」とし、事前作成した「spoke-tgw-subnet」に配置しましょう。
これだけでは作成にならないので、注意が必要です。
Transit Gatewayの本体はアカウント側になるので、アタッチメントの作成を承諾する必要があります。
承諾が完了するとステータスが「pending」から「active」になります。
最後に、EC2が配置されているサブネットのルートテーブルを編集していきます。現時点では、各アカウントのTransitGateway Attachment間のルートは伝搬されていますが、EC2からTransit Gatewayへのルートは実装されていません。
上記のように、ターゲットとしてTransit Gatewayを指定して通信先のVPC CIDRを指定してあげましょう。
*省略しますが、アカウントB側でも同様の設定をしてください。
こちらで構築準備は完了になります。
動作確認
実際に、アカウントAのEC2にセッションマネージャー経由でログインしてみます。
以下のコマンドを打つと、
ping [アカウントBのEC2プライベートIP]
Pingが帰ってきているのがわかりますね。しっかり、マルチアカウントのVPCにも通信が成功しました。
最後に
今回は、Transit GatewayをRAM共有して、異なるアカウント間の通信をやってみました。VPC Peeringで限界がある複数VPC間の双方向接続や、Direct Connectでは、接続数に限界がある場合、VPNなどの複数経路で接続を行う場合の中継HubとしてうまくTransit Gatewayを活用したいですね。
皆さんもぜひ、構築してみてください。
