Virtual Private Cloud:VPC ルートテーブル

ルートテーブル

VPC を作成すると、システムルートテーブルが自動的に作成されます。デフォルトでは、VPC 内のすべての vSwitch にアタッチされ、ネットワークトラフィックを制御します。

VPC 内の異なる ECS インスタンスが、異なるネットワークパスを介して同じ宛先 CIDR ブロックにトラフィックを送信する必要がある場合は、カスタムルートテーブルを使用できます。ECS インスタンスを異なる vSwitch にデプロイし、それぞれに専用のカスタムルートテーブルをアタッチすることで、きめ細やかなトラフィック制御が可能になります。

セルフマネージドファイアウォールを介してインバウンドのパブリックトラフィックを転送するには、ゲートウェイルートテーブルを使用できます。ゲートウェイルートテーブルは、IPv4/IPv6 ゲートウェイにアタッチされたカスタムルートテーブルです。この設定により、インバウンドトラフィックがファイアウォールに転送され、統一されたフィルタリング、監査、およびセキュリティポリシーの適用が可能になります。

この表は、これらのルートテーブルのタイプを比較したものです。

各 vSwitch は、必ず 1 つのルートテーブルに関連付ける必要があります。ただし、1 つのルートテーブルを複数の vSwitch に関連付けることはできます。

1. 静的ルート

システムによって自動的に追加されるか、ユーザーが手動で追加する静的ルートには、次の 2 種類があります。

• システムルート：ネクストホップが Local のルートで、VPC と vSwitch を作成する際にシステムによって自動的に追加されます。これらのルートは、VPC 内のインスタンス間の通信やクラウドサービスへのアクセスに使用されます。

• カスタムルート：トラフィック転送パスをカスタマイズするために手動で追加するルート。

次の図は、2 つの VPC が VPC ピアリング接続を介して接続されている例を示しています。VPC1 のシステムルートテーブルには、次の静的ルートが含まれています。

1. VPC と vSwitch を作成すると、システムはネクストホップが Local のシステムルートを自動的に追加します。

   1. クラウドサービスルート：宛先 CIDR ブロックは 100.64.0.0/10 です。このルートは、VPC1 内のインスタンスがクラウドサービスにアクセスするために使用されます。

   2. vSwitch ルート：宛先 CIDR ブロックは 10.0.0.0/24 です。このルートにより、VPC1 内の vSwitch 間でプライベート通信が可能になります。

2. VPC ピアリング接続を作成した後、次のカスタムルートを手動で追加する必要があります。

   宛先 CIDR ブロックは 172.16.0.0/16 で、ネクストホップは VPC ピアリング接続です。このルートは、VPC2 宛てのトラフィックを VPC ピアリング接続に転送します。

VPC2 のシステムルートテーブル内のルートエントリは、VPC1 と同じ原則に従うため、ここでは詳述しません。

2. 動的ルート

動的ルートは、他のネットワークインスタンスから VPC に伝播されるルートです。静的ルートとは異なり、VPC ルートテーブルで手動で設定する必要はありません。代わりに、動的ルートソースから自動的に受信および更新されます。

ルートの優先度

VPC ルートテーブル内のルートは、次のルールに基づいて優先順位が付けられます。

• ルートエントリの宛先 CIDR ブロックが重複する場合：

  IPv4 と IPv6 のトラフィックは独立してルーティングされます。システムは最長プレフィックス一致ルールを使用して、宛先 IP アドレスに一致する最も具体的なルートを選択します。このルートがトラフィックのネクストホップを決定します。

  最長プレフィックス一致：複数のルートエントリの宛先 CIDR ブロックがパケットの宛先 IP アドレスと一致する場合、システムはサブネットマスクが最も長い (最も具体的な範囲の) ルートを選択します。たとえば、192.168.1.100 宛てのトラフィックは、192.168.0.0/16 ルートではなく、192.168.1.0/24 ルートに一致します。

