割り当てと上限

このドキュメントでは、Cloud Router に適用される割り当てとシステムの上限を示します。割り当ては、使用できるカウント可能な共有リソースの量を指定します。割り当ては、Cloud Router などの Google Cloud サービスによって定義されます。システムの上限は、変更できない固定値です。

Google Cloud は、割り当てを使用して公平性を確保し、リソースの使用量と可用性の急増を抑えます。割り当ては、Google Cloud プロジェクトで使用できる Google Cloud リソースの量を制限します。割り当ては、ハードウェア、ソフトウェア、ネットワークコンポーネントなど、さまざまなリソースタイプに適用されます。たとえば、割り当てによって、サービスへの API 呼び出しの数、プロジェクトで同時に使用されるロードバランサの数、作成可能なプロジェクトの数を制限できます。割り当てを適用することで、サービスの過負荷を防ぎ、Google Cloud ユーザーのコミュニティを保護します。割り当ては、自組織で使用している Google Cloud リソースの管理にも役立ちます。

Cloud Quotas システムは次のことを行います。

Google Cloud のプロダクトとサービスの消費量をモニタリングする
これらのリソースの消費量を制限する
割り当て値の変更をリクエストする手段を提供する

ほとんどの場合、割り当ての許容量を超えるリソースを消費しようとすると、システムによってリソースへのアクセスがブロックされ、実行しようとしているタスクは失敗します。

割り当ては通常、Google Cloud プロジェクトレベルで適用されます。あるプロジェクトでリソースを使用しても、別のプロジェクトで使用可能な割り当てに影響することはありません。Google Cloud プロジェクト内では、すべてのアプリケーションと IP アドレスで割り当てが共有されます。

Cloud Router リソースにはシステムの上限もあります。システムの上限は変更できません。

割り当て

割り当てを変更するには、追加の割り当てをリクエストするをご覧ください。

次の表は、プロジェクト単位の重要な割り当てをまとめたものです。他の割り当てについては、Google Cloud コンソールの [割り当てとシステム制限] ページをご覧ください。

項目	割り当て	注
プロジェクトあたりの Cloud Router の数	割り当て	割り当てにかかわらず、各ネットワークではリージョンあたりの Could Router の数が 5 つに制限されています。上限をご覧ください。
リージョン、VPC ネットワークごとの、独自リージョンの Cloud Router 動的ルート接頭辞特定リージョン内のすべての Cloud Router によって同じリージョン内のサブネットに適用される、学習したルートの一意の宛先接頭辞の最大数。これは、リージョンの from-own-region 割り当てと呼ばれます。	割り当て	IPv4 と IPv6 の両方の接頭辞がこの割り当てにカウントされます。カスタム学習ルートや BGP で受信したルートなど、学習したすべてのルートがこの割り当てにカウントされます。ルートは一意の宛先ごとにグループ化されます。宛先が同じでネクストホップが異なるルートは、ただ 1 つの宛先としてカウントされます。また、宛先とネクストホップの両方が同じであるルートも、ただ 1 つの宛先としてカウントされます。グローバル動的ルーティングモードのネットワークでは、一意の動的ルート接頭辞のいずれかの割り当てに到達し、他の割り当てには到達しないことがあります。いずれかの割り当てが超過すると、ルートが破棄されたときに断続的に接続の問題が発生する可能性があります。詳細については、学習したルートの例をご覧ください。現在の使用量を把握するために使用できる指標など、これらの割り当ての詳細については、BGP ルートとルート選択のトラブルシューティングをご覧ください。
グローバル動的ルーティングモードの VPC ネットワークにのみ適用されます。リージョン、VPC ネットワークごと、他のリージョンの一意の Cloud Router 動的ルート接頭辞異なるリージョン内の Cloud Router によって特定のリージョンのサブネットに適用できる、学習したルートの保証された一意の宛先の最大数。これは、リージョンの from-other-regions 割り当てと呼ばれます。	割り当て	IPv4 と IPv6 の両方の接頭辞がこの割り当てにカウントされます。カスタム学習ルートや BGP で受信したルートなど、学習したすべてのルートがこの割り当てにカウントされます。ルートは一意の宛先ごとにグループ化されます。宛先が同じでネクストホップが異なるルートは、ただ 1 つの宛先としてカウントされます。また、宛先とネクストホップの両方が同じであるルートも、ただ 1 つの宛先としてカウントされます。グローバル動的ルーティングモードのネットワークでは、一意の動的ルート接頭辞のいずれかの割り当てに到達し、他の割り当てには到達しないことがあります。いずれかの割り当てに到達すると、ルートが破棄されたときに断続的に接続の問題が発生する可能性があります。詳細については、学習したルートの例をご覧ください。現在の使用量を把握するために使用できる指標など、これらの割り当ての詳細については、BGP ルートとルート選択のトラブルシューティングをご覧ください。

