こんにちは！クラウドインフラの世界へようこそ。SREとして日々さまざまなシステムの裏側を支えていると、「あれ？通信の向き先が想定と違うぞ…」というネットワークのミステリーに直面することがあります。
AWSなどのクラウドを使っていると、プライベートサブネットに置いたサーバーから「外のインターネットに出たい！」というときや、「別のVPCにあるデータベースと通信したい！」という要望が同時に出てきますよね。
ここで避けて通れないのが、「どの道を通るのが一番優先されるのか？」というルーティング（道案内）のルールです。今回は、パケットの気持ちになりながら、このルート競合の仕組みを優しく紐解いていきましょう！
—
1. 身近な例えでイメージしよう：郵便配達のルール
ネットワークのルーティングを理解するために、ちょっと身の回りの「手紙や荷物を送る仕組み」に例えてみましょう。
あなたが東京のオフィス（プライベートサブネット）から、荷物を送るとします。
宛先には大きく分けて、次の2パターンがありますよね。
1. お隣の部署（社内便）へ送る荷物
- 同じ会社の別フロアや、グループ会社宛てです。
2. 遠くの街（インターネット）へ送る荷物
- 全く関係のない一般企業や海外のWebサイト宛てです。
もしあなたが手紙を書くとき、宛先が「お隣の部署」であれば、社内便の専用ルートを使いますよね。わざわざ遠くの街へ行く一般の郵便ポスト（NATゲートウェイ）には出しません。
AWSのネットワークでも全く同じことが起きるんです。「ここへ行きたい！」という宛先（IPアドレス）が複数あるとき、AWSのルーターは「よりピンポイントで場所を知っている道（具体的なルート）」を優先して選ぶという、とても賢いルールを持っています。
—
2. ルートテーブルの主役たち：NAT GatewayとTGW/VPCピアリング
まずは、今回登場する主要なプレイヤーたちを顔見知りになっておきましょう。
- NATゲートウェイ (
0.0.0.0/0向け) - プライベートサブネットからインターネットの海へ飛び出すための「大きな総合窓口」です。どこ宛てか分からない通信は、とりあえずここに丸投げすれば、いい感じにインターネットへ連れていってくれます。
- VPCピアリング / AWS Transit Gateway (TGW)
- VPC同士（お隣のネットワーク同士）を繋ぐための「専用道路」や「高速道路のジャンクション」です。特定のプライベートIPアドレスの範囲（例:
10.100.0.0/16など）へダイレクトに通信を流すために使います。
ここで、インフラ初心者のエンジニアがよくハマる疑問が生まれます。
「プライベートサブネットのルートテーブルに、VPCピアリング向けのルートと、NATゲートウェイ向けのデフォルトルート (0.0.0.0/0) の両方を登録したら、通信はどっちを優先するの？」 という疑問です。
一歩ずつ、その答えに近づいていきましょう！
—
3. 評価の仕組み：最も「具体的」な住所が勝つ！
AWSのルートテーブル（道案内図）がパケットをさばくとき、基本原則は「最長一致（ロンゲスト・プレフィックス・マッチ）」という、ちょっとかっこいい名前のルールに従います。
難しく聞こえますが、要するに「より狭くて詳しい住所が優先される」ということです。
たとえば、次の2つのルートがルートテーブルに書かれていたとします。
1. 10.1.0.0/16 （VPCピアリングやTGWを通るルート）
2. 0.0.0.0/0 （NATゲートウェイを通るデフォルトルート）
ここで、パケット（手紙）の宛先が 10.1.5.5 だったとしましょう。
- ルート1の
10.1.0.0/16は、10.1.0.0から10.1.255.255までをカバーする「大きな街（エリア）」です。 - ルート2の
0.0.0.0/0は、すべてのIPアドレス（地球上の全住所）を意味する「とりあえず全部」です。
パケットが届いたとき、AWSは「よりピンポイントで場所を知っているのはどっちだ？」と探します。すると、10.1.5.5 は 10.1.0.0/16 という「街」の中に綺麗にスッポリ収まるため、NATゲートウェイ（0.0.0.0/0）ではなく、VPCピアリングやTransit Gatewayの道が選ばれることになるのです！
安全ですね。お隣の部署宛ての荷物は、ちゃんと社内便ルートを通って届くようになっています。
—
4. 実務で役立つ！ルートテーブル設定の実例
それでは、実際にAWSのインフラを構築する際のCloudFormationやTerraform、あるいはAWS CLIをイメージした設定例を見てみましょう。
今回は、プライベートサブネットから「特定のVPC（10.50.0.0/16）」へはTGW経由で通信させつつ、それ以外のインターネット行きは「NATゲートウェイ」に流す設定を想定します。
{
"RouteTable": {
"VpcId": "vpc-0123456789abcdef0",
"Routes": [
{
"DestinationCidrBlock": "10.50.0.0/16",
"TransitGatewayId": "tgw-0987654321fedcba0",
"Description": "社内の別VPC（TGW経由）へ向かうピンポイントなルート"
},
{
"DestinationCidrBlock": "0.0.0.0/0",
"NatGatewayId": "nat-0123456789abcdef0",
"Description": "宛先が分からないすべての通信を流すNATゲートウェイ向けのデフォルトルート"
}
]
}
}この設定におけるパケットの挙動
- 宛先が
10.50.10.20の場合： 10.50.0.0/16のルールに一致するため、AWS Transit Gateway を通って別VPCへ向かいます。- 宛先が
8.8.8.8（GoogleのパブリックDNSなど）の場合： 10.50.0.0/16には一致しませんが、すべての宛先をカバーする0.0.0.0/0に一致するため、NATゲートウェイを経由してインターネットへ出ていきます。
このように、具体的なルートと全方向のルートが共存していても、AWSは意図した通りに賢く交通整理を行ってくれます。
—
5. トラブルシューティングの現場から：ありがちな罠
最後に、現場のSREとして「うわっ、やっちゃったな…」というトラブルの事例をひとつご紹介します。
時々、「すべての通信を一度コントロールしたい！」という理由で、ルートテーブルに 0.0.0.0/0 の宛先として、Transit GatewayやVPNを無理やり設定することがあります。これをやるとどうなるでしょうか？
もしプライベートサブネットのデフォルトルート（0.0.0.0/0）の向き先を、NATゲートウェイからTransit Gatewayに変更してしまうと、インターネット向けの通信（例えば 8.8.8.8 や外部API）のすべてがTGW側へ吸い込まれてしまいます。
その結果、宛先のネットワーク側で適切な返答ルート（戻りパケットのルーティング）が設定されていないと、通信がピタリと止まってしまい、「あれ、YUMやAPTでパッケージがアップデートできないぞ…？」というパニックに繋がります。
【教訓】
- インターネットに出たい通信は、素直に
0.0.0.0/0を NATゲートウェイ に向ける。 - 他のプライベートネットワーク（VPCやオンプレミス）に行きたい通信は、それぞれ専用の具体的なIPアドレス範囲（CIDR）を指定して、VPCピアリングやTransit Gateway に向ける。
この「住み分け」をしっかり意識するだけで、ネットワークトラブルの大部分は綺麗に防ぐことができますよ。
—
まとめ
いかがでしたでしょうか？
今回は、NATゲートウェイとVPCピアリング/Transit Gatewayのルートが競合した際の評価順序について解説しました。
- ルーティングは「より具体的な住所（最長一致）」が勝つ！
- だから、具体的なIP範囲のルートと、すべてを網羅する
0.0.0.0/0（NATゲートウェイ）が共存していても、意図した通りに綺麗にルーティングされる。 - 迷ったときは「パケットの宛先はどの街に一番近いかな？」と地図を広げるように考えてみる。
インフラやネットワークの世界は、最初は難しく見える用語が多いですが、一歩ずつ身近なものに置き換えていくと、とてもロジカルで面白い仕組みで動いています。
あなたのクラウド構築ライフが、よりスムーズで楽しいものになりますように！それではまた次の技術でお会いしましょう。
コメント