ルートテーブルを設定する - Amazon Virtual Private Cloud
ルートテーブルの概念サブネットルートテーブルゲートウェイルートテーブルルーティングの優先度ルートテーブルのクォータ到達可能性に関する問題のトラブルシューティング

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ルートテーブルを設定する

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

コンテンツ

ルートテーブルの概念

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

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

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

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

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

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

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

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

  • 伝達 – VPC に仮想プライベートゲートウェイをアタッチし、ルート伝達を有効にすると、サブネットルートテーブルへの VPN 接続のルートが自動的に追加されます。これは、VPN ルートを手動で追加または削除する必要がないことを意味します。詳細については、「Site-to-Site VPN ユーザーガイド」の「Site-to-Site VPN のルーティングオプション」を参照してください。

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

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

  • Transit Gateway ルートテーブル — Transit Gateway に関連付けられているルートテーブル。詳細については、「Amazon VPC Transit Gateway」の「Transit Gateway ルートテーブル」を参照してください。

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

サブネットルートテーブル

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

ルート

テーブル内の各ルートは、送信先とターゲットを指定します。例えば、サブネットがインターネットゲートウェイ経由でインターネットにアクセスできるようにするには、サブネットルートテーブルに次のルートを追加します。ルートの送信先は 0.0.0.0/0 です。これは、すべての IPv4 アドレスを表します。ターゲットは、VPC にアタッチされているインターネットゲートウェイです。

デスティネーション ターゲット
0.0.0.0/0 igw-id

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

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

各ルートテーブルには、VPC 内で通信を有効にするローカルルートが含まれます。このルートは、デフォルトですべてのルートテーブルに追加されます。VPC に複数の IPv4 CIDR ブロックがある場合、ルートテーブルには各 IPv4 CIDR ブロックのローカルルートが含まれます。IPv6 CIDR ブロックを VPC に関連付けた場合、ルートテーブルには IPv6 CIDR ブロックのローカルルートが含まれます。必要に応じて、各ローカルルートのターゲットを置き換えまたは復元できます。

ルールと考慮事項

  • ローカルルートよりも具体的なルートを追加できます。送信先は、VPC 内のサブネットの IPv4 または IPv6 CIDR ブロック全体と一致する必要があります。ターゲットは、NAT ゲートウェイ、ネットワークインターフェイス、Gateway Load Balancer エンドポイントである必要があります。

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

  • 完全一致、または次の範囲のサブセットである IPv4 アドレスにルートを追加することはできません: 169.254.168.0/22。この範囲はリンクローカルアドレス空間内にあり、 AWS のサービス用に予約されています。例えば、Amazon EC2 は、Instance Metadata Service (IMDS) や Amazon DNS サーバーなどの EC2 インスタンスからのみアクセスできるサービスに、この範囲のアドレスを使用します。より大きいが 169.254.168.0/22 と重複する CIDR ブロックを使用できますが、169.254.168.0/22 のアドレスを送信先とするパケットは転送されません。

  • 完全一致、または次の範囲のサブセットである IPv6 アドレスにルートを追加することはできません: fd00:ec2::/32。この範囲は、一意のローカルアドレス (ULA) スペース内にあり、 AWS のサービス用に予約されています。例えば、Amazon EC2 は、Instance Metadata Service (IMDS) や Amazon DNS サーバーなどの EC2 インスタンスからのみアクセスできるサービスに、この範囲のアドレスを使用します。より大きいが fd00:ec2::/32 と重複する CIDR ブロックを使用できますが、fd00:ec2::/32 のアドレスを宛先とするパケットは転送されません。

  • ミドルボックスアプライアンスを VPC のルーティングパスに追加できます。詳細については、「ミドルボックスアプライアンスのルーティング」を参照してください。

例

以下の図では、VPC に IPv4 CIDR ブロックとIPv6 CIDR ブロックの両方があります。IPv4 トラフィックと IPv6 トラフィックは、次のルートテーブルに示すように別々に扱われます。

デスティネーション ターゲット
10.0.0.0/16 Local
2001:db8:1234:1a00::/56 Local
172.31.0.0/16 pcx-11223344556677889
0.0.0.0/0 igw-12345678901234567
::/0 eigw-aabbccddee1122334

  • VPC (10.0.0.0/16) 内でルーティングされる IPv4 トラフィックは Local ルートの対象となります。

  • VPC 内でルーティングされる IPv6 トラフィック (2001:db8:1234:1a00::/56) は Local ルートの対象となります。

  • 172.31.0.0/16 のルートは、トラフィックをピアリング接続に送信します。

  • すべての IPv4 トラフィック (0.0.0.0/0) のルートは、トラフィックをインターネットゲートウェイに送信します。そのため、VPC 内のトラフィックとピアリング接続へのトラフィックを除くすべての IPv4 トラフィックは、インターネットゲートウェイにルーティングされます。

  • すべての IPv6 トラフィックのルート (::/0) は、トラフィックを Egress-Only インターネットゲートウェイに送信します。そのため、VPC 内のトラフィックを除く IPv6 トラフィックはすべて、Egress-Only インターネットゲートウェイにルーティングされます。