項目

割り当て

注

プロジェクトあたりの Cloud Router の数

割り当て

割り当てにかかわらず、各ネットワークではリージョンあたりの Could Router の数が 5 つに制限されています。上限をご覧ください。

リージョン、VPC ネットワークごとの、独自リージョンの Cloud Router 動的ルート接頭辞

特定リージョン内のすべての Cloud Router によって同じリージョン内のサブネットに適用される、学習したルートの一意の宛先接頭辞の最大数。これは、リージョンの from-own-region 割り当てと呼ばれます。

割り当て

IPv4 と IPv6 の両方の接頭辞がこの割り当てにカウントされます。

カスタム学習ルートや BGP で受信したルートなど、学習したすべてのルートがこの割り当てにカウントされます。

ルートは一意の宛先ごとにグループ化されます。宛先が同じでネクストホップが異なるルートは、ただ 1 つの宛先としてカウントされます。また、宛先とネクストホップの両方が同じであるルートも、ただ 1 つの宛先としてカウントされます。

グローバル動的ルーティングモードのネットワークでは、一意の動的ルート接頭辞のいずれかの割り当てに到達し、他の割り当てには到達しないことがあります。いずれかの割り当てが超過すると、ルートが破棄されたときに断続的に接続の問題が発生する可能性があります。詳細については、学習したルートの例をご覧ください。

現在の使用量を把握するために使用できる指標など、これらの割り当ての詳細については、BGP ルートとルート選択のトラブルシューティングをご覧ください。

グローバル動的ルーティングモードの VPC ネットワークにのみ適用されます。

リージョン、VPC ネットワークごと、他のリージョンの一意の Cloud Router 動的ルート接頭辞

異なるリージョン内の Cloud Router によって特定のリージョンのサブネットに適用できる、学習したルートの保証された一意の宛先の最大数。これは、リージョンの from-other-regions 割り当てと呼ばれます。

割り当て

IPv4 と IPv6 の両方の接頭辞がこの割り当てにカウントされます。

カスタム学習ルートや BGP で受信したルートなど、学習したすべてのルートがこの割り当てにカウントされます。

グローバル動的ルーティングモードのネットワークでは、一意の動的ルート接頭辞のいずれかの割り当てに到達し、他の割り当てには到達しないことがあります。いずれかの割り当てに到達すると、ルートが破棄されたときに断続的に接続の問題が発生する可能性があります。詳細については、学習したルートの例をご覧ください。

上限

Virtual Private Cloud（VPC）ネットワークには次の Cloud Router の上限が適用されます。特に明記されていない限り、これらの上限を引き上げることはできません。