• 新しいルートエントリが既存のルートエントリと重複する場合：

  アクション	既存のシステムルート	既存のカスタムルート	既存の動的ルート
  vSwitch の作成	vSwitch の CIDR ブロックは、既存のシステムルートの CIDR ブロックと重複できません。	vSwitch の CIDR ブロックでは、次のことはできません。 既存のカスタムルートの宛先 CIDR ブロックと同一であること。 既存のカスタムルートの宛先 CIDR ブロックを含むこと。	vSwitch の CIDR ブロックは、以下と重複できません。 既存の動的ルートの宛先 CIDR ブロックと同一であること。 既存の動的ルートの宛先 CIDR ブロックを含むこと。
  カスタムルートの追加	新しいカスタムルートの宛先 CIDR ブロックは、次のように指定できません。 既存のシステムルートの CIDR ブロックと同一であること。 VPC 内通信のための既存のシステムルートよりも具体的であること。	新しいカスタムルートの宛先 CIDR ブロックは、既存のカスタムルートの宛先 CIDR ブロックと同一にすることはできません。 ネクストホップタイプが ルーターインターフェイス (VBR 向け) の場合、アクティブ/スタンバイルートまたは ECMP ルートを設定できます。詳細については、「ルーターインターフェイスへのルート」をご参照ください。	新しいカスタムルートの宛先 CIDR ブロックは、既存の動的ルートの宛先 CIDR ブロックと同一にすることはできません。 新しいカスタムルートのネクストホップが VPN ゲートウェイまたはルーターインターフェイスであり、CEN からの既存の動的ルートが同じ宛先 CIDR ブロックを持つ場合、動的ルートは取り消され、カスタムルートが有効になります。
  動的ルートの受信	既存のシステムルートの宛先 CIDR ブロックと同一にすることはできません。 動的ルートが既存のシステムルートよりも具体的な場合、動的ルートは有効になりません。 動的ルートソースが ECR の場合、ルートは VPC ルートテーブルに Candidate ステータスで表示され、転送には使用されません。 動的ルートソースが VPN ゲートウェイ、TR Enterprise Edition、または TR Basic Edition の場合、ルートは VPC ルートテーブルに伝播されません。	動的ルートの宛先 CIDR ブロックが既存のカスタムルートの宛先 CIDR ブロックと同一の場合、動的ルートは有効になりません。 動的ルートソースが ECR の場合、ルートは VPC ルートテーブルに Candidate ステータスで表示され、転送には使用されません。 動ルートソースが VPN ゲートウェイ、TR Enterprise Edition、または TR Basic Edition の場合、ルートは VPC ルートテーブルに伝播されません。 カスタムルートが削除されると、動的ルートは自動的に有効になります。	適用されません。VPC ルートテーブルは 単一のルート伝播ソースのみをサポートします。

ルートテーブルの作成と削除

ターゲットの vSwitch、IPv4 ゲートウェイ、または IPv6 ゲートウェイに関連付ける前に、カスタムルートテーブルを作成する必要があります。

variable "name" {
  default = "terraform-example"
}

resource "alicloud_vpc" "defaultVpc" {
  vpc_name = var.name
}


resource "alicloud_route_table" "default" {
  description      = "test-description"
  vpc_id           = alicloud_vpc.defaultVpc.id
  route_table_name = var.name
  associate_type   = "VSwitch"
}

ルートテーブルの関連付けと関連付け解除

新しいカスタムルートテーブルは、デフォルトではどのリソースにも関連付けられていません。有効にするには、vSwitch または IPv4/IPv6 ゲートウェイに関連付ける必要があります。

variable "name" {
  default = "terraform-example"
}

resource "alicloud_vpc" "foo" {
  cidr_block = "172.16.0.0/12"
  vpc_name   = var.name
}

data "alicloud_zones" "default" {
  available_resource_creation = "VSwitch"
}

resource "alicloud_vswitch" "foo" {
  vpc_id       = alicloud_vpc.foo.id
  cidr_block   = "172.16.0.0/21"
  zone_id      = data.alicloud_zones.default.zones[0].id
  vswitch_name = var.name
}

resource "alicloud_route_table" "foo" {
  vpc_id           = alicloud_vpc.foo.id
  route_table_name = var.name
  description      = "route_table_attachment"
}

resource "alicloud_route_table_attachment" "foo" {
  vswitch_id     = alicloud_vswitch.foo.id
  route_table_id = alicloud_route_table.foo.id
}

resource "alicloud_vpc" "example" {
  cidr_block = "172.16.0.0/12"
  vpc_name   = "terraform-example"
}

