ルートテーブル - Amazon Virtual Private Cloud

ルートテーブル

ルートテーブルには、サブネットまたはゲートウェイからのネットワークトラフィックの経路を判断する際に使用される、ルートと呼ばれる一連のルールが含まれます。

ルートテーブルの概念

ルートテーブルの主な概念は次のとおりです。

  • メインルートテーブル — VPC に自動的に割り当てられるルートテーブル。これは、他のルートテーブルに明示的に関連付けられていないすべてのサブネットのルーティングを制御します。

  • カスタムルートテーブル — VPC 用に作成するルートテーブル。

  • エッジの関連付け—インバウンド VPC トラフィックをアプライアンスにルーティングするために使用するルートテーブル。ルートテーブルをインターネットゲートウェイまたは仮想プライベートゲートウェイに関連付け、アプライアンスのネットワークインターフェイスを VPC トラフィックのターゲットとして指定します。

  • ルートテーブルの関連付け — ルートテーブルとサブネット、インターネットゲートウェイ、または仮想プライベートゲートウェイの間の関連付け。

  • サブネットルートテーブル — サブネットに関連付けられたルートテーブル。

  • ゲートウェイルートテーブル — インターネットゲートウェイまたは仮想プライベートゲートウェイに関連付けられたルートテーブル。

  • ローカルゲートウェイルートテーブル — Outposts ローカルゲートウェイに関連付けられているルートテーブル。ローカルゲートウェイの詳細については、AWS Outposts ユーザーガイドの「ローカルゲートウェイ」を参照してください。

  • [送信先] — トラフィックを送信する IP アドレスの範囲 (送信先 CIDR)。たとえば、172.16.0.0/12 CIDR がある外部企業ネットワークなどです。

  • 伝達—ルート伝達により、仮想プライベートゲートウェイはルートテーブルにルートを自動的に伝達できます。つまり、ルートテーブルへの VPN ルートを手動で入力する必要はありません。VPN ルーティングオプションの詳細については、Site-to-Site VPN ユーザーガイドの「Site-to-Site VPN のルーティングオプション」を参照してください。

  • [ターゲット] — 送信先トラフィックの送信に使用するゲートウェイ、ネットワークインターフェイス、または接続 (インターネットゲートウェイなど)。

  • ローカルルート — VPC 内の通信のデフォルトルート。

ルーティングオプションの例については、「ルーティングオプションの例」を参照してください。

ルートテーブルの仕組み

VPC には暗黙的なルーターがあり、ルートテーブルを使用してネットワークトラフィックの送信先を制御します。VPC の各サブネットをルートテーブルに関連付ける必要があり、ルートテーブルはサブネットのルーティング(サブネットルートテーブル)を制御します。サブネットを特定のルートテーブルに明示的に関連付けることができます。それ以外の場合、サブネットはメインルートテーブルに暗黙的に関連付けられます。1 つのサブネットは同時に 1 つのルートテーブルにしか関連付けることはできませんが、複数のサブネットを同じサブネットルートテーブルに関連付けることはできます。

必要に応じて、ルートテーブルをインターネットゲートウェイまたは仮想プライベートゲートウェイ(ゲートウェイルートテーブル)に関連付けることができます。これにより、ゲートウェイを介して VPC に入るインバウンドトラフィックのルーティングルールを指定できます。詳細については、「ゲートウェイルートテーブル」を参照してください。

VPC ごとに作成できるルートテーブルの数にはクォータがあります。ルートテーブルごとに追加できるルート数にもクォータがあります。詳細については、「Amazon VPC のクォータ」を参照してください。

ルート

テーブル内の各ルートは、送信先とターゲットを指定します。たとえば、サブネットがインターネットゲートウェイ経由でインターネットにアクセスできるようにするには、サブネットルートテーブルに次のルートを追加します。

送信先 ターゲット
0.0.0.0/0 igw-12345678901234567

ルートの宛先は 0.0.0.0/0 です。これは、すべての IPv4 アドレスを表します。ターゲットは、VPC にアタッチされているインターネットゲートウェイです。

