概要
VPC 内に複数のサブネットを作成しても、それぞれのサブネットがどこと通信できるかは自動では決まりません。サブネット内のリソースから出ていくトラフィックを「どこへ転送するか」を定義するのがルートテーブルです。同じ VPC の中でも、インターネットに出られるサブネットと出られないサブネットを分けられるのは、サブネットごとに異なるルートテーブルを関連付けられるからです。
ルートテーブルは、トラフィックの送信先（宛先 IP の範囲）と、そのトラフィックを渡すターゲット（転送先のコンポーネント）を組み合わせた「ルート」の集合です。ルートの設計を理解することは、パブリック／プライベートサブネットの構成や、VPC ピアリング・NAT ゲートウェイなどの応用構成を理解する土台になります。
本記事では、ルートテーブルの構成要素とルートの優先順位の仕組みを理解し、既存の VPC 上でカスタムルートテーブルを作成・編集してサブネットの関連付けを切り替える操作を体験します。
この記事のメリット
- ルートテーブル・ルート・ターゲットの関係と、トラフィック制御の仕組みを理解できる
- メインルートテーブルとカスタムルートテーブルの違いと使い分けを把握できる
- ロンゲストプレフィックスマッチによるルートの優先順位の決まり方を学べる
- カスタムルートテーブルを作成し、サブネットの関連付けを変更する手順を習得できる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
クラウドおさるとひさん、前回 VPC とサブネットを作りましたよね。サブネットってルートテーブルが関連付くって話でしたけど、ルートテーブルってそもそも何をするものなんですか？
土肥いい復習だね。ルートテーブルは、サブネット内のリソースから出ていくトラフィックを「どこに転送するか」を決めるルールの集まりだよ。VPC のトラフィック制御を担う、いわば交通整理の役割なんだ。一つひとつのルールを「ルート」と呼ぶよ。
クラウドおさるルートにはどんな情報が入っているんですか？
土肥ルートは「送信先」と「ターゲット」の 2 つの要素で構成されているんだ。
| 要素 | 説明 |
|---|---|
| 送信先（Destination） | トラフィックの宛先 IP アドレスの範囲。CIDR ブロックやプレフィックスリストで指定する（例: 0.0.0.0/0、10.0.0.0/16） |
| ターゲット（Target） | 送信先に向かうトラフィックを渡す先のコンポーネント。local、インターネットゲートウェイ、NAT ゲートウェイ、VPC ピアリング接続など |
土肥トラフィックが発生すると、その宛先 IP アドレスがどのルートの送信先に当てはまるかを照合して、当てはまったルートのターゲットへ転送する、という流れになるよ。
クラウドおさるなるほど、宛先を見てルールに照らし合わせるんですね！前回のルートテーブルに local っていうのがありましたけど、あれもターゲットの一種なんですね。
土肥そうそう。local ルートは特別なルートで、VPC 内の通信のためのものだよ。ルートテーブルを作ると、VPC の CIDR ブロックを送信先、ターゲットを local とするルートが自動で入るんだ。これがあるおかげで、同じ VPC 内のサブネット同士は何も設定しなくても通信できるんだよ。local ルートはすべてのルートテーブルに必ず存在していて、削除はできないんだ。
クラウドおさるだから前回作ったルートテーブルにも、最初から 10.0.0.0/16 の local ルートが入っていたんですね。
メインルートテーブルとカスタムルートテーブル
クラウドおさるところで、ルートテーブルって VPC を作ったら自動でできるんですか？それとも自分で作るものなんですか？
土肥実は両方あるんだ。VPC を作成すると、AWS が自動的に 1 つルートテーブルを用意してくれる。これを「メインルートテーブル」と呼ぶよ。それとは別に、利用者が自分で作るルートテーブルを「カスタムルートテーブル」と呼ぶんだ。
| 種類 | 作成タイミング | 役割 |
|---|---|---|
| メインルートテーブル | VPC 作成時に自動で 1 つ作られる | どのルートテーブルにも明示的に関連付けられていないサブネットのルーティングを制御する |
| カスタムルートテーブル | 利用者が明示的に作成する | 特定のサブネットに関連付けて、用途に応じたルーティングを設定する |
クラウドおさるなるほど。メインルートテーブルは「デフォルトの担当」みたいな感じなんですね。
土肥そのイメージで合っているよ。ポイントは、メインルートテーブルは原則そのまま使わず、用途ごとにカスタムルートテーブルを作る運用が推奨されることだね。たとえばインターネットへのルートを持つルートテーブルをメインにしてしまうと、新しく作ったサブネットが意図せずパブリックになってしまうことがあるんだ。
クラウドおさる知らないうちにインターネットに繋がっちゃうのは怖いですね…。
土肥だからこそ、メインルートテーブルは控えめにしておいて、インターネットに出したいサブネットだけカスタムルートテーブルを明示的に関連付ける、というのが安全なんだ。
サブネットの関連付け
クラウドおさるその「関連付け」って、サブネットとルートテーブルを結びつけることですよね。前回 1 回やった記憶があります。
土肥そうだね。サブネットとルートテーブルの関連付けには、実は 2 種類あるんだ。
| 関連付けの種類 | 説明 |
|---|---|
| 明示的関連付け | サブネットとカスタムルートテーブルを利用者が直接結びつけた状態 |
| 暗黙的関連付け | どのカスタムルートテーブルにも明示的に関連付けられていないサブネットが、自動的にメインルートテーブルに従う状態 |
クラウドおさるつまり、自分で何も設定しなくても、サブネットは必ずどれかのルートテーブルに従っているってことですか？
土肥その通り。サブネットは常にちょうど 1 つのルートテーブルに関連付けられているんだ。明示的に関連付ければそのルートテーブル、何もしなければメインルートテーブルに暗黙的に関連付けられる。1 つのサブネットが複数のルートテーブルに同時に従うことはないよ。
クラウドおさるなるほど！逆に、1 つのルートテーブルを複数のサブネットで共有することはできるんですか？
土肥それはできるよ。たとえばプライベートサブネットが 3 つあるなら、同じプライベート用ルートテーブルを 3 つのサブネットに関連付けて使い回せるんだ。「サブネット : ルートテーブル」が「多 : 1」になるイメージだね。
ルートの優先順位
クラウドおさるもしルートテーブルの中に、宛先が重なるルートが複数あったらどうなるんですか？10.0.0.0/16 と 10.0.1.0/24 って、後者は前者に含まれていますよね。
土肥いいところに気づいたね！その場合は「ロンゲストプレフィックスマッチ」というルールで決まるんだ。トラフィックの宛先 IP に対して、複数のルートが当てはまるときは、最も具体的なルート（プレフィックスが最も長いルート）が優先されるんだよ。
クラウドおさるプレフィックスが長いって、/24 のほうが /16 より長いってことですか？
土肥そうそう。/24 のほうが範囲が狭くて具体的だよね。だから宛先が 10.0.1.5 宛のトラフィックなら、10.0.0.0/16 のルートと 10.0.1.0/24 のルートの両方に当てはまるけど、より具体的な 10.0.1.0/24 のルートが選ばれるんだ。
| ルート（送信先） | プレフィックス長 | 10.0.1.5 宛トラフィックでの扱い |
|---|---|---|
10.0.1.0/24 | /24（より具体的） | こちらが優先される |
10.0.0.0/16 | /16 | 当てはまるが優先されない |
0.0.0.0/0 | /0（最も広い） | 当てはまるが優先されない |
クラウドおさるなるほど！0.0.0.0/0 が一番優先度が低いんですね。だから「どれにも当てはまらなかったときの受け皿」みたいに使えるんですね。
土肥その理解で完璧だよ。0.0.0.0/0 はすべての IPv4 アドレスを表すから、local ルートやその他の具体的なルートに当てはまらなかったトラフィックがここに流れる。インターネットゲートウェイや NAT ゲートウェイを 0.0.0.0/0 のターゲットにするのは、まさにこの「最後の受け皿」を使っているんだ。
クラウドおさるルートテーブルの仕組み、だいぶイメージがつきました！実際に作って動きを見てみたいです。
実践
既存の VPC 上にカスタムルートテーブルを作成し、ルートを追加してサブネットに関連付ける手順を体験します。あわせて、メインルートテーブルとの関係や暗黙的関連付けの動きを確認します。本記事の操作はすべて VPC コンソール内で完結します。
前提条件
- リージョン:
ap-northeast-1（東京） - IAM ユーザーまたはロールに VPC 関連リソースの操作権限があること
- 以下のリソースが作成済みであること
| リソース種別 | リソース名 | 補足 |
|---|---|---|
| VPC | rt-vpc | CIDR ブロック 10.0.0.0/16 |
| パブリックサブネット | rt-public-subnet | CIDR 10.0.1.0/24（AZ: ap-northeast-1a） |
| プライベートサブネット | rt-private-subnet | CIDR 10.0.2.0/24（AZ: ap-northeast-1a） |
| インターネットゲートウェイ | rt-igw | rt-vpc にアタッチ済み |
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| ルートテーブル | rt-public-rt | パブリックサブネット用（インターネットへのルートを持つ） |
ステップ1: メインルートテーブルを確認する
まず、VPC 作成時に自動で作られたメインルートテーブルの状態を確認します。
- AWS マネジメントコンソールにログインし、リージョンが
ap-northeast-1（東京）であることを確認します - 上部の検索バーに
VPCと入力し、表示された「VPC」を選択します - 左側ナビゲーションの「ルートテーブル」を選択します
- 一覧の「VPC」列で
rt-vpcに属するルートテーブルを探します。「メインルートテーブル」列がはいになっているものがメインルートテーブルです - そのルートテーブルを選択し、下部の「ルート」タブを選択します
10.0.0.0/16 を送信先とする local ルートが 1 つだけ存在することが確認できます。これは VPC 内通信のためのルートで、削除はできません。
- 続けて「サブネットの関連付け」タブを選択します
- 「明示的なサブネットの関連付け」には何も表示されず、「関連付けられていないサブネット」に
rt-public-subnetとrt-private-subnetが表示されることを確認します
この時点では、2 つのサブネットはどちらもメインルートテーブルに暗黙的に関連付けられている状態です。
ステップ2: カスタムルートテーブルを作成する
パブリックサブネット用のカスタムルートテーブルを作成します。
- 左側ナビゲーションの「ルートテーブル」を選択し、「ルートテーブルを作成」をクリックします
- 以下の内容を入力します
- 名前:
rt-public-rt - VPC:
rt-vpcを選択 - 「ルートテーブルを作成」をクリックします
作成完了後、rt-public-rt の詳細画面が表示されます。「ルート」タブを見ると、この時点でも 10.0.0.0/16 の local ルートが自動で含まれていることが確認できます。
ステップ3: インターネットへのルートを追加する
作成したカスタムルートテーブルに、インターネット向けのルートを追加します。
rt-public-rtの詳細画面で「ルート」タブを選択し、「ルートを編集」をクリックします- 「ルートを追加」をクリックし、以下を入力します
- 送信先:
0.0.0.0/0 - ターゲット: 「インターネットゲートウェイ」を選択し、表示された
rt-igwを選択 - 「変更を保存」をクリックします
保存後、「ルート」タブに 2 つのルート（10.0.0.0/16 → local、0.0.0.0/0 → rt-igw）が表示されることを確認します。
ステップ4: カスタムルートテーブルをパブリックサブネットに関連付ける
rt-public-rt をパブリックサブネットに明示的に関連付けます。
rt-public-rtの詳細画面で「サブネットの関連付け」タブを選択します- 「明示的なサブネットの関連付け」セクションの「サブネットの関連付けを編集」をクリックします
- 一覧から
rt-public-subnetにチェックを入れます。rt-private-subnetにはチェックを入れません - 「関連付けを保存」をクリックします
保存後、「明示的なサブネットの関連付け」に rt-public-subnet が表示されることを確認します。これでパブリックサブネットは rt-public-rt に明示的に関連付けられ、インターネットへのルートを持つようになりました。
ステップ5: メインルートテーブル側の変化を確認する
明示的関連付けによってメインルートテーブル側がどう変わったかを確認します。
- 左側ナビゲーションの「ルートテーブル」を選択し、
rt-vpcのメインルートテーブルを選択します - 「サブネットの関連付け」タブを選択します
「関連付けられていないサブネット」から rt-public-subnet が消え、rt-private-subnet のみが残っていることが確認できます。rt-public-subnet はカスタムルートテーブルに明示的に関連付けられたため、メインルートテーブルへの暗黙的関連付けが解消されました。一方 rt-private-subnet は明示的な関連付けがないため、引き続きメインルートテーブルに暗黙的に関連付けられています。
ステップ6: リソースマップで関連付けを確認する
VPC のリソースマップで、ルートテーブルとサブネットの関係を視覚的に確認します。
- 左側ナビゲーションの「お使いの VPC」を選択し、
rt-vpcを選択します - 「リソースマップ」タブを選択します
rt-public-subnet が rt-public-rt を経由してインターネットゲートウェイ rt-igw につながっていること、rt-private-subnet はメインルートテーブルに関連付けられインターネットへのルートを持たないことが、線でつながった図として確認できます。
まとめ
- ルートテーブルは、送信先（宛先 IP の範囲）とターゲット（転送先のコンポーネント）からなるルートの集合で、サブネットのトラフィックの流れを制御する
localルートは VPC 内通信のためのルートで、すべてのルートテーブルに自動で含まれ、削除できない- VPC 作成時に自動で作られるメインルートテーブルに対し、用途ごとに作るのがカスタムルートテーブルで、明示的に関連付けるサブネットだけが意図したルーティングに従う
- サブネットは常にちょうど 1 つのルートテーブルに関連付けられ、明示的関連付けがなければメインルートテーブルに暗黙的に関連付けられる
- 宛先が重なる複数のルートがある場合は、ロンゲストプレフィックスマッチにより最も具体的なルートが優先される
