108. ルートテーブルは行き先ごとの案内板である — 最長プレフィックス一致と、サブネットを『パブリック』にする1行
VPCの中で1つのパケットが「どこへ送られるか」がどう決まるのか、たった数行の表を上から下まで追いながら、その1行1行がパケットの宛先IPと照らし合わされていく様子を図で追っていきます。
① 案内板はDestinationとTargetの2列
- 公式定義: Destination = 「トラフィックを送りたいIPアドレスの範囲(宛先CIDR)」。Target = 「宛先トラフィックを送るゲートウェイ・ネットワークインターフェイス・接続(gateway, network interface, or connection)」。
- 表は「行の集まり」にすぎない。1行 = (宛先CIDR → 送り先) のペア。
- 上の3行はAWS公式ドキュメントの例の表そのまま(10.0.0.0/16→local、172.31.0.0/16→pcx-11223344556677889、0.0.0.0/0→igw-12345678901234567)。
ルートテーブルは「宛先CIDR → 送り先」という2列の行を並べただけの案内板。パケットが来るたびに、その宛先IPアドレスがどの行に該当するかを照合し、送り先(target)を決める。
② メイン・カスタム・必ずあるlocal
- 公式定義: メインルートテーブル = 「VPCに自動で付いてくる(automatically comes with your VPC)ルートテーブル。他のルートテーブルに明示的に関連付けられていない全サブネットのルーティングを制御する」。
- カスタムルートテーブル = 「VPC用に自分で作成するルートテーブル」。
- local ルート = 「VPC内の通信のためのデフォルトルート(a default route for communication within the VPC)」。IPv4とIPv6の両方があれば、それぞれにlocalルートが1本ずつある。
- 公式: 「すべてのルートテーブルは、VPC内通信のためのlocalルートを含む。このルートはデフォルトで全ルートテーブルに追加される(This route is added by default to all route tables)」。localルートのtargetは差し替え・復元が可能(ミドルボックス構成向け)だが、行そのものは全表に標準装備(根拠: subnet-route-tables.html)。
明示的に関連付けなければメインルートテーブルが支配し、関連付ければカスタムが上書きする。そしてどの表にも必ずlocalルートがあり、VPC内あての通信はここで完結する。
③ 最も長く一致する行が勝つ
- 公式: 「最も具体的な、一致するルートを使ってトラフィックを送る。これを最長プレフィックス一致(longest prefix match)と呼ぶ」。
- 公式の例そのまま: 172.31.0.0/16あてのトラフィックは、0.0.0.0/0(IGW)より具体的なので、ピアリング接続(pcx-…)を使う。
- プレフィックス長 = CIDRの「/16」の数字 = 先頭から何bitを固定で照合するか。長いほど「具体的」。公式の別例では 10.10.2.15/32 が 10.10.2.0/24 に優先する。
- 「表を上から順に読む」のではない。全行を見て、一致する中で最長プレフィックスの1行を選ぶ検索。
複数の行に一致しても、より長いプレフィックス(=より具体的な指定)を持つ行が必ず勝つ。これはS3の認証編で見た「明示的Denyが勝つ」や、API Gateway編の「より具体的なパスが勝つ」と同じ、"競合解決の規則を先に決めておく"設計の一族。
④ 0.0.0.0/0の正体は「残り全部」
- プレフィックス長0 = 1bitも指定しない = 全アドレスに一致。だが最短プレフィックスなので、他に一致する行があれば必ず負ける。
- 公式: 「ルートテーブルが明示的に知らない全ての宛先(all destinations not explicitly known to the route table — 0.0.0.0/0 for IPv4 or ::/0 for IPv6)に対して、インターネットゲートウェイへのルートを指定できる」。
- つまり 0.0.0.0/0 は「他のどれにも該当しなかった残り全部」の意味になる。
0.0.0.0/0 は「全部に一致するが必ず最後に負ける」行。だからこそ「どこにも当たらなかった残り全部」を意味し、これをIGWに向けると「インターネットへの道」になる。プログラミングのswitch文のdefault節と同じ発想で、"最後に残ったものを引き受ける"役割だ。
⑤ 『パブリック』の正体はこの1行の有無
- 公式定義: 「サブネットがインターネットゲートウェイへのルートを持つルートテーブルに関連付けられていれば、それはパブリックサブネットと呼ばれる。IGWへのルートを持たないルートテーブルに関連付けられていれば、プライベートサブネットと呼ばれる」。
- 「パブリック/プライベート」はサブネットに立てるフラグではなく、関連付いたルートテーブルにIGWルートがあるかどうかの結果。
- 両サブネットとも localルート(例: 10.0.0.0/16 → local)は共通に持つ。
- 補足: プライベートサブネットのインスタンスはpublic IPを持っていても、IGWへのルートがないためインターネットと通信できない(公式の明記: "instances in the private subnet can't communicate with the internet, even if they have public IP addresses")。
「パブリックサブネット」という特別な種類のサブネットがあるわけではない。関連付いた案内板に「0.0.0.0/0 → igw-…」の1行があればパブリック、なければプライベート。呼び名の違いは、たった1行のルートの有無に還元される。
⑥ IGWは細い管ではない — 但し書き2つ
- 公式: 「インターネットゲートウェイは、水平スケールされ、冗長で、高可用なVPCコンポーネントであり、VPCとインターネット間の通信を可能にする。ネットワークトラフィックに可用性リスクや帯域制約(availability risks or bandwidth constraints)をもたらさない」。
- 但し書き(1): 宛先が同一の場合、静的ルートがプロパゲート(VPN経由でVPGから自動追加)ルートに優先する。静的の対象にはIGW・NATゲートウェイ・ネットワークインターフェイス・VPCピアリング等が含まれる。※これは「宛先が同一のとき」の話で、大前提は依然として最長プレフィックス一致(より具体的な行が種別を問わず先に勝つ)。
- 但し書き(2): 公式: 「CIDRブロックをVPCに関連付けると、VPC内のルーティングを可能にするためのルートが自動でルートテーブルに追加される(宛先=そのCIDRブロック、ターゲット=local)」。例の2行(10.0.0.0/16と10.2.0.0/16)は公式の例そのまま(レッスン1「VPCはCIDRを足せる」の回収。根拠: vpc-cidr-blocks.html)。
IGWは1本の細い管ではなく、水平スケールする高可用コンポーネント — だから「インターネットへの道」を1行足しても、そこがボトルネックにも単一障害点にもならない。そして案内板の読み方には、同一宛先なら静的が優先・CIDRを足せばlocalが自動で増える、という2つの但し書きが付く。
⑦ 名前の解決と番号の解決
- 両者は総括レッスンで合流する。
ルーティングとは「表を上から順に読む」ことではなく、「最も長く一致する行を探す」ことだ。キャッシュ編のDNSルーティングが「名前の解決」だったのに対し、ルートテーブルは「番号の解決」——同じ"最も一致するものへ導く"仕組みが、名前と番号という別の顔で現れている。