「僕はパケット。宛先に届くために、VPCの道案内（ルートテーブル）を頼りに旅をする。」
パケットの視点で VPC ルーティングの仕組みを理解しよう！
VPC ルーティングを理解するために、まずこの4つのポイントだけ押さえてください。
パケットは「宛先IPアドレス」を見て、ルートテーブル（道路標識）に従い、次にどこへ行くか決めます。
ルートが複数マッチする場合、最も具体的な（CIDRが長い）ルートが優先されます。住所が詳しい標識ほど優先！
各サブネットには必ず1つのルートテーブルが紐づきます。明示的に設定しないとメインルートテーブルが使われます。
ルートの「ターゲット」は、パケットが次に通過するゲートウェイやENIです。目的地への「出口」のこと。
あなたは配達ドライバー（パケット）です。荷物（データ）を届けるために、 街（VPC）の中を道路標識（ルートテーブル）を見ながら走ります。 この対応表を覚えれば、VPCルーティングはもう怖くありません！
自分だけの専用ネットワーク空間。街の境界線（CIDRブロック）で範囲が決まっています。
VPCを区切った小さなネットワーク。各地区（サブネット）ごとに道路標識（ルートテーブル）が設置されています。
「この宛先に行くなら、この道を通れ」という案内板。すべてのサブネットに必ず1つ設置されます。
IGW（Internet Gateway）は「街の正面玄関」で、VPC自体にアタッチされます（サブネットの外）。NAT-GWは「パブリックサブネット内に配置された、代理で外出してくれる受付」です。
パケットがサブネットから出発するとき、まずルートテーブルを確認します。 下の図は VPC 内の基本的な構造と、パケットがどのようにルーティングされるかを示しています。
図1：VPC全体構造 ─ IGWはVPCにアタッチ（サブネット外）、NAT-GWはパブリックサブネット内に配置
パケットは自分のヘッダーにある「宛先IPアドレス」を確認します。「この荷物はどこ行き？」
所属するサブネットのルートテーブル（道路標識）で、宛先に最もマッチするルートを探します。
マッチしたルートの「ターゲット」（出口）にパケットが送り出されます。IGW? NAT-GW? local?
パブリックサブネットの EC2（10.0.1.10）から、プライベートサブネットの EC2（10.0.2.20）へ通信する場合。 同じ街の中での配達のようなものです。
「宛先は 10.0.2.20 だな。ルートテーブルを見ると… 10.0.0.0/16 → local だ！同じ街の中だから、直接届けに行こう！」
| 宛先（Destination） | ターゲット（Target） | 説明 |
|---|---|---|
| 10.0.0.0/16 | local | ✅ マッチ！VPC内で直接配達 |
| 0.0.0.0/0 | igw-xxxxxxxx | インターネットへの出口 |
図2：VPC内通信 ─ local ルートで直接配達。ゲートウェイは通らない
local ルートはVPC作成時に自動追加され、削除できません。 これは「同じ街の中なら、標識がなくても直接届けられる」という基本ルールです。 VPC内のすべてのサブネット間は、この local ルートで通信可能です。
パブリックサブネットの EC2 から Google（8.8.8.8）にアクセスする場合。 街の外に荷物を届けるには、正面玄関（Internet Gateway）を通る必要があります。
「宛先は 8.8.8.8 だ。ルートテーブルを見ると… 10.0.0.0/16 にはマッチしない。0.0.0.0/0 → IGW がある！正面玄関からインターネットの世界へ出よう！」
| 宛先（Destination） | ターゲット（Target） | 説明 |
|---|---|---|
| 10.0.0.0/16 | local | VPC内通信（今回はマッチしない） |
| 0.0.0.0/0 | igw-xxxxxxxx | ✅ マッチ！インターネットへの出口 |
図3：パブリックサブネット → IGW（VPCにアタッチ）→ インターネット
IGW はサブネットではなく VPC にアタッチされます。街の「正面玄関」は特定の地区内にあるのではなく、街の境界に設置されるイメージです。 サブネットが「パブリック」と呼ばれるには、ルートテーブルに IGW へのルート（0.0.0.0/0 → igw-xxx）があり、 EC2 インスタンスにパブリック IP が割り当てられている必要があります。 道路標識に「正面玄関はこっち」と書いてあっても、入館証（パブリックIP）がないと外に出られません。
プライベートサブネットの EC2 は直接インターネットに出られません。 代わりに NAT Gateway（代理で外出してくれる受付）を通じてインターネットにアクセスします。
「宛先は 8.8.8.8 だけど、僕はプライベートサブネットにいる。直接外には出られない…。ルートテーブルを見ると 0.0.0.0/0 → NAT-GW だ！受付さんに代わりに外に出てもらおう！」
| 宛先（Destination） | ターゲット（Target） | 説明 |
|---|---|---|
| 10.0.0.0/16 | local | VPC内通信 |
| 0.0.0.0/0 | nat-xxxxxxxx | ✅ マッチ！NAT-GW経由で外出 |
図4：プライベートSN → NAT-GW（パブリックSN内）→ IGW（VPCにアタッチ）→ インターネット
NAT Gateway は「代理で外出してくれる受付」です。外出はできますが、外からの訪問者が直接プライベートサブネットに入ることはできません。 これにより、プライベートサブネットの EC2 はインターネットにアクセスしつつ、外部からのアクセスを遮断できます。 NAT Gateway 自体はパブリックサブネットに配置される点に注意してください。
別のVPC（172.16.0.0/16）のリソースにアクセスする場合。 これは「隣の街への専用トンネル」を通るイメージです。
「宛先は 172.16.1.50 だな。うちの街（10.0.0.0/16）ではない。ルートテーブルを見ると… 172.16.0.0/16 → pcx-xxxxxxxx だ！隣の街への専用トンネルが使えるぞ！」
| 宛先（Destination） | ターゲット（Target） | 説明 |
|---|---|---|
| 10.0.0.0/16 | local | 自分のVPC内通信 |
| 172.16.0.0/16 | pcx-xxxxxxxx | ✅ マッチ！VPC Peering経由 |
| 0.0.0.0/0 | igw-xxxxxxxx | インターネットへの出口 |
VPC Peering は「双方向の専用トンネル」です。トンネルを掘っただけでは不十分で、 両方のVPCのルートテーブルに相手方への道路標識を追加する必要があります。 片側だけに標識があっても、帰り道がわかりません！
ルートテーブルに複数のルートがマッチする場合、最も具体的な（CIDRの範囲が狭い＝プレフィックスが長い）ルートが勝ちます。 配達で例えると「東京都」と「東京都渋谷区神宮前1-1-1」の両方の標識がある場合、より詳しい住所の標識が優先されるのと同じです。
「地球上のどこか」レベルの大雑把さ
「この街のどこか」レベル
「この地区のこの通り」レベル
AWSでは、ルートテーブル内で宛先にマッチする全ルートの中から、プレフィックスが最も長い（CIDR範囲が最も狭い）ルートを選びます。 /24 は /16 より具体的で、/16 は /0 より具体的です。 これは「より詳しい住所を知っている道路標識に従え」というルールです。 同じプレフィックス長のルートが複数ある場合は、静的ルートが伝播ルートより優先されます。
VPCには「メインルートテーブル」と「カスタムルートテーブル」の2種類があります。
VPC作成時に自動で作られるデフォルトのルートテーブルです。
明示的にルートテーブルを関連付けていないサブネットは、自動的にこのメインルートテーブルを使います。 「地区ごとの標識がなければ、街全体の共通標識に従う」というイメージです。
ベストプラクティス：メインルートテーブルはデフォルト（local のみ）のままにし、各サブネットにカスタムルートテーブルを使うのが安全です。
自分で作成して、特定のサブネットに関連付けるルートテーブルです。
パブリックサブネット用にはIGWルートを、プライベートサブネット用にはNAT-GWルートを設定するなど、 目的に応じた道路標識を設置できます。 「繁華街エリアには専用の道路標識を設置する」というイメージです。
ベストプラクティス：サブネットの役割（パブリック/プライベート/VPN専用）ごとに別のカスタムルートテーブルを作成しましょう。
ルートテーブルで指定できる主なターゲット（パケットの次の行き先）をまとめます。
| ターゲット | たとえ話 | 主な用途 |
|---|---|---|
| local | 同じ街の中で直接配達 | VPC内通信（自動設定・削除不可） |
| igw-xxx | 🚪 街の正面玄関 | インターネットとの双方向通信（VPCにアタッチ・サブネット外） |
| nat-xxx | 🔄 代理で外出してくれる受付 | プライベートSNからのインターネットアクセス（パブリックSN内に配置） |
| pcx-xxx | 🔗 隣の街への専用トンネル | VPC Peeringでの他VPC通信 |
| tgw-xxx | 🚉 複数の街をつなぐ中央駅 | Transit Gatewayで多数VPCを接続 |
| vgw-xxx | 🏢 オフィスへの専用回線 | VPN接続でオンプレミスと通信 |
| vpce-xxx | 📮 街の中の専用ポスト | VPCエンドポイント（S3等にプライベート接続） |
| eni-xxx | 👤 特定の担当者に直接渡す | ネットワークインターフェイス（ファイアウォール等） |
ルーティングのトラブルで最もよくある原因と対処法をまとめます。
ルートテーブルに 0.0.0.0/0 → IGW のルートがない、またはパブリックIPが付与されていない可能性があります。
✅ サブネットのルートテーブルにIGWルートがあるか確認し、EC2にパブリックIP / Elastic IPが割り当てられているか確認
NAT Gateway のルートが設定されていない、またはNAT Gateway自体がパブリックSNに配置されていない可能性があります。
✅ プライベートSNのルートテーブルに 0.0.0.0/0 → nat-xxx があるか確認。NAT-GW がパブリックSN内にあるかも確認
片方のVPCにしかルートを追加していない。両方のVPCのルートテーブルに相手方CIDRへのルートが必要です。
✅ 両方のVPCのルートテーブルに相手方CIDRのルートがあるか確認。セキュリティグループとNACLも確認
最長プレフィックスマッチにより、より具体的なルートが意図せず優先されている可能性があります。
✅ ルートテーブルの全ルートを確認し、宛先CIDRの粒度（プレフィックス長）を見直す
削除できません。 local ルートはVPC内通信を保証する基本ルールで、すべてのルートテーブルに自動的に存在します。 ただし、より具体的なルート（例：10.0.1.0/24 → 特定のENI）を追加することで、 localルートの一部を上書きすることは可能です（ミドルボックスルーティングなど）。
1つのサブネットに関連付けられるルートテーブルは1つだけです。 ただし、1つのルートテーブルを複数のサブネットに関連付けることはできます。 「各地区に設置できる道路標識は1セットだけ。でも同じ標識を複数の地区で共有はOK」というイメージです。
パケットは破棄（ドロップ）されます。 マッチするルートがなければ、パケットは行き場を失い、宛先に届きません。 「道路標識にない場所には行けない」ということです。 だからこそ、0.0.0.0/0（デフォルトルート）を設定して「それ以外はここへ」と指定することが重要です。
はい、ルートテーブルの変更は即座に反映されます。 道路標識を書き換えた瞬間から、新しいルートに従ってパケットが転送されます。 ただし、既存のコネクションが突然切れる場合があるため、本番環境での変更は慎重に行いましょう。
ルートテーブルは「道順」、セキュリティグループと NACL は「検問所」です。 ルートテーブルはパケットの行き先を決めるもの。セキュリティグループはインスタンスレベルのファイアウォール（入口の警備員）、 NACLはサブネットレベルのファイアウォール（地区の入口ゲート）です。 パケットは「道順を調べる → 検問所を通過 → 配達」の順で処理されます。
ルートテーブル（道路標識）が唯一の道案内。宛先IPとルートを照合して次のターゲットを決定
最長プレフィックスマッチにより、最も具体的なルートが常に勝つ。/24 > /16 > /0
各サブネットに1つのルートテーブル。目的別にカスタムルートテーブルを作成するのがベスト
Created by SSuzuki1063
AWS SAP Learning Resources