VPC リソースの割り当て

割り当てと上限

以下のセクションでは、VPC ネットワークの割り当てと上限について説明します。割り当てを変更するには、GCP Console を使用して追加の割り当てをリクエストします。 具体的に注記がある場合を除き、一般的に上限を引き上げることはできません。

プロジェクト単位

次の表は、プロジェクトごとの、VPC リソースの重要なグローバル割り当てを示しています。他の割り当てについては [割り当て] ページをご覧ください。

項目 割り当て 注
ネットワーク 割り当て default ネットワーク（削除可能）が含まれます。
サブネット 割り当て プロジェクト内のすべてのネットワークのすべてのサブネットに適用されます。
割り当て済みの IP アドレス範囲 割り当て この割り当ては、プライベート サービス アクセス用に割り当て可能な、連続する内部 IP アドレス範囲の数を表します。この割り当ては、VPC ネットワークやリージョンではなく、プロジェクトに適用されます。
システム生成ルートと
カスタム静的ルート		 割り当て この割り当てには、Cloud Router が学習するカスタム動的ルートは含まれません。
Cloud Router 割り当て この割り当ては、任意のネットワークとリージョンで、プロジェクト内に作成できる Cloud Router の数を表します。また、各ネットワークには、リージョン内の Cloud Router 数にも上限があります。詳しくは、Cloud Router の割り当てと上限をご覧ください。
ファイアウォール ルール 割り当て この割り当ては、プロジェクト内のすべての VPC ネットワークに対して作成できるファイアウォール ルールの数を表します。
転送ルール 割り当て この割り当てには、内部と外部両方の転送ルール数が含まれています。内部転送ルール数には、異なる上限が適用されます。詳しくは、ネットワークあたりの内部ロードバランサに使用される転送ルール数と VPC ネットワーク ピアリングに関する上限をご覧ください。

共有 VPC プロジェクトの上限

共有 VPC に参加するプロジェクトには、次の上限が適用されます。

項目 上限 注
ホスト プロジェクトに接続可能なサービス プロジェクトの数 最大 100 この上限は状況によって異なり、100 より小さい場合もあります。ご不明な点がある場合や、この上限を引き上げる必要がある場合は、GCP セールスチームにお問い合わせください。
単一の組織における共有 VPC ホスト プロジェクトの数 100 この上限を引き上げる必要がある場合は、GCP セールスチームにお問い合わせください。
サービス プロジェクトが接続可能なホスト プロジェクトの数 1 この上限を引き上げることはできません。

ネットワーク単位

VPC ネットワークには次の上限が適用されます。これらの上限は、特に明記されていない限り、GCP セールスチームに連絡すれば引き上げることができます。

項目 上限 注
ネットワークあたりの VM インスタンス 15,000 VPC ネットワーク ピアリングを使用してネットワークを他のネットワークに接続すると、そのネットワークごとに作成できるインスタンス数の実質的な上限が低下することがあります。次のセクションの VPC ネットワーク ピアリングの上限をご覧ください。
サブネットあたりの VM インスタンス 特に制限はありません。
エイリアス IP 範囲の割り当て 15,000 エイリアス IP は、VM のネットワーク インターフェースに割り当てられた単一の IP アドレス（/32）または CIDR ブロック（/24 または /16）のどちらかです。エイリアス IP アドレスはサブネットのプライマリまたはセカンダリ IP 範囲のどちらかから取得されます。
この上限において、GCP はエイリアス範囲のサイズ（ネットマスク）を考慮しません。ネットワーク内のすべての VM に割り当てられるエイリアス IP（範囲）の数のみがカウントされます。