IPv4 と IPv6 の CIDR ブロックは、個別に処理されます。たとえば、送信先が 0.0.0.0/0 の CIDR のルーティングの場合は、IPv6 アドレスが自動的に含まれることはありません。すべての IPv6 アドレスの宛先が ::/0 の CIDR のルートを作成する必要があります。

各ルートテーブルには、VPC 内で通信を有効にするローカルルートが含まれます。このルートは、デフォルトですべてのルートテーブルに追加されます。VPC に複数の IPv4 CIDR ブロックがある場合、ルートテーブルには各 IPv4 CIDR ブロックのローカルルートが含まれます。IPv6 CIDR ブロックを VPC に関連付けた場合、ルートテーブルには IPv6 CIDR ブロックのローカルルートが含まれます。サブネットルートテーブルまたはメインルートテーブルでこれらのルートを変更または削除することはできません。

ゲートウェイルートテーブル内のルートとローカルルートの詳細については、「ゲートウェイルートテーブル」を参照してください。

ルートテーブルに複数のルートがある場合、AWS では、トラフィックと一致する(最長プレフィックス一致)最も具体的なルートを使用して、トラフィックをルーティングする方法を決定します。

次の例では、IPv6 CIDR ブロックは、VPC に関連付けられています。ルートテーブルでは、

  • VPC (2001:db8:1234:1a00::/56) 内に留まる宛先の IPv6 トラフィックは、Local ルートによってカバーされ、VPC 内でルーティングされます。

  • IPv4 ルートと IPv6 ルートに対して個別に適用されます。そのため、IPv6 トラフィックはすべて(VPC 内のトラフィックを除く)、Egress-Only インターネットゲートウェイにルーティングされます。

  • ピア接続を指す 172.31.0.0/16 IPv4 トラフィックのルートがあります。

  • インターネットゲートウェイを指すすべての IPv4 トラフィック (0.0.0.0/0) のルートがあります。

  • Egress-only インターネットゲートウェイを指すすべての IPv6 トラフィック (::/0) のルートがあります。

送信先 ターゲット
10.0.0.0/16 ローカル
2001:db8:1234:1a00::/56 ローカル
172.31.0.0/16 pcx-11223344556677889
0.0.0.0/0 igw-12345678901234567
::/0 eigw-aabbccddee1122334

AWS リソース全体で同じ CIDR ブロックのセットを頻繁に参照する場合は、カスタマーマネージドプレフィックスリストを作成して、それらをグループ化できます。その後、ルートテーブルエントリの送信先としてプレフィックスリストを指定できます。

メインルートテーブル

VPC を作成するときに、メインルートテーブルが自動的に割り当てられます。メインルートテーブルは、他のルートテーブルに明示的に関連付けられていないすべてのサブネットのルーティングを制御します。Amazon VPC コンソールの [Route Tables] ページで、[Main] 列の [Yes] を探すことによって VPC のメインルートテーブルを表示できます。

デフォルトでは、デフォルト以外の VPC を作成すると、メインルートテーブルにはローカルルートのみが含まれます。コンソールで VPC ウィザードを使用して NAT ゲートウェイまたは仮想プライベートゲートウェイを持つデフォルト以外の VPC を作成すると、ウィザードによりそれらのゲートウェイのメインルートテーブルにルートが自動的に追加されます。

メインルートテーブルで、ルートを追加、削除、変更することができます。ローカルルートよりも具体的なルートを作成することはできません。メインルートテーブルは削除できませんが、メインルートテーブルを作成したカスタムサブネットルートテーブルと置き換えることができます。ゲートウェイルートテーブルをメインルートテーブルとして設定することはできません。

すでに暗示的に関連付けられている場合でも、サブネットをメインルートテーブルに明示的に関連付けることができます。この作業は、メインルートテーブルにするテーブルを変更するときに行います。メインルートテーブルであるテーブルを変更する場合、これにより、新しい追加のサブネット、または他のルートテーブルに明示的に関連付けられていないサブネットのデフォルトも変更されます。詳細については、「メインルートテーブルを置き換える」を参照してください。

