AWSを利用している際にVPCやアカウント数が増えてきたり、「AWSと支店などの拠点間をVPN接続したい」となった際にTransit Gateway(以下TGW)を利用することがあると思います。 
TGWを利用する際にはAWS公式ドキュメント <a href="https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html" target="_blank" rel="nofollow noopener noreferrer">Transit gateway design best practices</a>を参考に設計/構築することになるかと思います。
AWS公式ドキュメントでは、TGWをアタッチする各サブネット内にTGWアタッチメント専用サブネット(/28など小さくてOK)を作成することがベストプラクティスとされています。
<blockquote>
AWS公式ドキュメント <a href="https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html" target="_blank" rel="nofollow noopener noreferrer">Transit gateway design best practices</a> 抜粋
<blockquote>
Use a separate subnet for each transit gateway VPC attachment. For each subnet, use a small CIDR, for example /28, so that you have more addresses for EC2 resources.
</blockquote>
</blockquote>
本記事では、TGWアタッチメント専用サブネットの必要性について図解していきます。
<h1 id="%E6%83%B3%E5%AE%9A%E8%AA%AD%E8%80%85">
<a class="header-anchor-link" href="#%E6%83%B3%E5%AE%9A%E8%AA%AD%E8%80%85" aria-hidden="true"></a> 想定読者</h1>
<ul>
<li>これからTGWを設計/構築する方</li>
<li>ルートテーブル, SG, NACLなど、AWSのネットワークに関する基本知識がある方</li>
<li>TGWアタッチメント専用サブネットがなぜ必要なのかよくわからない方</li>
</ul>
<h2 id="%E3%83%99%E3%82%B9%E3%83%88%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9%E3%81%AB%E6%B2%BF%E3%81%A3%E3%81%9F%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E8%A8%AD%E8%A8%88">
<a class="header-anchor-link" href="#%E3%83%99%E3%82%B9%E3%83%88%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9%E3%81%AB%E6%B2%BF%E3%81%A3%E3%81%9F%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E8%A8%AD%E8%A8%88" aria-hidden="true"></a> ベストプラクティスに沿ったネットワーク設計</h2>
まずは、以下のような要件があった際にハブとしてTGW利用した際のネットワーク図を例示します。
<ul>
<li>AWS〜オンプレの閉域接続が必要(DX接続)</li>
<li>North-South, East-West, インターネットへの全通信を監査(Inline Inspection VPC + Central Egress VPC)</li>
<li>複数拠点(支店)からSite-to-SiteのVPN接続でAWSへのアクセスを行いたい(TGW + VPN)</li>
</ul>
<h3 id="%E3%83%99%E3%82%B9%E3%83%88%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E5%9B%B3(%E4%BE%8B)">
<a class="header-anchor-link" href="#%E3%83%99%E3%82%B9%E3%83%88%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E5%9B%B3(%E4%BE%8B)" aria-hidden="true"></a> ベストプラクティスネットワーク図(例)</h3>
<img src="https://res.cloudinary.com/zenn/image/fetch/s--XRPG7njW--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_1200/https://storage.googleapis.com/zenn-user-upload/deployed-images/b455279eb34f519f2aaf31aa.png%3Fsha%3D80667ae83054bb45e75ecb2d081506b2a50dbd9a" alt loading="lazy" class="md-img"> 
補足
<ul>
<li>赤枠がベストプラクティスとされているTGWアタッチメント専用サブネット
</li>
<li>①〜⑦はSpoke VPC Aに配置されているEC2からインターネットへのOut-bound通信経路</li>
</ul>
※説明のために図を簡素に書いていますが、本来であれば少なくとも以下について追記および検討していく必要があります。
<ul>
<li><code>AZ冗長化</code></li>
<li><code>Spoke VPC A以外のSpoke VPC</code></li>
<li><code>Spoke VPC間の通信設計</code></li>
<li><code>ELBやDBなど、その他リソースのサブネットへの配置方法</code></li>
<li><code>VPCは一律/16で切って良いのか？</code></li>
<li><code>コンポーネント配置するサブネットは一律/24で切って良いのか？</code></li>
<li><code>DX冗長化はコスト的に高いので片方はSite-to-Site VPNとしておくか？</code></li>
<li>
<code>on-premisessとDXロケーションの回線を冗長化するか？</code> etc..</li>
</ul>
<h2 id="%E6%9C%AC%E9%A1%8C">
<a class="header-anchor-link" href="#%E6%9C%AC%E9%A1%8C" aria-hidden="true"></a> 本題</h2>
さて、TGWアタッチメント専用サブネットはなぜ必要なのでしょうか？ 
答えは、AWS Black Belt Online SeminarのQAに載っています。
<blockquote>
AWS Black Belt Online Seminar <a href="https://aws.amazon.com/jp/blogs/news/webinar-bb-aws-transit-gateway-2019/" target="_blank" rel="nofollow noopener noreferrer">AWS Transit Gateway 資料及び QA 公開</a> 抜粋
<blockquote>
Q. VPC をアタッチするときに指定するサブネットをアタッチ専用のサブネットとする必要性について、もう少し具体例を挙げて説明していただきたいです。そのサブネットの内部のEC2 インスタンスのルーティングに影響あるとのことでしたが、どのような影響があるのか？などを教えていただきたいです。
</blockquote>
<blockquote>
A. Transit Gateway (TGW) のアタッチメントがついているサブネットと同一のサブネットに EC2 インスタンスが存在する場合に、その EC2 インスタンスはTGWと同じルーティングテーブルを参照します。 
例えば　インライン監査用の VPC の TGW の ENI がある Subnet 上に EC2 インスタンスを設置してしまうと、その EC2 インスタンスは必ずインライン監査のミドルボックス ENI に吸い込まれてしまい、EC2 インスタンスの意図するルーティングテーブルを作れなくなってしまいます。こういったことを防ぐために、TGW 専用のサブネットを作ることをお薦めしています。 
<a href="https://www.slideshare.net/AmazonWebServicesJapan/20191113-aws-black-belt-online-seminar-aws-transit-gateway/40" target="_blank" rel="nofollow noopener noreferrer">こちら</a>および<a href="https://www.slideshare.net/AmazonWebServicesJapan/20191113-aws-black-belt-online-seminar-aws-transit-gateway/41" target="_blank" rel="nofollow noopener noreferrer">こちら</a>の資料を併せてご参照ください。
</blockquote>
</blockquote>
皆さんはこの文面を読んでパッと専用サブネットの必要性について理解できたでしょうか？ 
(私はなんとなく理解できましたが、、、いまいち腹落ちしなかったです。。)
しかし、バッドプラクティスネットワーク図を頭の中で思い浮かべ、ルートテーブルの意識 &amp; 通信の流れを意識することで腹落ちさせることができました。
<h3 id="%E3%83%90%E3%83%83%E3%83%89%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E5%9B%B3">
<a class="header-anchor-link" href="#%E3%83%90%E3%83%83%E3%83%89%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E5%9B%B3" aria-hidden="true"></a> バッドプラクティスネットワーク図</h3>
赤枠部分がベストプラクティスからの変更点です(TGWアタッチメント専用サブネットを廃止) 
一見すると、ベストプラクティスの時と同様に①〜⑦の通信は問題なく通っているように見えます。 
<img src="https://res.cloudinary.com/zenn/image/fetch/s--Tl6QILNs--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_1200/https://storage.googleapis.com/zenn-user-upload/deployed-images/efa9b301ca9d8888ae36d2da.png%3Fsha%3D87090b39065021d94f1b31f7cc4b91335c576c9d" alt loading="lazy" class="md-img">
QAを見返してみると以下の記述があります。
<blockquote>
AWS Black Belt Online Seminar <a href="https://aws.amazon.com/jp/blogs/news/webinar-bb-aws-transit-gateway-2019/" target="_blank" rel="nofollow noopener noreferrer">AWS Transit Gateway 資料及び QA 公開</a> 抜粋
<blockquote>
例えば　インライン監査用の VPC の TGW の ENI がある Subnet 上に EC2 インスタンスを設置してしまうと、(以下略)
</blockquote>
</blockquote>
インライン監査用のVPC（Inline Inspection VPC)にEC2を追加してみましょう（以下図赤枠に追加） 
<img src="https://res.cloudinary.com/zenn/image/fetch/s--UwDpY383--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_1200/https://storage.googleapis.com/zenn-user-upload/deployed-images/14cd577bf206cd09b0a7cf41.png%3Fsha%3D9b7255b1026fe5408365901c9dc75debe42f00b7" alt loading="lazy" class="md-img"> 
一見問題ないように見えるのですが、「インライン監査用VPCのEC2からSpoke VPC AのEC2への通信はインライン監査させずに直接通信させたい」などの要件(※)が出てきた場合に困ります。 
※例えば、コストや性能の問題でそのような要件が出てくる場合が考えられます
具体的には、インライン監査用VPC内のEC2は赤点線で囲ったNetwork Firewall Endpointへのルートテーブルを参照してしまいます。 
そのため、緑色①〜②の経路で通信させたい場合でも、オレンジ色①〜③の経路でSpoke VPC AのEC2へ通信がされてしまいます。 
結果としてインライン監査用VPCのTGWアタッチメントがあるサブネットにはEC2などのリソースが配置できず、IPアドレスが無駄に確保された状態となってしまいます。
<h2 id="%E3%81%BE%E3%81%A8%E3%82%81">
<a class="header-anchor-link" href="#%E3%81%BE%E3%81%A8%E3%82%81" aria-hidden="true"></a> まとめ</h2>
AWS Black Belt 公式QAにも「TGW 専用のサブネットを作ることをお薦め」との記載がある通り、あくまでお薦めという位置付けですが、/28という比較的小さなレンジでの専用サブネット確保ですので、「TGWアタッチメント専用サブネットがない場合の影響を理解しており、将来的な要件追加もない」などの状況でない場合には、TGWアタッチメント専用サブネットを作るのが良いと思います。
本記事を読んでいただいた皆様が「TGWアタッチメント専用サブネットの必要性」についての理解ができたなら幸いです。

[図解]TGWアタッチメント専用サブネットの必要性

ベストプラクティスネットワーク図(例)

ベストプラクティスに沿ったネットワーク設計

バッドプラクティスネットワーク図

Discussion