# サブネットのルートテーブル VPC には暗黙的なルーターがあり、ルートテーブルを使用してネットワークトラフィックの送信先を制御します。VPC の各サブネットをルートテーブルに関連付ける必要があり、ルートテーブルはサブネットのルーティング（サブネットルートテーブル）を制御します。サブネットを特定のルートテーブルに明示的に関連付けることができます。それ以外の場合、サブネットはメインルートテーブルに暗黙的に関連付けられます。1 つのサブネットは同時に 1 つのルートテーブルにしか関連付けることはできませんが、複数のサブネットを同じサブネットルートテーブルに関連付けることはできます。 **Topics** + [ルート](#route-table-routes) + [メインルートテーブル](#main-route-table) + [カスタムルートテーブル](#custom-route-tables) + [サブネットとルートテーブルの関連付け](#route-table-assocation) ## ルート テーブル内の各ルートは、送信先とターゲットを指定します。例えば、サブネットがインターネットゲートウェイ経由でインターネットにアクセスできるようにするには、サブネットルートテーブルに次のルートを追加します。ルートの送信先は `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 ブロックのセットを頻繁に参照する場合は、[カスタマーマネージドプレフィックスリスト](managed-prefix-lists.md)を作成して、それらをグループ化できます。その後、ルートテーブルエントリの送信先としてプレフィックスリストを指定できます。 各ルートテーブルには、VPC 内で通信を有効にするローカルルートが含まれます。このルートは、デフォルトですべてのルートテーブルに追加されます。VPC に複数の IPv4 CIDR ブロックがある場合、ルートテーブルには各 IPv4 CIDR ブロックのローカルルートが含まれます。IPv6 CIDR ブロックを VPC に関連付けた場合、ルートテーブルには IPv6 CIDR ブロックのローカルルートが含まれます。必要に応じて、各ローカルルートのターゲットを[置き換えまたは復元](replace-local-route-target.md)できます。 **ルールと考慮事項** + ローカルルートよりも具体的なルートを追加できます。送信先は、VPC 内のサブネットの IPv4 または IPv6 CIDR ブロック全体と一致する必要があります。ターゲットは、NAT ゲートウェイ、ネットワークインターフェイス、Gateway Load Balancer エンドポイントである必要があります。 + ルートテーブルに複数のルートがある場合、トラフィックと一致する (最長プレフィックス一致) 最も明確なルートを使用して、トラフィックをルーティングする方法を決定します。 + 完全一致、または次の範囲のサブセットである IPv4 アドレスにルートを追加することはできません: 169.254.168.0/22。この範囲はリンクローカルアドレススペース内にあり、AWS のサービスで使用するために予約されています。例えば、Amazon EC2 は、インスタンスメタデータサービス (IMDS) や Amazon DNS サーバーなどの EC2 インスタンスからのみアクセスできるサービスに、この範囲のアドレスを使用します。より大きいが 169.254.168.0/22 と重複する CIDR ブロックを使用できますが、169.254.168.0/22 のアドレスを送信先とするパケットは転送されません。 + 完全一致、または次の範囲のサブセットである IPv6 アドレスにルートを追加することはできません: fd00:ec2::/32。この範囲は一意のローカルアドレス (ULA) スペース内にあり、AWS のサービスで使用するために予約されています。例えば、Amazon EC2 は、インスタンスメタデータサービス (IMDS) や Amazon DNS サーバーなどの EC2 インスタンスからのみアクセスできるサービスに、この範囲のアドレスを使用します。より大きいが fd00:ec2::/32 と重複する CIDR ブロックを使用できますが、fd00:ec2::/32 のアドレスを宛先とするパケットは転送されません。 + ミドルボックスアプライアンスを VPC のルーティングパスに追加できます。詳細については、「[ミドルボックスアプライアンスのルーティング](route-table-options.md#route-tables-appliance-routing)」を参照してください。 **例** 以下の図では、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 を作成する](create-vpc.md)NAT ゲートウェイを選択すると、Amazon VPC はゲートウェイのメインルートテーブルにルートを自動的に追加します。 メインルートテーブルには、次のルールが適用されます。 + メインルートテーブルで、ルートを追加、削除、変更することができます。 + メインルートテーブルを削除することはできません。 + ゲートウェイルートテーブルをメインルートテーブルとして設定することはできません。 + メインルートテーブルを置き換えるには、カスタムルートテーブルをサブネットに関連付けます。 + すでに暗黙的に関連付けられている場合でも、サブネットをメインルートテーブルに明示的に関連付けることができます。 この作業は、メインルートテーブルにするテーブルを変更するときに行います。メインルートテーブルであるテーブルを変更する場合、これにより、新しい追加のサブネット、または他のルートテーブルに明示的に関連付けられていないサブネットのデフォルトも変更されます。詳細については、「[メインルートテーブルの置換](Route_Replacing_Main_Table.md)」を参照してください ## カスタムルートテーブル デフォルトでは、ルートテーブルには VPC 内で通信を有効にするローカルルートが含まれます。パブリックサブネットを [VPC を作成する](create-vpc.md) および選択すると、Amazon VPC によってカスタムルートテーブルが作成され、インターネットゲートウェイを指すルートが追加されます。VPC を保護する 1 つの方法は、メインルートテーブルを元のデフォルトの状態のままにすることです。次に、作成するそれぞれの新しいサブネットが、作成したカスタムルートテーブルの 1 つに明示的に関連付けられます。これにより、各サブネットがトラフィックをルーティングする方法を明示的にコントロールします。 カスタムルートテーブルで、ルートを追加、削除、変更することができます。カスタムルートテーブルは、関連付けがない場合にのみ削除できます。 ## サブネットとルートテーブルの関連付け VPC 内の各サブネットは、ルートテーブルと関連付ける必要があります。サブネットは、カスタムルートテーブルに明示的に関連付けることも、メインルートテーブルに暗黙的または明示的に関連付けることもできます。サブネットとルートテーブルの関連付けの表示の詳細については、「[明示的な関連付けを判断する](WorkWithRouteTables.md#Route_Which_Associations)」を参照してください。 Outposts に関連付けられた VPC 内のサブネットには、ローカルゲートウェイの追加ターゲットタイプを設定できます。これは、Outposts 以外のサブネットとの唯一のルーティングの違いです。 **例 1: 暗黙的および明示的なサブネットの関連付け** 次の図は、インターネットゲートウェイ、仮想プライベートゲートウェイ、パブリックサブネット、および VPN のみのサブネットを持つ VPC のルーティングを示しています。 ![\[メインルートテーブルに関連付けられたプライベートサブネットと、カスタムルートテーブルを含むパブリックサブネットの図\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/subnet-association.png) ルートテーブル 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 つのサブネット。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/replace-route-table-initial.png) メインルートテーブルを置き換えるには、まずサブネット B とルートテーブル B の間に明示的な関連付けを作成します。ルートテーブル B をテストします。 ![\[サブネット B は、カスタムルートテーブルであるルートテーブル B に明示的に関連付けられるようになりました。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/replace-route-table-step1.png) ルートテーブル B をテスト後、そのテーブルをメインルートテーブルにします。サブネット B とルートテーブル B との間には、まだ明示的な関連付けがあります。ただし、ルートテーブル B が新しいメインルートテーブルであるため、サブネット A とルートテーブル B の間には暗黙的な関連付けができます。ルートテーブル A はいずれのサブネットにも関連付けられていない状態となりました。 ![\[メインルートテーブル B に関連付けられたサブネット A と、ルートテーブル B に関連付けられたサブネット B の図\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/replace-route-table-step2.png) (オプション) サブネット B とルートテーブル B の関連付けを解除しても、サブネット B とルートテーブル B との間の暗黙的な関連付けは残ります。ルートテーブル A が必要なくなった場合は削除できます。 ![\[サブネットは両方ともルートテーブル B に暗黙的に関連付けられています。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/replace-route-table-step3.png)