カスタムルートテーブル

デフォルトでは、カスタムルートテーブルは空で、必要に応じてルートを追加します。コンソールで VPC ウィザードを使用してインターネットゲートウェイを持つ VPC を作成すると、ウィザードによってカスタムルートテーブルが作成され、インターネットゲートウェイにルートが追加されます。VPC を保護する 1 つの方法は、メインルートテーブルを元のデフォルトの状態のままにすることです。次に、作成するそれぞれの新しいサブネットが、作成したカスタムルートテーブルの 1 つに明示的に関連付けられます。これにより、各サブネットがトラフィックをルーティングする方法を明示的にコントロールします。

カスタムルートテーブルで、ルートを追加、削除、変更することができます。カスタムルートテーブルは、関連付けがない場合にのみ削除できます。

サブネットとルートテーブルの関連付け

VPC 内の各サブネットは、ルートテーブルと関連付ける必要があります。サブネットは、カスタムルートテーブルに明示的に関連付けることも、メインルートテーブルに暗黙的または明示的に関連付けることもできます。サブネットとルートテーブルの関連付けの表示の詳細については、「テーブルに明示的に関連付けられているサブネットまたはゲートウェイを特定する」を参照してください。

Outposts に関連付けられた VPC 内のサブネットには、ローカルゲートウェイの追加ターゲットタイプを設定できます。これは、Outposts 以外のサブネットとの唯一のルーティングの違いです。

以下のいずれかに該当する場合、サブネットをルートテーブルに関連付けることはできません。

  • ルートテーブルには、デフォルトのローカルルートよりも具体的な既存のルートが含まれています。

  • デフォルトのローカルルートのターゲットが置き換えられました。

例 1: 暗黙的および明示的なサブネットの関連付け

次の図は、インターネットゲートウェイ、仮想プライベートゲートウェイ、パブリックサブネット、および VPN のみのサブネットを持つ VPC のルーティングを示しています。メインルートテーブルには、仮想プライベートゲートウェイへのルートがあります。カスタムルートテーブルは、パブリックサブネットに明示的に関連付けられています。カスタムルートテーブルには、インターネットゲートウェイを経由するインターネット (0.0.0.0/0) へのルートがあります。


                    メインルートテーブルとカスタムテーブル

この VPC で新しいサブネットを作成すると、そのサブネットはメインルートテーブルに自動的に暗黙的に関連付けられ、メインルートテーブルは、そのトラフィックを仮想プライベートゲートウェイにルーティングします。逆の設定(メインルートテーブルにインターネットゲートウェイへのルートが含まれ、カスタムルートテーブルに仮想プライベートゲートウェイへのルートが含まれる)を行うと、新しいサブネットには自動的に、インターネットゲートウェイへのルートが含まれるようになります。

例 2: メインルートテーブルを置き換える

メインルートテーブルに変更を加えることもできます。トラフィックの中断を避けるために、まずカスタムルートテーブルを使用してルート変更をテストすることをお勧めします。テストの結果に満足したら、メインルートテーブルを新しいカスタムテーブルに置き換えられます。

次の図は、メインルートテーブル (ルートテーブル A) に暗示的に関連付けられている 2 つのサブネットを持つ VPC を示しています。カスタムルートテーブル (ルートテーブル B) は、どのサブネットにも関連付けられていません。


                    メインテーブルの置き換え: 開始

サブネット 2 とルートテーブル B の間には明示的な関連付けを作成できます。


                    メインテーブルの置き換え: 新しいテーブル

ルートテーブル B をテストしたら、そのテーブルをメインルートテーブルにできます。サブネット 2 とルートテーブル B との間に、まだ明示的な関連付けがあることに注意してください。また、ルートテーブル B は新しいメインルートテーブルなので、サブネット 1 とルートテーブル B の間には暗示的な関連付けがあります。ルートテーブル A はもう使用されていません。


                    メインテーブルの置き換え: 置き換え