項目	上限	注
VPC ネットワークとリージョンの各組み合わせにおける Cloud Router の最大数	5	プロジェクトの割り当てが十分な場合には、VPC ネットワークおよびリージョンで最大 5 つの Cloud Router を作成できます。
特定の VPC ネットワークとリージョンの各 Cloud Router における BGP ピアの最大数	128	BGP ピアは次のいずれかです。動的ルーティングを使用する Cloud VPN トンネル次のいずれかの VLAN アタッチメント。 Dedicated Interconnect Partner Interconnect Cross-Cloud Interconnect Network Connectivity Center 内のルーターアプライアンス
Cloud Router が単一の BGP ピアから受け入れるプレフィックスの最大数	5,000	BGP ピアが 5,000 を超えるプレフィックスをアドバタイズすると、Cloud Router は BGP セッションをリセットします。
単一の BGP ピアまたは方向に適用されたすべての BGP ルートポリシーの最大項目数	1,000	この上限はリソース間で分割されず、合計されます。1 つの一致またはアクションの式のサイズ、1 つの語句内のアクション数、1 つのポリシー内の語句数、ポリシーの数に制限はありません。
特定の Cloud Router での、BGP セッションあたりのサブネットルートアドバタイズの最大数	制限なし	Cloud Router では、アドバタイズできるサブネットルートの数に上限はありません。サブネットルートの数は、VPC ネットワークの割り当てと上限で制御されるサブネット数に基づいて決まります。
特定の Cloud Router での、BGP セッションあたりのカスタムアドバタイズルートの最大数	200	Cloud Router のすべての BGP セッションでカスタムアドバタイズルートが同一である場合、この上限は、Cloud Router の一意の IPv4 および IPv6 のカスタムアドバタイズルートの総数を表します。その場合、各セッションは同一のカスタムアドバタイズルートのセットを受け取ります。
特定の Cloud Router に対して、UTF-8 としてエンコードされたときに BGP ルートポリシーで使用されるすべての一致とアクションの式リテラルの最大サイズの合計	250 KiB の上限	特定の Cloud Router に対して、この上限はリソース間で分割されず、合計されます。1 つの一致またはアクションの式のサイズ、1 つの語句内のアクション数、1 つの BGP ルートポリシー内の語句数、BGP ルートポリシーの数に制限はありません。
1 つの Cloud Router での `list-bgp-routes` 呼び出しの 1 分あたりの最大クエリ数	1500	この割り当ては `compute.googleapis.com/list_requests_per_region` から取得されます。詳細については、レートに基づく割り当てをご覧ください。
Cloud Router あたりの BGP ルートポリシーの最大数	500
特定の BGP セッションでのカスタム学習ルートの最大数	10	この機能の詳細については、カスタム学習ルートをご覧ください。
VPC ネットワーク内の特定のリージョンに対する、カスタム学習ルートとして構成できる一意の IP 接頭辞の最大数。この上限により、複数のピアで同じ範囲を使用できます。	10	この機能の詳細については、カスタム学習ルートをご覧ください。

学習したルートの例

次の例では、from-own-region の割り当てまたは from-other-regions の割り当てを超えた場合に発生する可能性があるルートドロップ動作を示します。

Cloud Router が us-east1 リージョンにあり、同じ VPC ネットワークの us-west1 リージョンにも Cloud Router がある場合に、グローバル動的ルーティングが有効になっているとします。各リージョンの Cloud Router は、それぞれ 250 個の一意の宛先を学習します。この図は説明を目的としたもので、各リージョンの Cloud Router はそれぞれ同じ宛先を学習しません。

各リージョンの Cloud Router は 250 個の一意の宛先のうち 250 個を学習するため、各リージョンのルートをどの Cloud Router が学習しても、各リージョンの from-own-region の割り当てに達します。各 Cloud Router は他のリージョンから 250 個の一意の宛先をインポートするため、両方のリージョンの from-other-regions の割り当てにも到達します。サンプルの VPC ネットワークでリージョン動的ルーティングを使用した場合、リージョン動的ルーティングモードは、ルートのネクストホップに一致するリージョン内にのみ動的ルートを作成するように VPC ネットワークに対して指示するため、各リージョンの from-other-regions の割り当ては適用されません。

リージョンの from-own-region の割り当てを超えた場合