この割り当てに加えて、ネットワーク インターフェースごとのエイリアス IP 範囲の数には VM ごとに上限があります。
サブネットあたりのプライマリ IP 範囲 1 各サブネットにはプライマリ IP 範囲（CIDR ブロック）が 1 つ必要です。この範囲は、VM のプライマリ内部 IP アドレス、VM のエイリアス IP アドレス、内部ロードバランサの IP アドレスに使用されます。この上限を引き上げることはできません。
サブネットあたりのセカンダリ IP 範囲 30 必要に応じて、サブネットごとに最大 30 個のセカンダリ CIDR ブロックを定義できます。このセカンダリ IP 範囲は、エイリアス IP アドレスにのみ使用できます。この上限を引き上げることはできません。
サブネット IP 範囲の数（プライマリとセカンダリ） 300 1 つの VPC ネットワークで割り当てられるプライマリおよびセカンダリのサブネット IP 範囲の合計数です。
ファイアウォール ルールあたりの最大ソースタグ数 30 この上限は、上りのファイアウォール ルール作成時にソースタグとして指定できるネットワーク タグの最大数です。この上限を引き上げることはできません。
ファイアウォール ルールあたりの最大ターゲットタグ数 70 この上限は、下りまたは上りのファイアウォール ルール作成時にターゲットタグとして指定できるネットワーク タグの最大数です。この上限を引き上げることはできません。
ファイアウォール ルールあたりの最大ソースサービス アカウント数 10 この上限は、上りのファイアウォール ルール作成時に指定できるソースサービス アカウントの最大数です。この上限を引き上げることはできません。
ファイアウォール ルールあたりの最大ターゲット サービス アカウント数 10 この上限は、下りまたは上りのファイアウォール ルール作成時に指定できるターゲット サービス アカウントの最大数です。この上限を引き上げることはできません。
ネットワークあたりの転送ルールの最大数:
- 内部 TCP / UDP 負荷分散
- 内部 HTTP(S) 負荷分散 		75 この上限は、1 つのネットワーク内の内部転送ルールの最大数を表します。ネットワークを VPC ネットワーク ピアリングを使用する他のネットワークに接続している場合は、重要となる詳細情報について、VPC ネットワーク ピアリングの上限をご覧ください。
Cloud Router に関する上限 ルーターの合計数、BGP ピア、カスタムルート アドバタイズ、学習したルートについては、Cloud Router の割り当てと上限をご覧ください。

VPC ネットワーク ピアリングに関する上限

VPC ネットワーク ピアリングを使用して接続している VPC ネットワークには、次の上限が適用されます。それぞれの上限は、互いに直接ピアリングしている VPC ネットワークの集合である、ピアリング グループに適用されます。特定の VPC ネットワークの観点から見た場合、その VPC ネットワークとそのすべてのピア ネットワークは 1 つのピアリング グループに属します。ピアリング グループにはピア ネットワークのピアは含まれません。

これらの上限は引き上げることができる場合もあります。上限を引き上げる必要がある場合は、GCP セールスチームにお問い合わせください。

項目 上限 注
1 つの VPC ネットワークのピアリング接続数 25 この上限は、ピアリング グループ内の最大ネットワーク数を表します。自ネットワークは含まれません。
ピアリング グループ内の静的ルート数 300 この上限は、ネットワーク管理者がピアリング グループのすべてのネットワークに作成できる静的ルートの総数を表します。ピアリング グループがこの上限を超えてしまう場合、GCP ではネットワークのピアリング接続を作成できません。
ピアリング グループ内の動的ルート数 300

この上限は、Cloud Router でピアリング グループのすべてのネットワークに適用できる動的ルートの総数を表します。動的ルート数がこの上限を超える場合、GCP では特定のネットワークの動的ルートをインポートする方法が以下のように調整されます。

  • GCP では、ピアリング ネットワークからインポートされた動的ルートがドロップされます。内部アルゴリズムを使用して動的ルートをドロップするため、最近追加されたルートだけでなく、古いルートもドロップされる可能性があります。インポートされたどの動的ルートがドロップされるかを予測することはできません。そこで、ピアリング グループ内の動的ルートの数を減らすことをおすすめします。
  • Cloud Router の制限の適用により、ローカル ネットワークの Cloud Router によって学習された動的ルートが GCP にドロップされることはありません。
  • ピアリング接続するとこの上限を超えてしまう場合でも、GCP でピアリング接続を作成できます。警告は表示されません。