サブネット 2 とルートテーブル B の関連付けを解除しても、サブネット 2 とルートテーブル B との間の暗示的な関連付けは残ります。不要になったルートテーブル A は削除できます。


                    メインテーブルの置き換え: 関連付け解除

ゲートウェイルートテーブル

ルートテーブルは、インターネットゲートウェイまたは仮想プライベートゲートウェイに関連付けることができます。ルートテーブルがゲートウェイに関連付けられている場合、ゲートウェイルートテーブルと呼ばれます。ゲートウェイルートテーブルを作成して、VPC に入るトラフィックのルーティングパスを細かく制御できます。たとえば、インターネットゲートウェイを介して VPC に入るトラフィックを VPC 内のミドルボックスアプライアンス (セキュリティアプライアンスなど) にリダイレクトして、そのトラフィックをインターセプトできます。

ゲートウェイルートテーブルは、ターゲットがミドルボックスアプライアンスにアタッチされた VPC 内の local (デフォルトのローカルルート) または Elastic Network Interface (ネットワークインターフェイス) の場合、ルートをサポートします。ターゲットがネットワークインターフェイスの場合、次の宛先が許可されます。

  • VPC の IPv4 または IPv6 の CIDR ブロック全体。この場合、デフォルトのローカルルートのターゲットを置き換えます。

  • VPC 内のサブネットの IPv4 または IPv6 CIDR ブロック全体。これは、デフォルトのローカルルートよりも具体的なルートです。

ゲートウェイルートテーブルのローカルルートのターゲットを VPC のネットワークインターフェイスに変更した場合、後でデフォルトの local ターゲットに復元できます。詳細については、「ローカルルートのターゲットの置き換えと復元」を参照してください。

次のゲートウェイルートテーブルでは、172.31.0.0/20 CIDR ブロックを持つサブネット宛てのトラフィックは、特定のネットワークインターフェイスにルーティングされます。VPC 内の他のすべてのサブネット宛てのトラフィックは、ローカルルートを使用します。

送信先 Target
172.31.0.0/16 ローカル
172.31.0.0/20 eni-id

次のゲートウェイルートテーブルでは、ローカルルートのターゲットがネットワークインターフェイス ID に置き換えられます。VPC 内のすべてのサブネット宛てのトラフィックは、ネットワークインターフェイスにルーティングされます。

送信先 Target
172.31.0.0/16 eni-id

ルールと考慮事項

次のいずれかに該当する場合、ルートテーブルをゲートウェイに関連付けることはできません。

  • ルートテーブルには、ネットワークインターフェイスまたはデフォルトのローカルルート以外のターゲットを持つ既存のルートが含まれています。

  • ルートテーブルには、VPC の範囲外の CIDR ブロックへの既存のルートが含まれます。

  • ルートテーブルに対してルート伝達が有効です。

さらに、次のルールと考慮事項が適用されます。

  • 個々の VPC CIDR ブロックより大きい範囲も含め、VPC の範囲外の CIDR ブロックにルートを追加することはできません。

  • ターゲットとして指定できるのは、local またはネットワークインターフェイスのみです。個々のホスト IP アドレスを含む他のタイプのターゲットは指定できません。

  • プレフィックスリストを送信先として指定することはできません。

  • ゲートウェイルートテーブルを使用して、VPC 外のトラフィック(アタッチされたトランジットゲートウェイを通過するトラフィックなど)を制御またはインターセプトすることはできません。VPC に入るトラフィックをインターセプトし、同じ VPC 内の別のターゲットにのみリダイレクトできます。

  • トラフィックがミドルボックスアプライアンスに到達するようにするには、ターゲットネットワークインターフェイスを実行中のインスタンスにアタッチする必要があります。インターネットゲートウェイを流れるトラフィックの場合、ターゲットネットワークインターフェイスにはパブリック IP アドレスも必要です。

  • ミドルボックスアプライアンスを設定するときは、アプライアンスに関する考慮事項に注意してください。

  • ミドルボックスアプライアンスを介してトラフィックをルーティングする場合、宛先サブネットからのリターントラフィックを同じアプライアンスを介してルーティングする必要があります。非対称ルーティングはサポートされていません。