メインルートテーブル

VPC を作成するときに、メインルートテーブルが自動的に割り当てられます。サブネットに明示的なルーティングテーブルが関連付けられていない場合、デフォルトではメインのルーティングテーブルが使用されます。Amazon VPC コンソールの [ルートテーブル] ページで、[メイン] 列の [はい] を探すことによって VPC のメインルートテーブルを表示できます。

デフォルトでは、デフォルト以外の VPC を作成すると、メインルートテーブルにはローカルルートのみが含まれます。「VPC を作成する」NAT ゲートウェイを選択すると、Amazon VPC はゲートウェイのメインルートテーブルにルートを自動的に追加します。

メインルートテーブルには、次のルールが適用されます。

  • メインルートテーブルで、ルートを追加、削除、変更することができます。

  • メインルートテーブルを削除することはできません。

  • ゲートウェイルートテーブルをメインルートテーブルとして設定することはできません。

  • メインルートテーブルを置き換えるには、カスタムルートテーブルをサブネットに関連付けます。

  • すでに暗黙的に関連付けられている場合でも、サブネットをメインルートテーブルに明示的に関連付けることができます。

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

カスタムルートテーブル

デフォルトでは、ルートテーブルには VPC 内で通信を有効にするローカルルートが含まれます。パブリックサブネットを 「VPC を作成する」 および選択すると、Amazon VPC によってカスタムルートテーブルが作成され、インターネットゲートウェイを指すルートが追加されます。VPC を保護する 1 つの方法は、メインルートテーブルを元のデフォルトの状態のままにすることです。次に、作成するそれぞれの新しいサブネットが、作成したカスタムルートテーブルの 1 つに明示的に関連付けられます。これにより、各サブネットがトラフィックをルーティングする方法を明示的にコントロールします。

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

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

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

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

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

次の図は、インターネットゲートウェイ、仮想プライベートゲートウェイ、パブリックサブネット、および VPN のみのサブネットを持つ VPC のルーティングを示しています。

メインルートテーブルはプライベートサブネットに暗黙的に関連付けられ、カスタムルートテーブルはパブリックサブネットに明示的に関連付けられます。

ルートテーブル A はカスタムルートテーブルで、パブリックサブネットに明示的に関連付けられています。すべてのトラフィックをインターネットゲートウェイに送信するルートがあり、それによりサブネットはパブリックサブネットになります。

デスティネーション ターゲット
VPC CIDR ローカル
0.0.0.0/0 igw-id

ルートテーブル B は、メインルートテーブルです。プライベートサブネットに暗黙的に関連付けられています。すべてのトラフィックを仮想プライベートゲートウェイに送信するルートがありますが、インターネットゲートウェイには送信しないため、サブネットは VPN のみのサブネットになります。この VPC に別のサブネットを作成し、カスタムルートテーブルを関連付けない場合、そのサブネットはメインルートテーブルであるため、このルートテーブルにも暗黙的に関連付けられます。

デスティネーション ターゲット
VPC CIDR ローカル
0.0.0.0/0 vgw-id
例 2: メインルートテーブルを置き換える

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

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

メインルートテーブルであるルートテーブル A と暗黙的に関連付けられた 2 つのサブネット。

メインルートテーブルを置き換えるには、まずサブネット B とルートテーブル B の間に明示的な関連付けを作成します。ルートテーブル B をテストします。

サブネット B は、カスタムルートテーブルであるルートテーブル B に明示的に関連付けられるようになりました。

ルートテーブル B をテスト後、そのテーブルをメインルートテーブルにします。サブネット B とルートテーブル B との間には、まだ明示的な関連付けがあります。ただし、ルートテーブル B が新しいメインルートテーブルであるため、サブネット A とルートテーブル B の間には暗黙的な関連付けができます。ルートテーブル A はいずれのサブネットにも関連付けられていない状態となりました。

サブネット A はメインルートテーブルであるルートテーブル B に暗黙的に関連付けられていますが、サブネット B は引き続きルートテーブル B に明示的に関連付けられています。

