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 Gateway またはルーターインターフェイスであり、CEN からの既存の動的ルートが同じ宛先 CIDR ブロックを持つ場合、動的ルートは取り消され、カスタムルートが有効になります。
  動的ルートの受信	既存のシステムルートの宛先 CIDR ブロックと同一にすることはできません。 動的ルートが既存のシステムルートよりも具体的な場合、動的ルートは有効になりません： 動的ルートソースが ECR の場合、ルートは VPC ルートテーブルに 候補 ステータスで表示され、転送には使用されません。 動的ルートソースが VPN Gateway、TR Enterprise Edition、または TR Basic Edition の場合、ルートは VPC ルートテーブルに伝播されません。	宛先 CIDR ブロックが既存のカスタムルートと同一である場合、動的ルートは有効になりません。 動的ルートソースが ECR の場合、ルートは VPC ルートテーブルに 候補 ステータスで表示され、転送には使用されません。 動的ルートソースが VPN Gateway、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 ブロックのトラフィックをリダイレクトできます。

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

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

サポートされている宛先 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 Gateway へのルートエントリ	VPC	いいえ	はい	はい
    VPC ピアリング接続へのルートエントリ	VPC	いいえ	いいえ	いいえ
    TR へのルートエントリ	VPC	いいえ	いいえ	いいえ
    VPN Gateway へのルートエントリ	VPC	いいえ	はい	はい
    ECS インスタンスへのルートエントリ	VPC	いいえ	はい	はい
    Elastic Network Interface へのルートエントリ	VPC	いいえ	はい	はい
    高可用性仮想 IP へのルートエントリ	VPC	いいえ	はい	はい
    ルーターインターフェイス (VBR への) へのルートエントリ	VPC	いいえ	いいえ	いいえ
    ルーターインターフェイス (VPC への) へのルートエントリ	VPC	いいえ	いいえ	いいえ
    ECR へのルートエントリ	VPC	いいえ	いいえ	いいえ
    Gateway Load Balancer エンドポイントへのルートエントリ	VPC	いいえ	はい	はい

  シナリオ例

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

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

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

ご利用の VPC が ECR と TR の両方に接続されている場合、ECR へのルートの公開と TR へのルートの公開は互いに影響しない独立した操作です。

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

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

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

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

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

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

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

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 インスタンスにセルフマネージドファイアウォールをデプロイし、gateway route table を使用して 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 を使用するには、VPC ルートテーブルに、宛先 CIDR ブロックをオンプレミスデータセンターの CIDR ブロックに設定し、ネクストホップを VPN Gateway に設定したルートを追加します。これにより、VPC は IPsec-VPN 接続を介してオンプレミスデータセンターにアクセスできます。

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

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

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

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

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

この機能を使用する場合、VPC のルートを設定する必要があります。宛先 CIDR ブロックをオンプレミスデータセンターの CIDR ブロックに設定し、ネクストホップタイプを ルーターインターフェイス (VBR へ) に設定します。これにより、VPC は Virtual Border Router (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 ルートテーブル機能は無料です。