ピアリング グループ内の VM インスタンス総数 15,500 この上限は、ピアリング グループに直接接続されたネットワークに存在できるインスタンスの総数を表します。

後述の VPC ネットワーク ピアリングと最大 VM 数のセクションに、この上限の具体例を示します。
サブネット IP 範囲の数（プライマリとセカンダリ） 400 ピアリング グループ内のすべてのネットワークで割り当てられるプライマリおよびセカンダリのサブネット IP 範囲の合計数です。
特定のネットワーク内で使用される転送ルールの最大数:
- 内部 TCP / UDP 負荷分散
- 内部 HTTP(S) 負荷分散 		75 GCP では、以下のすべての条件を満たす限り、特定の VPC ネットワークで新しい内部転送ルールを作成できます。
  • 特定ネットワークのプロジェクト内に存在する転送ルールの総数（内部転送ルール数だけではない）が、プロジェクトあたりの転送ルールの割り当て未満であること。
  • 特定ネットワークの内部転送ルール数が、特定ネットワーク内の内部ロードバランサに使用される転送ルールの最大数未満であること。
  • ピアリング グループ内の内部転送ルール数が、ピアリング グループ内の内部ロードバランサに使用される実質的な転送ルール数未満であること。これは、VPC ネットワーク ピアリングと内部転送ルール数の説明に従って計算されます。
ピアリング グループ内で使用される転送ルール数:
- 内部 TCP / UDP 負荷分散
- 内部 HTTP(S) 負荷分散 		175

VPC ネットワーク ピアリングと最大 VM 数

ピアリング グループ内のネットワーク間で許可されている VM インスタンス数は、最大 15,500 個です。具体例として、ネットワーク network-b がネットワーク network-a と network-c の 2 つとピアリングされている場合を考えます。

  • network-b に 5,000 個の VM がある場合、network-a と network-c の両方を合わせた VM の総数は 10,500 以下である必要があります。
  • network-b に 500 個の VM がある場合、network-a と network-c の両方を合わせた VM の総数は 15,000 以下である必要があります。

VPC ネットワーク ピアリングと内部転送ルール数

特定の VPC ネットワークの観点から見た場合、GCP は次の方法を使用して、ピアリング グループ内の内部ロードバランサに使用される実質的な転送ルール数を計算しています。

  • ステップ 1. 特定のネットワークについて、次の 2 つの上限のうち値が大きい方を見つけます。

    • 特定のネットワーク内の内部ロードバランサに使用される転送ルールの最大数
    • ピアリング グループ内の内部ロードバランサに使用される転送ルール数

  • ステップ 2. ピアリング グループ内の残りの各ネットワークについて、次の 2 つの上限のうち値が大きい方を見つけます。

    • ピア ネットワーク内の内部ロードバランサに使用される転送ルールの最大数
    • ピアリング グループ内の内部ロードバランサに使用される転送ルール数

  • ステップ 3. ステップ 2 で作成したリストから最小値を見つけます。

  • ステップ 4. ステップ 1 とステップ 3 の 2 つの数のうち値が大きい方を選びます。この数が、特定のネットワークの観点から見た場合にピアリング グループ内で作成可能な、内部ロードバランサに使用される実質的な転送ルール数となります。

たとえば、network-a、network-b、network-c、network-d の 4 つの VPC ネットワークを使用しているとします。

  • network-a は network-b とピアリングされており、network-b は network-a とピアリングされています。
  • network-a は network-c とピアリングされており、network-c は network-a とピアリングされています。
  • network-c は network-d とピアリングされており、network-d は network-c とピアリングされています。

また、各ネットワークには以下の上限があります。