us-west1 の Cloud Router に接続されているオンプレミスルーターが 251 番目の宛先をアドバタイズするとします。us-west1 リージョンの Cloud Router は、決定論的なルート順序に従って、251 個の一意の宛先から 250 個を選択します。これらのルーターは、250 個の一意の宛先を VPC ネットワークに送信し、us-west1 リージョンに 250 個の動的ルートを作成します。

VPC ネットワークはグローバル動的ルーティングモードを使用するため、他のリージョンの一意の宛先の from-other-regions の割り当てに従って、他のすべてのリージョンに 250 以下の動的ルートも作成します。次のセクションでは、他のリージョンで行われる処理について詳しく説明します。

リージョンの from-other-regions の割り当てを超えた場合

us-west1 リージョンの Cloud Router が 251 個の一意の宛先を学習すると、us-east1 リージョンのリソースに対して、us-west1 を起点とする 251 個の一意の宛先のうち 250 個の宛先へのルートが利用可能になります。これは us-east1 リージョンの from-other-regions の割り当てで許容できる一意の宛先が 250 個に制限されるためです。

同じ VPC ネットワーク内の 3 番目のリージョン us-central1 に Cloud Router を作成するとします。また、新しい Cloud Router が BGP ピアから 10 個の一意の宛先を学習するものとします。us-central1 リージョンの from-own-region の割り当ては超過していませんが、他の 2 つのリージョンから合計 500 個の一意の宛先（us-east1 では 250、us-west1 では 250）が提供されているため、us-central1 リージョンの from-other-regions の割り当てを超えています。

リージョンごとに、次の表に示すように、他のリージョンからのルートは、各リージョンで一意の宛先が 250 個を超えないよう、決定論的なルート順序で選択されます。

リージョンリージョン固有の一意の宛先
（リージョンの from-own-region の割り当ての使用）他のリージョンからの一意の宛先
（リージョンの from-other-regions の割り当ての使用）

リージョン	リージョン固有の一意の宛先（リージョンの from-own-region の割り当ての使用）	他のリージョンからの一意の宛先（リージョンの from-other-regions の割り当ての使用）
us-west1	251 個を受信。251 個のうち 250 個が選択され、251 個のうちの 1 個が決定論的なルート順序によって破棄されます。`us-west1` にネクストホップを持つ 250 個の動的ルートが `us-west1` に作成されます。選択された 250 個の接頭辞は、他のリージョンと共有されます。	260 個を受信（`us-east1` から 250 個、`us-central1` から 10 個）。260 個のうち 250 個が選択され、260 個のうち 10 個が決定論的なルート順序で破棄されます。 `us-west1` の外部にネクストホップを持つ 250 個の動的ルートは、`us-west1` に作成されます。
us-east1	250 個を受信。250 個すべてが決定論的なルート順序によって選択されます。`us-east1` にネクストホップを持つ 250 個の動的ルートが `us-east1` に作成されます。選択された 250 個の接頭辞は、すべて他のリージョンと共有されます。	260 個を受信（`us-west1` から 250 個、`us-central1` から 10 個）。260 個のうち 250 個が選択され、260 個のうち 10 個が決定論的なルート順序で破棄されます。 `us-east1` の外部にネクストホップを持つ 250 個の動的ルートは、`us-east1` に作成されます。
us-central1	10 個を受信。10 個すべてが決定論的なルート順序によって選択されます。`us-central1` にネクストホップを持つ 10 個の動的ルートが `us-central1` に作成されます。選択された 10 個の接頭辞は、すべて他のリージョンと共有されます。	500 個を受信（`us-west1` から 250 個、`us-east1` から 250 個）。500 個のうち 250 個が選択され、500 個のうち 250 個が決定論的なルート順序で破棄されます。 `us-central1` の外部にネクストホップを持つ 250 個の動的ルートは、`us-central1` に作成されます。

us-west1

251 個を受信。251 個のうち 250 個が選択され、251 個のうちの 1 個が決定論的なルート順序によって破棄されます。us-west1 にネクストホップを持つ 250 個の動的ルートが us-west1 に作成されます。