(オプション) サブネット B とルートテーブル B の関連付けを解除しても、サブネット B とルートテーブル B との間の暗黙的な関連付けは残ります。ルートテーブル A が必要なくなった場合は削除できます。

サブネットは両方ともルートテーブル B に暗黙的に関連付けられています。

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

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

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

インターネットゲートウェイに関連付けられたゲートウェイルートテーブルは、次のターゲットを持つルートをサポートします。

仮想プライベートゲートウェイに関連付けられたゲートウェイルートテーブルは、次のターゲットを持つルートをサポートします。

ターゲットが Gateway Load Balancer エンドポイントまたはネットワークインターフェイスの場合、次の送信先が許可されます。

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

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

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

例

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

送信先 ターゲット
172.31.0.0/16 ローカル
172.31.0.0/20 eni-id
例

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

送信先 ターゲット
172.31.0.0/16 eni-id

ルールと考慮事項

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

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

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

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

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

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

  • ターゲットとして指定できるのは、local、Gateway Load Balancer のエンドポイント、またはネットワークインターフェイスのみです。個々のホスト IP アドレスを含む他のタイプのターゲットは指定できません。詳細については、「ルーティングオプションの例」を参照してください。

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

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

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

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

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

  • ルートテーブルルールは、サブネットから出るすべてのトラフィックに適用されます。サブネットから出るトラフィックは、そのサブネットのゲートウェイルーターの MAC アドレスを送信先とするトラフィックとして定義されます。サブネット内の別のネットワークインターフェイスの MAC アドレスを送信先とするトラフィックは、ネットワーク（レイヤ 3）ではなくデータリンク（レイヤ 2）ルーティングを使用するため、このトラフィックにはルールが適用されません。

  • すべてのLocal Zones が仮想プライベートゲートウェイとのエッジ関連付けをサポートしているわけではありません。使用可能なゾーンの詳細については、「AWS Local Zones ユーザーガイド」の「考慮事項」を参照してください。

ルーティングの優先度

一般的に、トラフィックと一致する最も具体的なルートを使用してトラフィックを誘導します。これは、プレフィックスの最長一致と呼ばれます。ルートテーブルに重複または一致するルートがある場合は、追加のルールが適用されます。

最長のプレフィックスの一致

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

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

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

ルートプライオリティと伝播ルート

仮想プライベートゲートウェイを VPC にアタッチし、サブネットルートテーブルでルート伝達を有効にしている場合は、Site-to-Site VPN 接続を表すルートが伝達済みルートとしてルートテーブルに自動的に表示されます。

伝播ルートの送信先が静的ルートと重複する場合、静的ルートが優先されます。

伝播ルートの送信先が静的ルートの送信先と同じ場合、ターゲットが次のいずれかであれば、静的ルートが優先されます。

  • インターネットゲートウェイ

  • NAT ゲートウェイ

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

  • インスタンス ID

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

  • トランジットゲートウェイ

  • VPC ピア接続

  • Gateway Load Balancer エンドポイント

詳細については、AWS Site-to-Site VPN ユーザーガイドの「ルートテーブルと VPN ルーティングの優先度」を参照してください。

次のルートテーブルの例にはインターネットゲートウェイへの静的ルート、および仮想プライベートゲートウェイへの伝播されたルートがあります。両方のルートとも、送信先は 172.31.0.0/24 です。インターネットゲートウェイへの静的ルートが優先されるため、172.31.0.0/24 のすべてのトラフィックがインターネットゲートウェイにルーティングされます。

デスティネーション ターゲット 伝播済み
10.0.0.0/16 local いいえ
172.31.0.0/24 vgw-11223344556677889 はい
172.31.0.0/24 igw-12345678901234567 いいえ

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

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

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

  • 伝播されたルートがルートテーブルに含まれていて、プレフィックスリストを参照するルートと一致する場合は、プレフィックスリストを参照するルートが優先されます。重複するルートについては、伝播されたルート、静的ルート、またはプレフィクスリストを参照するルートであるかどうかにかかわらず、より具体的なルートが常に優先されることに注意してください。

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

ルートテーブルのクォータ

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

到達可能性に関する問題のトラブルシューティング

Reachability Analyzer は、静的な設定分析ツールです。Reachability Analyzer を使用して、VPC 内の 2 つのリソース間のネットワーク到達可能性を分析し、デバッグします。Reachability Analyzer は、到達可能なときにこれらのリソース間の仮想パス hop-by-hop の詳細を生成し、それ以外の場合はブロッキングコンポーネントを識別します。例えば、ルートテーブルのルートが見つからない場合や設定が間違っている場合などです。

詳細については、「Reachability Analyzer Guide」(到達可能性アナライザーガイド) を参照してください。