セキュリティアプライアンスのルーティングの例については、「VPC でのミドルボックスアプライアンスのルーティング」を参照してください。

ルーティングの優先度

AWS では、トラフィックと一致する最も具体的なルートをルートテーブルで使用して、トラフィックをルーティングする方法を決定します (最長プレフィックス一致)。

IPv4 および IPv6 アドレスまたは CIDR ブロックへのルートは、互いに独立しています。IPv4 トラフィックまたは IPv6 トラフィックのいずれかに一致する最も具体的なルートを使用して、トラフィックのルーティング方法を決定します。

たとえば、次のサブネットルートテーブルには、インターネットゲートウェイを指す IPv4 インターネットトラフィック (0.0.0.0/0) のルートと、ピアリング接続 (pcx-11223344556677889) を指す IPv4 トラフィック (172.31.0.0/16) のルートが含まれます。172.31.0.0/16 IP アドレス範囲あてのサブネットからのトラフィックでは、ピアリング接続が使用されます。このルートはインターネットゲートウェイのルートよりも制限が高いためです。VPC 内のターゲットに向けられたすべてのトラフィック (10.0.0.0/16) には Local ルートが適用されるため、VPC 内でルーティングされます。サブネットからのその他のすべてのトラフィックでは、インターネットゲートウェイが使用されます。

送信先 ターゲット
10.0.0.0/16 ローカル
172.31.0.0/16 pcx-11223344556677889
0.0.0.0/0 igw-12345678901234567

仮想プライベートゲートウェイを VPC にアタッチし、サブネットルートテーブルでルート伝達を有効にしている場合は、Site-to-Site VPN 接続を表すルートが伝達済みルートとしてルートテーブルに自動的に表示されます。伝達されたルートが静的ルートと重複し、最長プレフィクス一致を適用できない場合、伝達されたルートよりも静的ルートが優先されます。詳細については、AWS Site-to-Site VPN ユーザーガイド の「ルートテーブルと VPN ルートの優先度」を参照してください。

この例の場合、ルートテーブルにはインターネットゲートウェイへの(手動で追加した)静的ルート、および仮想プライベートゲートウェイへの伝達されたルートがあります。両方のルートとも、宛先は 172.31.0.0/24 です。この場合、172.31.0.0/24 を宛先とするすべてのトラフィックはインターネットゲートウェイにルーティングされます。これは静的ルートであるため、伝達されたルートよりも優先順位が高くなります。

送信先 ターゲット
10.0.0.0/16 ローカル
172.31.0.0/24 vgw-11223344556677889(伝達済み)
172.31.0.0/24 igw-12345678901234567(静的)

ルートテーブルに次のいずれかへの静的ルートが含まれている場合も、同じルールが適用されます。

  • NAT ゲートウェイ

  • ネットワークインターフェイス

  • インスタンス ID

  • ゲートウェイ VPC エンドポイント

  • 転送ゲートウェイ

  • VPC ピア接続

静的ルートと伝達されたルートの宛先が同じ場合、静的ルートが優先されます。

プレフィックスリストのルーティング優先度

ルートテーブルでプレフィックスリストが参照されている場合は、次のルールが適用されます。

  • ルートテーブルに、プレフィックスリストを参照する別のルートと重複する静的ルートが含まれている場合、送信先 CIDR ブロックを指定したスタティックルートが優先されます。

  • 伝播されたルートがルートテーブルに含まれていて、プレフィックスリストを参照するルートと重複する場合は、プレフィックスリストを参照するルートが優先されます。

  • ルートテーブルで複数のプレフィックスリストが参照されていて、異なるターゲットへの CIDR ブロックが重複する場合、優先されるルートはランダムに選択されます。その後は、同じルートが常に優先されます。

  • プレフィックスリストエントリ内の CIDR ブロックがルートテーブルに対して有効でない場合、その CIDR ブロックは無視されます。たとえば、サブネットルートテーブルで、プレフィックスリストに VPC CIDR よりも具体的な CIDR を指定したエントリが含まれている場合、そのエントリは無視されます。