選択された 250 個の接頭辞は、他のリージョンと共有されます。

260 個を受信（us-east1 から 250 個、us-central1 から 10 個）。260 個のうち 250 個が選択され、260 個のうち 10 個が決定論的なルート順序で破棄されます。

us-west1 の外部にネクストホップを持つ 250 個の動的ルートは、us-west1 に作成されます。

us-east1

250 個を受信。250 個すべてが決定論的なルート順序によって選択されます。us-east1 にネクストホップを持つ 250 個の動的ルートが us-east1 に作成されます。

選択された 250 個の接頭辞は、すべて他のリージョンと共有されます。

260 個を受信（us-west1 から 250 個、us-central1 から 10 個）。260 個のうち 250 個が選択され、260 個のうち 10 個が決定論的なルート順序で破棄されます。

us-east1 の外部にネクストホップを持つ 250 個の動的ルートは、us-east1 に作成されます。

us-central1

10 個を受信。10 個すべてが決定論的なルート順序によって選択されます。us-central1 にネクストホップを持つ 10 個の動的ルートが us-central1 に作成されます。

選択された 10 個の接頭辞は、すべて他のリージョンと共有されます。

500 個を受信（us-west1 から 250 個、us-east1 から 250 個）。500 個のうち 250 個が選択され、500 個のうち 250 個が決定論的なルート順序で破棄されます。

us-central1 の外部にネクストホップを持つ 250 個の動的ルートは、us-central1 に作成されます。

us-central1 リージョンの他リージョンからの割り当てを超えていますが、from-own-region の割り当てでは、ネクストホップが us-central1 リージョンに存在する宛先を受け入れることができます。

決定論的なルートドロップ動作

Cloud Router は、受信した各接頭辞のサブネットマスク長と辞書的特性に基づいて、決定論的なルートドロップ動作を実装します。各リージョン内では、次のプロセスが from-own-region の宛先リストと from-other-regions の一意の宛先リストに独立して適用されます。

リストは、サブネットマスクの長さが最短のものから最長のものの順に並べられ、次に辞書順に並べ替えられます。たとえば、10.0.0.0/8、10.2.1.0/24、10.99.1.0/24 はこの順序で並べられます。
リストにある最初の 250 件のエントリは保持されます。他はすべて破棄されます。

リージョンの from-other-regions の割り当てを超えた場合に示すように、決定論的ドロップ動作は、各リージョンの from-own-region の割り当てと各リージョンの from-other-regions の割り当てに対して独立して適用されます。

決定論的なルートドロップ動作の結果は、次のとおりです。

IPv4 と IPv6 の両方のプレフィックスを受信し、一意の宛先の割り当てを超えると、通常 Cloud Router は IPv6 プレフィックスを先に破棄します。これは、IPv6 の最も一般的な最小のサブネットマスク長（/48）が、IPv4 の最長のサブネットマスク長（/32）よりも長くなるためです。
各リージョンで学習したプレフィックスのセットが一定に保たれている場合は、VPC ネットワークの動的ルーティングモードに従って、すべてのリージョンで一貫したローカル動的ルートセットが Google Cloud によってプログラムされます。この一貫性は、Cloud Router によって破棄されるルートを含め、Cloud Router タスクを再起動しても保持されます。

ルートドロップの回避

ルートドロップの動作中は、ドロップされる接頭辞の接続が失われます。ルートドロップを回避するには、Cloud Monitoring または Cloud Logging を使用して、各リージョンの from-own-region のプレフィックスの使用状況と from-other-region のプレフィックスの使用状況をモニタリングし、一意の宛先をそれぞれの割り当てを超えてアドバタイズしないようにします。

一意の宛先の数を減らすため、ルートの要約を検討してください。たとえば、4 つのサブネット 10.10.10.0/24、10.10.10.1/24、10.10.10.2/24、10.10.10.3/24 がある場合、それらを 1 つの接頭辞 10.10.0.0/22 でまとめることができます。