resource "alicloud_route_table" "example" {
  vpc_id           = alicloud_vpc.example.id
  route_table_name = "terraform-example"
  description      = "terraform-example"
  associate_type   = "Gateway"
}

resource "alicloud_vpc_ipv4_gateway" "example" {
  ipv4_gateway_name = "terraform-example"
  vpc_id            = alicloud_vpc.example.id
  enabled           = true
}

resource "alicloud_vpc_gateway_route_table_attachment" "example" {
  ipv4_gateway_id = alicloud_vpc_ipv4_gateway.example.id
  route_table_id  = alicloud_route_table.example.id
}

ルートエントリの追加と削除

vSwitch に関連付けられたルートテーブルにルートエントリを追加して、そのトラフィックを転送できます。これらはカスタムルートエントリと呼ばれます。

IPv4 ゲートウェイまたは IPv6 ゲートウェイに関連付けられたルートテーブルにルートエントリを追加することはできません。ただし、ルートエントリのネクストホップを変更することはできます。

resource "alicloud_route_entry" "foo" {
  route_table_id        = "rt-12345xxxx" # ルートテーブル ID を入力します。 
  destination_cidrblock = "172.16.1.1/32"
  nexthop_type          = "Instance" # ネクストホップタイプを入力します。 
  nexthop_id            = "i-12345xxxx" # ネクストホップインスタンス ID を入力します。 
}

ネクストホップの変更

ルートエントリのネクストホップを変更して、その宛先 CIDR ブロックのトラフィックをリダイレクトできます。

• システムルートエントリ：システムルートエントリがカスタムルートテーブル (ゲートウェイルートテーブルを含む) にある場合にのみ、そのネクストホップを変更できます。この変更により、システムルートエントリはカスタムルートエントリに変換されます。このカスタムルートエントリを削除すると、システムルートエントリに戻ります。

• カスタムルートエントリ：システムルートテーブルとカスタムルートテーブルの両方で、カスタムルートエントリのネクストホップを変更できます。

サポートされている宛先 CIDR ブロックとネクストホップのタイプについては、システムルートエントリとカスタムルートエントリの比較をご参照ください。

resource "alicloud_route_entry" "foo" {
  route_table_id        = "rt-12345xxxx" # ルートテーブル ID を入力します。 
  destination_cidrblock = "172.16.1.1/32"
  nexthop_type          = "Instance" # ネクストホップタイプを変更します。
  nexthop_id            = "i-12345xxxx" # ネクストホップインスタンス ID を入力します。 
}

静的ルートの公開と撤回

ルートテーブルから ECR または TR にルートを伝播できます。これを動的ルート受信と組み合わせることで、ルーティング設定が簡素化されます。

