AWS Transit Gatewayを構築して分かったこと・ベストプラクティスを紐解く

CI部SRE2課の松井（紀）です。

AWS Transit Gateway（以下TGW）を構築する際に行った検証や注意点、ベストプラクティスに記載されている内容の深堀りをします。

はじめに
結論
Transit Gateway VPC attachment は専用のサブネットで作る
ネットワーク ACLはフルオープンにする
- 技術検証
許可するプレフィックスの制限に注意
TGW越しでセキュリティグループの参照は出来ない
まとめ

はじめに

簡単にTGWについて解説します。

AWS Transit Gateway は、中央ハブを介して VPC とオンプレミスネットワークを接続します。これにより、ネットワークが簡素化され、複雑なピア接続関係がなくなります。クラウドルーターとして機能 – 新しい接続はそれぞれ 1 回だけ行われます。
https://aws.amazon.com/jp/transit-gateway/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc

TGWを使うことで、各VPCをそれぞれVPC ピアリングでつなぐ必要がなくなり、1 か所で管理して管理することが出来ます。

f:id:swx-toshiki-matsui:20220207121742p:plain

結論

transit gateway VPC attachment は専用のサブネットで作る
ネットワーク ACLはフルオープンにする
Direct Connect Gatewayを関連付ける際は許可するプレフィックスの制限に注意
AWS Transit Gateway間でセキュリティグループの参照は出来ない

一つずつ解説していきます

Transit Gateway VPC attachment は専用のサブネットで作る

設計のベストプラクティスに以下記載があります。

各 Transit Gateway VPC アタッチメントに個別のサブネットを使用します。各サブネットに対して、小さな CIDR (/28 など) を使用して、EC2 リソースのアドレスが増えるようにします。
https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-best-design-practices.html

理由は、Transit Gateway Attachment が存在するサブネットにEC2やコンテナのENIがあると、そのリソースはTransit Gateway RouteTableと同じルートを参照してしまうからです。仮にTGWを経由させたくないEC2がTransit Gateway VPC attachmentと同じサブネットに存在していた場合、意図しない方向へ通信が行われてしまうことがあります。

AWS Black Belt Online Seminarにて音声付きの解説がありますので、参考にしてください。

youtu.be

Transit Gateway Attachment、Transit Gateway RouteTableの詳しい解説は下記ブログを参照ください。

https://blog.serverworks.co.jp/tech/2020/06/30/transit-gateway-routing/

ネットワーク ACLはフルオープンにする

設計のベストプラクティスに以下記載があります。

ネットワーク ACL を 1 つ作成し、Transit Gateway に関連付けられたすべてのサブネットに関連付けます。ネットワーク ACL は、インバウンド方向とアウトバウンド方向の両方で開いたままにします
https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-best-design-practices.html

なぜ、Transit Gateway に関連付けられたすべてのサブネットにはネットワークACLを用いた制御が推奨されていないのでしょうか、検証してみました。

技術検証

VPCにそれぞれ１つのサブネットのEC2とTransit Gateway VPC attachmentを構築しました。セキュリティーグループは各EC2からのトラフィックを許可しています。

f:id:swx-toshiki-matsui:20220208090044p:plain この状態で、ec2-tgw1からの通信に絞るためsubnet-tgw-2にインバウンド192.168.0.0/16を許可するネットワークACLを設定したところ、EC2間での疎通が取れなくなりました。

f:id:swx-toshiki-matsui:20220207155215p:plain 今度は、Transit Gateway VPC attachmentとEC2のサブネットを分けてsubnet2-tgw-2へ同様にインバウンド192.168.0.0/16を許可するネットワークACLを設定したところ、EC2間での疎通が取れるようになりました。
Transit Gateway VPC attachmentと通信したいリソースが同じサブネットに存在していると、ネットワークACLで意図した制御が出来ないことが分かります。

VPCフローログで通信がどのように処理されているか確認してみました。 attach-tgw2には以下のように記述されていました。

eni-xxxxxxxxxxxx 172.16.2.140 172.16.1.195 0 0 1 29 2436 1644196286 1644196315 REJECT OK

Transit Gateway VPC attachmentは送信元をec2-tgw1(192.168.1.42)ではなく自身のENIのCIDR（172.16.2.140）からのパケットと判断しネットワークACLの制御に基づきREJECTしています。
送信元CIDRが正しく判断出来ないため、Transit Gateway VPC attachmentのサブネットではネットワーク ACLをフルオープンにすることがベストプラクティスとなっていることが分かりました。