要約できない場合は、Google Cloud のセールスチームに連絡して、別のオプションを確認してください。

割り当てを管理する

Cloud Router では、さまざまな理由から、使用できるリソースの割り当て量に上限が設けられています。たとえば、割り当て量の上限を設定して予期しない使用量の急増を防ぐことで、 Google Cloud ユーザーのコミュニティを保護しています。割り当て量は、無料枠で Google Cloud を試しているユーザーをトライアルに留めておくのにも役立ちます。

すべてのプロジェクトは同じ割り当て量で開始しますが、追加の割り当て量をリクエストすることで変更できます。割り当てによっては、プロダクトの使用状況に応じて自動的に増加される場合もあります。

権限

Identity and Access Management（IAM）のプリンシパルが割り当ての表示や、割り当ての増加のリクエストをするには、以下のいずれかのロールが必要です。

タスク	必要なロール
プロジェクトの割り当て量をチェックする	次のいずれかが必要です。プロジェクトオーナー（`roles/owner`）プロジェクト編集者（`roles/editor`）割り当て閲覧者（`roles/servicemanagement.quotaViewer`）
割り当て量の変更、割り当て量の追加のリクエストを行う	次のいずれかが必要です。プロジェクトオーナー（`roles/owner`）プロジェクト編集者（`roles/editor`）割り当て管理者（`roles/servicemanagement.quotaAdmin`） `serviceusage.quotas.update` 権限のあるカスタムロール

割り当て量を確認する

コンソール

Google Cloud コンソールで [割り当て] ページに移動します。
[割り当て] に移動
更新する割り当てを検索するには、[表をフィルタリング] を使用します。割り当ての名前がわからない場合は、このページにあるリンクを使用します。

gcloud

Google Cloud CLI で次のコマンドを実行して、割り当てを確認します。PROJECT_ID は、実際のプロジェクト ID に置き換えます。

    gcloud compute project-info describe --project PROJECT_ID

ある特定のリージョンで使用済みの割り当て量を確認するには、次のコマンドを実行します。

    gcloud compute regions describe example-region

割り当て量を超えたときのエラー

gcloud コマンドで割り当て量を超えた場合、gcloud は quota exceeded エラーメッセージを出力し、終了コード 1 を返します。

API リクエストで割り当て量を超えた場合、Google Cloud は HTTP ステータスコード 413 Request Entity Too Large を返します。

追加の割り当てをリクエスト

通常、割り当てを調整するには、Google Cloud コンソールを使用します。詳細については、割り当ての調整をリクエストするをご覧ください。

コンソール

Google Cloud コンソールで [割り当て] ページに移動します。
[割り当て] に移動
[割り当て] ページで、変更する割り当てを選択します。
ページの上部にある [割り当てを編集] をクリックします。
[名前] に氏名を入力します。
省略可: [電話番号] に有効な電話番号を入力します。
リクエストを送信します。割り当てのリクエストが処理されるまでに、24～48 時間かかります。

リソースの可用性

各割り当て量は、リソースが利用可能な場合に作成できる特定のリソースタイプの最大数を表します。割り当て量によってリソースの可用性が保証されるわけではありません。この点は注意が必要です。割り当て量が使用可能でも、新しいリソースを使用できなければ、そのリソースを作成することはできません。

たとえば、us-central1 リージョンで新しいリージョンの外部 IP アドレスを作成するための割り当て量が十分にあっても、そのリージョンに使用可能な外部 IP アドレスがない場合、外部 IP アドレスは作成できません。ゾーンリソースの可用性は、新しいリソースを作成できるかにも影響を及ぼす可能性があります。

リージョン全体でリソースを使用できない状況はまれです。ただし、ゾーン内のリソースが使い果たされることはあります。通常、そのリソースタイプのサービスレベル契約（SLA）に影響はありません。詳細については、リソースに関連する SLA をご覧ください。