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 か所で管理して管理することが出来ます。
結論
- 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にて音声付きの解説がありますので、参考にしてください。
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からのトラフィックを許可しています。
この状態で、ec2-tgw1からの通信に絞るためsubnet-tgw-2にインバウンド192.168.0.0/16を許可するネットワークACLを設定したところ、EC2間での疎通が取れなくなりました。
今度は、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をフルオープンにすることがベストプラクティスとなっていることが分かりました。
許可するプレフィックスの制限に注意
TGW-DXGW接続をされる場合、許可するプレフィックスを設定する項目があり、こちらはAWS側からオンプレミスのルーターへーBGP広報するCIDRの値となります。 こちらの制限が２０個となり、以下の場合注意が必要です。
- CIDRが飛び飛びのVPCが複数存在し、CIDRをまとめることが出来ない
- AWSとオンプレミスで隣接したネットワークアドレスを設定しているため、AWS側でCIDRをまとめて広報することが出来ない
またこちらの値はVPCのCIDRから伝搬させる機能はないため、集約するVPCが増えBGP広報させたいCIDRが増えた場合、都度設定を反映させる必要があります。
TGW越しでセキュリティグループの参照は出来ない
VPC ピアリング越しでのセキュリティーグループ相互参照はサポートされていますが、TGW越しのセキュリティーグループ相互参照はサポートされておりません。 VPC ピアリングからTGWへ構成を移行したい方は注意してください。
まとめ
今回は、TGW構築におけるハマった所や注意点などを共有させていただきました。TGWはAWS構成が大きくなってからネットワークリソースを集約させたいという理由で採用される機会も多いですが、超えなければいけないハードルも様々あります。これからTGW化を検討されている方の参考になればと思います。
弊社ではTGW案件もかなり実績があり、技術ブログも多数ございます、よろしければご覧ください。