ネットワーク 特定のネットワーク内の内部ロードバランサに使用される転送ルールの最大数 ピアリング グループ内の内部ロードバランサに使用される転送ルール数
network-a 160 150
network-b 75 80
network-c 75 75
network-d 75 95

各 VPC ネットワークの観点から見た場合、GCP は次の方法を使用してピアリング グループ内の内部ロードバランサに使用される実質的な転送ルール数を計算しています。

  • network-a の観点から見た場合、ピアリング グループには network-a、network-b、network-c が含まれています。ピアリング グループ内の内部ロードバランサに使用される実質的な転送ルール数は、次のように計算されます。

    1. network-a では max(160,150) = 160 になります。
    2. 残りのピア ネットワークでは次のようになります。
      • network-b: max(75,80) = 80
      • network-c: max(75,75) = 75
    3. min(80,75) = 75
    4. max(160,75) = 160
      • 内部ロードバランサに使用される実質的な転送ルール数は、network-a の観点から見ると、ピアリング グループあたり 160 になります。

  • network-b の観点から見た場合、ピアリング グループには network-b、network-a が含まれています。ピアリング グループ内の内部ロードバランサに使用される実質的な転送ルール数は、次のように計算されます。

    1. network-b では max(75,80) = 80 になります。
    2. 残りのピア ネットワークでは次のようになります。
      • network-a: max(160,150) = 160
    3. min(160) = 160
    4. max(80,160) = 160
      • 内部ロードバランサに使用される実質的な転送ルール数は、network-b の観点から見ると、ピアリング グループあたり 160 になります。

  • network-c の観点から見た場合、ピアリング グループには network-c、network-a、network-d が含まれています。ピアリング グループ内の内部ロードバランサに使用される実質的な転送ルール数は、次のように計算されます。

    1. network-c では max(75,75) = 75 になります。
    2. 残りのピア ネットワークでは次のようになります。
      • network-a: max(160,150) = 160
      • network-d: max(75,95) = 95
    3. min(160,95) = 95
    4. max(75,95) = 95
      • 内部ロードバランサに使用される実質的な転送ルール数は、network-c の観点から見ると、ピアリング グループあたり 95 になります。

  • network-d の観点から見た場合、ピアリング グループには network-d、network-c が含まれています。ピアリング グループ内の内部ロードバランサに使用される実質的な転送ルール数は、次のように計算されます。

    1. network-d では max(75,95) = 95 になります。
    2. 残りのピア ネットワークでは次のようになります。
      • network-c: max(75,75) = 75
    3. min(75) = 75
    4. max(95,75) = 95
      • 内部ロードバランサに使用される実質的な転送ルール数は、network-d の観点から見ると、ピアリング グループあたり 95 になります。

インスタンス単位

VM インスタンスには次の上限が適用されます。特に明記のない限り、これらの上限を引き上げることはできません。VM に関する割り当てについては、Compute Engine の割り当てをご覧ください。

項目 上限 注
Maximum Transmission Unit（MTU） 1,460 バイト これよりも大きい MTU サイズを使用するインスタンスは、パケットがドロップされる可能性があります。この MTU 値を引き上げることはできません。
ネットワーク インターフェースの最大数 8 ネットワーク インターフェースは、インスタンスの作成時に定義されます。後からインスタンスを編集して変更することはできません。
ネットワーク インターフェースごとのエイリアス IP 範囲の最大数 10 ネットワーク インターフェースに割り当てることのできるエイリアス IP 範囲が、VPC ネットワークに割り当てられたエイリアス IP 範囲の合計数の割り当てを超過しないようにする必要があります。