• ECR への静的ルートの公開：静的ルートを ECR に公開すると、ECR はそのルートをオンプレミスデータセンターに動的に伝播します。ルートの競合が存在しない場合、ECR に関連付けられているすべてのオンプレミスデータセンターがそのルートを学習できます。

  原則、制限、および例

  仕組み

  • VPC を ECR に関連付けると、そのシステムルートエントリはデフォルトで ECR に公開されます。

  • 静的ルートが ECR に公開された後：

    • ECR はルートを関連付けられた VBR に伝播します。VBR で BGP が有効になっている場合、VBR はルートをオンプレミスデータセンターに伝播します。

    • ECR は、関連付けられている他の VPC にルートを伝播しません。

  • 公開された静的ルートエントリが既存のルートエントリと競合する場合、ECR の [ルートエントリ] タブでルートエントリを表示できます。そのステータスは [競合] と表示され、[アクティブ] にはなりません。

  制限事項

  • VPC のカスタムルートテーブルから ECR にルートエントリを公開することはできません。

  • 宛先 CIDR ブロックがプレフィックスリストである場合、ルートエントリを ECR に公開することはできません。

  • ネクストホップがルーターインターフェイス (VBR への) である ECMP ルートおよびアクティブ/スタンバイルートは、ECR に公開できません。VPC ルートが ECR に公開された後は、そのルートに対して ECMP ルートまたはアクティブ/スタンバイルートを設定できなくなります。

  • VPC ルートが ECR に公開された後、公開されたルートを変更したい場合、そのネクストホップは公開操作をサポートするルートタイプにのみ設定できます (次の表を参照)。

  • 次の表は、VPC 内のさまざまなタイプのルートエントリのデフォルトの公開ステータスを示し、ECR での公開および撤回操作をサポートするかどうかを示しています。

    テーブル

    ルートタイプ	所有インスタンス	デフォルトで公開	公開のサポート	サポートの撤回
    VPC システムルートエントリ	VPC	はい	はい	マレーシア (クアラルンプール) でのみサポート
    IPv4 ゲートウェイへのルートエントリ	VPC	いいえ	はい	はい
    IPv6 ゲートウェイへのルートエントリ	VPC	いいえ	はい	はい
    NAT ゲートウェイへのルートエントリ	VPC	いいえ	はい	はい
    VPC ピアリング接続へのルートエントリ	VPC	いいえ	いいえ	いいえ
    TR へのルートエントリ	VPC	いいえ	いいえ	いいえ
    VPN ゲートウェイへのルートエントリ	VPC	いいえ	はい	はい
    ECS インスタンスへのルートエントリ	VPC	いいえ	はい	はい
    Elastic Network Interface へのルートエントリ	VPC	いいえ	はい	はい
    高可用性仮想 IP へのルートエントリ	VPC	いいえ	はい	はい
    ルーターインターフェイス (VBR への) へのルートエントリ	VPC	いいえ	いいえ	いいえ
    ルーターインターフェイス (VPC への) へのルートエントリ	VPC	いいえ	いいえ	いいえ
    ECR へのルートエントリ	VPC	いいえ	いいえ	いいえ
    Gateway Load Balancer エンドポイントへのルートエントリ	VPC	いいえ	はい	はい

  シナリオ例

  中国 (杭州) リージョンに VPC を持ち、オンプレミスデータセンターを持つ企業が、クラウドとオンプレミス間の安定した接続を確立し、オンプレミスデータセンターにデプロイされたサービスがインターネットにアクセスできるようにしたいと考えています。

  企業は VPC と VBR を ECR に接続できます。NAT ゲートウェイを作成し、それに EIP を関連付けた後、企業はルートを公開できます。ルートの競合が存在しない場合、ECR に関連付けられたオンプレミスデータセンターは、BGP を介して NAT ゲートウェイへのルートを学習し、インターネットにアクセスできるようになります。

• TR への静的ルートの公開：静的ルートが TR に公開されると、ルートの競合がなく、TR でルート同期が有効になっている場合、接続されているすべてのネットワークインスタンスがそのルートを学習できます。

VPC が ECR と TR の両方に接続されている場合、ECR へのルートの公開と TR へのルートの公開は、互いに影響しない独立したアクションです。

動的ルート受信の有効化/無効化

デフォルトでは、すべてのルートテーブルが動的ルートエントリを受信します。静的ルートのみのルーティング設定を使用したい場合は、各ルートテーブルで動的ルート受信を無効にできます。これにより、必要に応じてルート設定を柔軟に計画および管理できます。

1. 次のケースでは、この機能を無効にできます：動的ルートエントリのソースが [ルート伝播タイプ ECR] であるか、VPC に動的ルートが伝播されていない場合。動的ルートが伝播されていない場合、ルートテーブル詳細ページの [ルートエントリリスト] > [動的ルートエントリ] タブに [動的ルートエントリのソース] フィールドは表示されません。

   次のシナリオでは、動的ルート受信を無効にすることはできません：VPC が Basic Edition TR に接続されている。VPC が Enterprise Edition TR に接続されており、TR で VPC のルート同期が有効になっている。VPC が VPN ゲートウェイに関連付けられており、VPN ゲートウェイで自動ルート伝播が有効になっている。

2. この機能を無効にした場合の影響：

   • VPC ルートテーブルは、他のネットワークインスタンスからのルート伝播の受信を停止します。ルートテーブル内のすべての既存の動的ルートエントリは削除されます。注意して進めてください。

   • VPC を Basic Edition TR に接続することはできません。この VPC に接続された TR では、VPC のルート同期を有効にすることはできません。この VPC に関連付けられた VPN ゲートウェイでは、自動ルート伝播を有効にすることはできません。

