こんにちは！クラウドの広大な海を航海するエンジニアのみなさん、今日もパケットの行方に想いを馳せていますか？
AWSやGCPといったクラウドの世界に足を踏み入れると、必ずと言っていいほどぶつかる壁があります。それが「ネットワーク」です。特に、複数のシステム（VPC）が増えてきたときに、「インターネットへの出口を一つにまとめたいな……」と考えるのは、コストや管理の面で非常に賢い選択です。
今回は、AWSのTransit Gateway（トランジットゲートウェイ）という「巨大な交差点」を使って、複数のVPCのインターネット通信を一つのNATゲートウェイに集約する設計について、お話ししていきます。
「パケットってどうやって迷子にならずに帰ってくるの？」
「集約しすぎるとパンクしない？」
そんな疑問を、郵便配達の流れに例えて、一歩ずつ紐解いていきましょう！
—
1. NATゲートウェイは「マンションのコンシェルジュ」
まずはおさらいです。プライベートサブネット（外から直接見えない隠れ家のような場所）にあるサーバーが、外部のアプデ情報を取得するためにインターネットに出たいとき、NATゲートウェイが必要になります。
これを例えるなら、「住所を公開していないマンションの住民（サーバー）」が、「コンシェルジュ（NATゲートウェイ）」に手紙を託すようなものです。
1. 住民が手紙をコンシェルジュに渡す。
2. コンシェルジュが「マンションの代表住所」を差出人として書いて投函する。
3. 返事が来たら、コンシェルジュが「あ、これは〇〇号室の人の分だ」と判断して届けてくれる。
この仕組みのおかげで、外の世界に自分たちの部屋番号（プライベートIP）を明かさずに通信ができるわけですね。
—
2. なぜ出口を一つにまとめたいのか？
通常、VPCを作るたびにNATゲートウェイを設置すると、1つにつき月額で約30ドル以上（＋通信費）がかかります。VPCが10個あれば、それだけで毎月かなりの出費ですよね。
そこで登場するのが、Transit Gatewayです。これは、複数のVPCをガッチャンコと繋ぐ「巨大なハブ（交差点）」の役割を果たします。
「各VPCにコンシェルジュを置くのはもったいないから、中心にある大きな郵便局（検証用VPCなど）にあるコンシェルジュをみんなで使い回そう！」というのが、今回のNATゲートウェイ集約の狙いです。
—
3. Transit Gateway集約の設計図
構成はこんなイメージです。
- VPC A / VPC B: 自分の部屋（プライベートサブネット）。NATゲートウェイは持たない。
- Shared VPC（共有VPC）: 巨大なコンシェルジュ（NATゲートウェイ）が鎮座する場所。
- Transit Gateway: 全てのVPCを繋ぐ高速道路。
ここで重要なのは、「ルートテーブル（道案内図）」の設定です。
VPC A の道案内（Route Table）
「インターネット（0.0.0.0/0）に行きたいパケットは、まずTransit Gatewayへ向かってください」と指示を出します。
Transit Gateway の道案内（TGW Route Table）
「VPC Aから来たインターネット行きのパケットは、Shared VPCへ送ってください」と橋渡しをします。
Shared VPC の道案内（Route Table）
「届いたパケットは、この中にあるNATゲートウェイから外へ飛ばしてください」と出口を教えます。
—
4. 陥りやすい罠：非対称ルーティング（帰りの道がない！）
ここで初心者が一番ハマるのが、「行きはよいよい、帰りは恐い」という問題です。ネットワークの世界では、行きと帰りの道筋が同じである必要があります。
もし、パケットが帰ってくるときに「VPC Aの場所がわからない！」となってしまうと、通信は成立しません。
解決策：共有VPCにも「帰り道」を書く
Shared VPC内のサブネットにあるルートテーブルには、必ず以下の設定が必要です。
宛先: VPC A のネットワーク範囲 (例: 10.1.0.0/16)
ターゲット: Transit Gatewayこれを忘れると、NATゲートウェイまで戻ってきたパケットが「VPC Aってどこ？知らないから捨てちゃえ」と、ゴミ箱にポイされてしまいます。これが非対称ルーティングによる通信失敗の正体です。
—
5. スループットのボトルネックに注意！
「よし、これで全部のVPCを一つにまとめれば節約だ！」と意気込むのは素晴らしいですが、一つだけ注意点があります。それが「帯域（道路の幅）」です。
1. NATゲートウェイの限界: 基本的に5Gbps（最大100Gbpsまで自動拡張されますが、急激なスパイクには弱いことがあります）。
2. Transit Gatewayの限界: VPC1つあたりの接続（アタッチメント）は、通常最大50Gbpsです。
あまりにも多くのVPCから巨大なファイルを同時にダウンロードしようとすると、この共有されたNATゲートウェイが「もう無理！」と悲鳴を上げてしまいます。「節約とパフォーマンスはトレードオフ」であることを覚えておきましょう。
—
6. 実践！ルートテーブルの設定サンプル
それでは、実際にAWS CLIやコンソールで設定する際のイメージをコードで見てみましょう。
1. 利用者側（VPC A）のルート設定
「外の世界へは交差点（TGW）を通ってね」という設定です。
# VPC Aのプライベートサブネットのルートテーブルに、デフォルトルートを追加
aws ec2 create-route \
--route-table-id rtb-vpc-a-private \
--destination-cidr-block 0.0.0.0/0 \
--transit-gateway-id tgw-xxxxxxxxxxxxxxxxx # Transit GatewayのIDを指定2. 共有VPC側のルート設定（ここが重要！）
「外から戻ってきたパケットは、交差点（TGW）へ戻してね」という設定です。
# Shared VPCのNATゲートウェイがあるサブネットのルートテーブル
# VPC A宛の通信をTransit Gatewayへ戻す設定
aws ec2 create-route \
--route-table-id rtb-shared-nat-public \
--destination-cidr-block 10.1.0.0/16 \ # VPC Aのネットワーク範囲
--transit-gateway-id tgw-xxxxxxxxxxxxxxxxx—
まとめ：一歩ずつ「パケットの旅」を想像しよう
NATゲートウェイの集約は、コスト削減の特効薬ですが、ネットワークの基本である「行きと帰りのルート」をしっかり設計しないと、トラブルシューティングの迷宮に迷い込んでしまいます。
難しい用語が出てきても、「パケットという名の郵便物が、どの交差点を通って、どの窓口で切手を貼り替えられるのか」を想像してみてください。そうすれば、きっと複雑なクラウドネットワークもあなたの味方になってくれるはずです。
もし構築中に「つながらないな？」と思ったら、まずは「帰り道の設定、忘れてないかな？」と自分に問いかけてみてくださいね。
一歩ずつ、楽しみながらインフラをマスターしていきましょう！応援しています！
コメント