この上限を引き上げる必要がある場合は、GCP セールスチームにお問い合わせください。
VPC ネットワークあたりのネットワーク インターフェース 1 各ネットワーク インターフェースは、一意の VPC ネットワークに接続する必要があります。インスタンスは、特定の VPC ネットワーク内にネットワーク インターフェースを 1 つだけ持つことができます。
アイドル状態の TCP 接続の最大継続時間 10 分 VPC ネットワークは、アイドル状態の TCP 接続を 10 分後に自動的に切断します。この上限は変更できませんが、TCP キープアライブを使用すると、インスタンスへの接続がアイドル状態になることを防止できます。詳細については、Compute Engine のヒントとトラブルシューティングをご覧ください。
上り最大データ通信速度 マシンタイプに応じて異なります。 GCP では、VM インスタンスの受信トラフィック、つまり上りトラフィックは人為的に制限されません。VM は、リソースとネットワークの条件で許される限り多くのトラフィックを受信できます。キャパシティ プランニングのために、各 VM インスタンスは 10 Gbps 以下の外部インターネット トラフィックを処理できると仮定する必要があります。この値は概算であり、SLA の対象ではなく、変更される可能性があります。エイリアス IP アドレスや複数のネットワーク インターフェースを VM に追加しても、上り容量は増加しません。
下り最大データ通信速度 VM のマシンタイプに応じて異なります。
  • すべての共有コア マシンタイプでは 1 Gbps に制限されます。
  • 16 個以上の vCPU を持つ Skylake 以降の CPU プラットフォームを使用するマシンタイプでは、vCPU ごとに 2 Gbps、VM ごとに最大 32 Gbps。この下り速度は ultramem マシンタイプにも適用されます。
  • 8 個以上の vCPU を持つその他のマシンタイプでは、vCPU ごとに 2 Gbps、VM ごとに最大 16 Gbps です。
 下りトラフィックは VM のすべてのネットワーク インターフェース間で共有する送信帯域幅の合計です。これには、VM に接続された永続ディスクへのデータ転送も含まれます。

実際の下り速度はその他の要因に左右されます。詳細については、こちらのページをご覧ください。

Overview

Virtual Private Cloud enforces quotas on resource usage for a variety of reasons. For example, quotas protect the community of Google Cloud Platform users by preventing unforeseen spikes in usage. Quotas also help users who are exploring GCP with the free tier to stay within their trial.

All projects start with the same quotas, which you can change by requesting additional quota. Some quotas may increase automatically, based on your use of a product.

Permissions

To view quotas or request quota increases, IAM members need one of the following roles.

Task Required Role
Check quotas for a project Project owner or editor or Quota Viewer
Modify quotas, request additional quota Project owner or editor, Quota Admin, or custom role with the serviceusage.quotas.update permission

Checking your quota

In the GCP Console, go to the Quotas page.

Using the gcloud command-line tool, run the following command to check your quotas. Replace [PROJECT_ID] with your own project ID.

    gcloud compute project-info describe --project [PROJECT_ID]

To check your used quota in a region, run:

    gcloud compute regions describe example-region

Errors when exceeding your quota

If you exceed a quota with a gcloud command, gcloud outputs a quota exceeded error message and returns with the exit code 1.

If you exceed a quota with an API request, Google Cloud returns the following HTTP status code: HTTP 413 Request Entity Too Large.

Requesting additional quota

Request additional quota from the Quotas page in the GCP Console. Quota requests take 24 to 48 hours to process.

  1. Go to the Quotas page.

    Go to the Quotas page

  2. In the Quotas page, select the quotas you want to change.
  3. Click the Edit Quotas button at the top of the page.
  4. Fill out your name, email, and phone number and click Next.
  5. Fill in your quota request and click Next.
  6. Submit your request.

Resource availability

Each quota represents a maximum number for a particular type of resource that you can create, provided that resource is available. It's important to note that quotas do not guarantee resource availability. Even if you have available quota, you won't be able to create a new resource if it is not available. For example, you might have sufficient quota to create new regional, external IP address in the us-central1 region, but that would not be possible if there were no available external IP addresses in that region. Zonal resource availability can also affect your ability to create a new resource.

Situations where resources are unavailable in an entire region are rare; however, resources within a zone can be depleted from time to time, typically without impact to the SLA for the type of resource. For more information, review the relevant Service Level Agreement (SLA) for the resource.