3. この機能を再度有効にした場合の影響：

   この機能を再度有効にすると、VPC ルートテーブルは、動的ルートソースから現在伝播されているルートで更新されます。

   たとえば、ECR に 4 つの動的ルートエントリがあるとします。この機能を無効にすると、動的ルートエントリは VPC ルートテーブルからクリアされます。ECR にさらに 2 つのルートエントリが追加され、その後この機能を再度有効にすると、VPC ルートテーブルは ECR から 6 つの動的ルートエントリを受信します。

variable "name" {
  default = "terraform-example"
}

resource "alicloud_vpc" "defaultVpc" {
  vpc_name = var.name
}

resource "alicloud_route_table" "default" {
  description      = "test-description"
  vpc_id           = alicloud_vpc.defaultVpc.id
  route_table_name = var.name
  associate_type   = "VSwitch"
  route_propagation_enable = true # このパラメーターを true に設定すると動的ルート受信が有効になり、false に設定すると無効になります。 
}

セルフマネージドファイアウォールの使用

VPC 内の ECS インスタンスにセルフマネージドファイアウォールをデプロイし、ゲートウェイルートテーブルを使用して VPC に入るトラフィックをファイアウォールにリダイレクトしてフィルタリングすることができます。

GWLB の高可用性アーキテクチャ

Gateway Load Balancer (GWLB) を使用して、複数のセキュリティデバイスにトラフィックを分散させ、アプリケーションのセキュリティと可用性を向上させることができます。

IPv4 ゲートウェイへのルート

IPv4 ゲートウェイを、VPC とインターネット間のトラフィックの統一されたイングレスおよびエグレスポイントとして使用できます。IPv4 ゲートウェイとカスタムルートテーブルを組み合わせることで、一元化されたトラフィック制御、統合されたセキュリティポリシー、および監査が可能になり、分散アクセスによるセキュリティリスクを低減します。

IPv6 ゲートウェイへのルート

VPC で IPv6 を有効にすると、システムは自動的に次のルートをシステムルートテーブルに追加します：

• 宛先 CIDR ブロックは ::/0 で、ネクストホップは IPv6 ゲートウェイです。

このルートは、デフォルトの IPv6 トラフィックを IPv6 ゲートウェイに転送します。IPv6 アドレスのインターネット帯域幅を有効にすると、システムルートテーブルに関連付けられた vSwitch はインターネットと通信できるようになります。

カスタムルートテーブルに関連付けられている IPv6 対応の vSwitch の場合、IPv6 インターネットアクセスを有効にするには、前述のルートをカスタムルートテーブルに手動で追加する必要があります。

ネクストホップとして IPv6 ゲートウェイインスタンスを持つカスタムルートの場合、宛先 CIDR ブロックは ::/0 にのみ設定できます。

NAT Gateway へのルート

VPC 内の多くのサーバーがインターネットにアクセスし、多数のパブリック IP アドレスを消費する必要がある場合、インターネット NAT ゲートウェイの SNAT 機能を使用できます。SNAT を使用すると、複数の Elastic Compute Service (ECS) インスタンスが Elastic IP Address (EIP) を共有してインターネットにアクセスできます。これにより、パブリック IP リソースを節約し、ECS インスタンスのプライベート IP アドレスが公開されるのを防ぐことで、セキュリティを強化します。

NAT Gateway を使用する場合、インターネットアクセスを有効にするには、インターネット NAT ゲートウェイを指すカスタムルートを VPC ルートテーブルに追加する必要があります。

• ECS インスタンスが属する vSwitch がカスタムルートテーブルに関連付けられている場合、宛先 CIDR ブロックが 0.0.0.0/0 で、ネクストホップがインターネット NAT ゲートウェイであるルートを手動で追加する必要があります。

• ECS インスタンスが属する vSwitch がシステムルートテーブルに関連付けられている場合：

  • システムルートテーブルに宛先 CIDR ブロック 0.0.0.0/0 のルートが存在しない場合、システムは自動的にインターネット NAT ゲートウェイを指すルートを追加します。

  • システムルートテーブルに宛先 CIDR ブロック 0.0.0.0/0 のルートが既に存在する場合、既存のルートをインターネット NAT ゲートウェイを指す新しいルートに置き換える必要があります。

VPC ピアリング接続へのルート

デフォルトでは、VPC は互いに分離されています。VPC ピアリング接続を使用すると、異なるアカウントに属している場合や異なるリージョンにある場合でも、2 つの VPC 間でプライベート通信を有効にできます。ピアリング接続が確立されると、VPC 内のクラウドリソースは、プライベート IPv4 または IPv6 アドレスを使用して相互にアクセスできます。

トランジットルーターへのルート

Cloud Enterprise Network (CEN) を使用して VPC を接続する場合、トランジットルーターを指すルートを VPC ルートテーブルに追加する必要があります。次のいずれかの方法でルートを追加できます：

• VPC 接続を作成するときに、[トランジットルーターを指すルートを VPC のすべてのルートテーブルに自動的に追加する] を選択します。

  この機能を有効にすると、システムは宛先 CIDR ブロックが 10.0.0.0/8、172.16.0.0/12、および 192.168.0.0/16 の 3 つのルートを VPC のすべてのルートテーブルに自動的に追加します。これらのルートのネクストホップは VPC 接続です。これらのルートは、VPC からの IPv4 トラフィックをトランジットルーターに転送します。

• トランジットルーターで ルート学習を有効にした後、各 VPC の ルート伝播を有効にするか、各 VPC ルートテーブルにピア VPC へのルートを手動で追加することができます。

次の図は、トランジットルーターでルート学習が有効になっており、VPC ルートテーブルにルートが手動で追加されている例を示しています。このルートでは、宛先 CIDR ブロックはピア VPC の CIDR ブロックであり、ネクストホップはトランジットルーターです。

VPN Gateway へのルート

VPN Gateway を使用して暗号化トンネルを確立し、オンプレミスデータセンターと VPC の間に安全で信頼性の高いネットワーク接続を作成できます。

VPN Gateway を使用するには、宛先 CIDR ブロックをご利用のオンプレミスデータセンターの CIDR ブロックに設定し、ネクストホップを VPN Gateway に設定したルートを VPC ルートテーブルに追加します。これにより、VPC は IPsec 接続を介してオンプレミスデータセンターにアクセスできます。

ECS インスタンスまたは ENI へのルート

VPC 内の 2 つの vSwitch 間のトラフィックを検査、分析、保護するために、ルートテーブルを調整することで、ファイアウォールや Web Application Firewall (WAF) などのサードパーティのセキュリティデバイスをトラフィックパスに挿入できます。

そのためには、2 つの vSwitch のそれぞれを個別のカスタムルートテーブルに関連付け、対応する CIDR ブロックのシステムルートのネクストホップを、ファイアウォールの ECS インスタンスまたはそのネットワークインターフェース (ENI) に変更します。

ルーターインターフェイスへのルート

Express Connect の VBR-to-VPC 接続機能を使用して、オンプレミスデータセンターをクラウドネットワークに接続できます。

この機能を使用する場合、宛先 CIDR ブロックをオンプレミスデータセンターの CIDR ブロックに設定し、ネクストホップタイプを [ルーターインターフェイス (VBR へ)] に設定したルートを VPC に設定する必要があります。これにより、VPC は仮想ボーダールーター (VBR) を介してオンプレミスデータセンターにアクセスできます。このネクストホップタイプは、ヘルスチェックを必要とする 等コストマルチパス (ECMP) と A-S モードをサポートしています。

次の図は、アクティブ / スタンバイ構成を示しています。

Express Connect Router へのルート

Express Connect Router (ECR) を使用して、オンプレミスデータセンターをクラウドネットワークに接続できます。

• デフォルトでは、VPC は ECR からの動的ルートを受け入れます。これらのルートの宛先 CIDR ブロックはオンプレミスデータセンターの CIDR ブロックであり、ネクストホップは ECR です。これらのルートにより、VPC とオンプレミスデータセンター間の通信が可能になります。

• VPC ルートテーブルで動的ルート広告が無効になっている場合は、宛先 CIDR ブロックをオンプレミスデータセンターの CIDR ブロックに設定し、ネクストホップを Express Connect Router に設定したルートをテーブルに手動で追加する必要があります。これにより、VPC とオンプレミスデータセンター間の通信が可能になります。

Gateway Load Balancer エンドポイントへのルート

Gateway Load Balancer エンドポイントは、これらのリージョンでのみサポートされています。特定のユースケースについては、「gateway route table の使用 - GWLB 高可用性アーキテクチャ」をご参照ください。

クォータ

注意事項

課金

VPC ルートテーブル機能は無料でご利用いただけます。