VPC リソースの割り当て

割り当てと上限

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

組織単位

以下の上限は、組織に適用されます。

項目 上限 注
組織単位の階層型ファイアウォール ポリシー数 10 この上限を引き上げる必要がある場合は、Google Cloud セールスチームにお問い合わせください。
階層型ファイアウォール ポリシーにおける階層型ファイアウォール ルール属性数 250 階層型ファイアウォール ポリシーにおけるすべてのルールのルール属性数。ルール数ではなく、ポリシーにおけるすべてのルールの総属性数のみで算出します。

ルール「属性」とは、IP 範囲、プロトコル、またはプロトコルとポートの範囲を指します。例:
  • 10.100.0.1/32 のソース IP 範囲と tcp:5000-6000 の宛先ポートを指定するルールでは、IP 範囲 1 つ、プロトコルとポートの範囲 1 つで、2 つの属性として数えられます。
  • 10.100.0.1/32 と 10.100.1.1/32 のソース範囲、tcp:80、tcp:443、udp:4000-5000、icmp の宛先プロトコルと宛先ポートを指定するルールでは、2 つの IP 範囲に対して 1 つずつ、4 つのプロトコルまたはプロトコルとポートの範囲に対して 1 つずつで、6 つの属性として数えられます。
ポリシーの属性数を確認するには、ポリシーの説明をご覧ください。この上限を引き上げる必要がある場合は、Google Cloud セールスチームにお問い合わせください。

プロジェクト単位

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

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

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

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

項目 上限 注
ホスト プロジェクトに接続可能なサービス プロジェクトの数 1,000 この上限を引き上げる必要がある場合は、Google Cloud セールスチームにお問い合わせください。
単一の組織における共有 VPC ホスト プロジェクトの数 100 この上限を引き上げる必要がある場合は、Google Cloud セールスチームにお問い合わせください。
サービス プロジェクトが接続可能なホスト プロジェクトの数 1 この上限を引き上げることはできません。

ネットワーク単位

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

項目 上限 注
インスタンス
ネットワーク単位の VM インスタンスの最大数 15,000 VPC ネットワーク ピアリングを使用してネットワークを他のネットワークに接続すると、この上限が低下することがあります。詳しくは、VPC ネットワーク ピアリングに関する上限をご覧ください。
サブネット単位の VM インスタンスの最大数 特に制限はありません。
エイリアス IP 範囲の割り当ての最大数 15,000 エイリアス IP 範囲は、VM のネットワーク インターフェースに割り当てられた単一の IP アドレス（/32）または CIDR ブロック（/24 または /16）のどちらかです。エイリアス IP アドレスはサブネットのプライマリまたはセカンダリ IP 範囲のどちらかから取得されます。

この上限において、Google Cloud は範囲のネットマスクのサイズを考慮しません。ネットワーク内のすべての VM に割り当てられるエイリアス IP 範囲の数のみがカウントされます。

この割り当てに加えて、ネットワーク インターフェース単位のエイリアス IP 範囲の数には VM ごとに上限があります。
サブネット IP 範囲
サブネット単位のプライマリ IP 範囲 1 各サブネットにはプライマリ IP 範囲（CIDR ブロック）が 1 つ必要です。この範囲は、VM のプライマリ内部 IP アドレス、VM のエイリアス IP 範囲、内部ロードバランサの IP アドレスに使用されます。この上限を引き上げることはできません。
サブネット単位のセカンダリ IP 範囲の最大数 30 必要に応じて、サブネットごとに最大 30 個のセカンダリ CIDR ブロックを定義できます。このセカンダリ IP 範囲は、エイリアス IP 範囲にのみ使用できます。この上限を引き上げることはできません。
サブネット IP 範囲の最大数（プライマリとセカンダリ） 300 VPC ネットワーク内のすべてのサブネットに割り当てられたプライマリおよびセカンダリのサブネット IP 範囲の合計数です。
ファイアウォール ルール単位の最大ソースタグ数 30 この上限は、上り（内向き）トラフィックのファイアウォール ルール作成時にソースタグとして指定できるネットワーク タグの最大数です。この上限を引き上げることはできません。
ファイアウォール ルール単位の最大ターゲットタグ数 70 この上限は、下り（外向き）または上り（内向き）トラフィックのファイアウォール ルール作成時にターゲットタグとして指定できるネットワーク タグの最大数です。この上限を引き上げることはできません。
ファイアウォール ルール単位の最大ソースサービス アカウント数 10 この上限は、上り（内向き）トラフィックのファイアウォール ルール作成時に指定できるソースサービス アカウントの最大数です。この上限を引き上げることはできません。
ファイアウォール ルール単位の最大ターゲット サービス アカウント数 10 この上限は、下り（外向き）または上り（内向き）トラフィックのファイアウォール ルール作成時に指定できるターゲット サービス アカウントの最大数です。この上限を引き上げることはできません。
ファイアウォール ルール単位の最大ソース範囲数 256 この上限は、上り（内向き）のファイアウォール ルール作成時に指定できるソース IP 範囲の最大数です。この上限を引き上げることはできません。
ファイアウォール ルール単位の最大送信先範囲数 256 この上限は、下り（外向き）トラフィックのファイアウォール ルール作成時に指定できる送信先 IP 範囲の最大数です。この上限を引き上げることはできません。
内部負荷分散
転送ルールの最大数:
- 内部 TCP/UDP 負荷分散
- 内部 HTTP(S) 負荷分散 		75 これは、内部ロードバランサに使用される転送ルールの最大数を表します。

この上限は、内部負荷分散に使用される転送ルールの合計数に適用されます。各リージョンに個別には適用されません。

VPC ネットワーク ピアリングを使用してネットワークを他のネットワークに接続している場合は、重要となる詳細情報について、VPC ネットワーク ピアリングに関する上限をご覧ください。
プロトコル転送
内部プロトコル転送に使用される転送ルールの最大数 50 この上限は、内部プロトコル転送に使用される転送ルールの最大数を表します。

この上限は、内部プロトコル転送に使用される転送ルールの合計数に適用されます。各リージョンに個別には適用されません。

VPC ネットワーク ピアリングを使用してネットワークを他のネットワークに接続している場合は、重要となる詳細情報について、VPC ネットワーク ピアリングに関する上限をご覧ください。

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

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

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

項目 上限 注
ピアリング グループ
1 つの VCP ネットワークへの最大接続数 25 この上限は、VPC ネットワーク ピアリングを使用する特定の VPC ネットワークに接続できるネットワークの最大数を表します。
ピアリング グループ内の最大サブネット ルート数 特に制限なし 交換できるサブネット ルートの数は、下記のように、1 ピアリング グループあたりのサブネット IP 範囲の最大数（プライマリとセカンダリ）により制限されます。
ピアリング グループ内の最大静的ルート数 300 この上限は、カスタムルートのインポートとエクスポートをする際にピアリング グループ内のネットワーク間で交換できる静的ルートの最大数を表します。ピアリング グループがこの上限を超える場合、Google Cloud ではネットワークのピアリング接続を作成できません。
ピアリング グループ内の最大動的ルート数 300 この上限は、カスタムルートのインポートとエクスポートをする際に、Cloud Router でピアリング グループのすべてのネットワークに適用できる動的ルートの最大数を表します。動的ルート数がこの上限を超える場合、Google Cloud では特定のネットワークの動的ルートをインポートする方法が以下のように調整されます。
  • Google Cloud では、ピアリングされたネットワークからインポートした動的ルートがドロップされます。 内部アルゴリズムを使用して動的ルートをドロップするため、最近追加されたルートだけでなく、古いルートもドロップされる可能性があります。インポートした動的ルートのうち、どの動的ルートがドロップされるかを予測することはできません。そこで、ピアリング グループ内の動的ルートの数を減らすことをおすすめします。
  • Cloud Router の上限の適用により、ローカル ネットワークの Cloud Router が学習した動的ルートが Google Cloud にドロップされることはありません。
  • ピアリング接続すると、この上限を超える場合でも、Google Cloud でピアリング接続を作成できます。警告は表示されません。
インスタンス
VM インスタンスの最大数 1 ネットワークあたり 15,000
1 ピアリング グループあたり 15,500		 Google Cloud では、以下のすべての条件を満たす限り、特定の VPC ネットワークで新しいインスタンスを作成できます。
  • この上限で定義された 1 ネットワークあたりの最大数を超えていないこと。
  • この上限で定義された 1 ピアリング グループあたりの最大数を超えていないこと。
例については、VPC ネットワーク ピアリングと最大 VM 数をご覧ください。
サブネット IP 範囲
サブネット IP 範囲の最大数（プライマリとセカンダリ） 400 ピアリング グループ内のすべてのネットワークでサブネットに割り当てられる、プライマリおよびセカンダリのサブネット IP 範囲の最大数です。
内部負荷分散
転送ルールの最大数:
- 内部 TCP/UDP 負荷分散
- 内部 HTTP(S) 負荷分散 		1 ネットワークあたり 75
1 ピアグループあたり 175		 以下のすべての条件に該当する場合、内部負荷分散のための新しいリージョン内部転送ルールを作成できます。
  • 特定ネットワークのプロジェクト内に存在する転送ルールの総数（内部転送ルール数だけではない）が、プロジェクト単位の転送ルールの割り当て未満であること。
  • この上限で定義された 1 ネットワークあたりの最大数を超えていないこと。
  • 内部負荷分散で使用される内部転送ルール数が、ピアリング グループ内の実質的な転送ルール数未満であること。 実質的な転送ルール数は、VPC ネットワーク ピアリングと内部転送ルール数の説明に従って計算されます。
プロトコル転送
内部プロトコル転送に使用される転送ルールの最大数 1 ネットワークあたり 50
1 ピアリング グループあたり 100		 以下のすべての条件に該当する場合、プロトコル転送のための新しいリージョン内部転送ルールを作成できます。
  • 特定ネットワークのプロジェクト内に存在する転送ルールの総数（内部転送ルール数だけではない）が、プロジェクト単位の転送ルールの割り当て未満であること。
  • この上限で定義された 1 ネットワークあたりの最大数を超えていないこと。
  • ピアリング グループ内のプロトコル転送で使用される内部転送ルール数が、ピアリング グループ内の実質的な転送ルール数未満であること。これは、VPC ネットワーク ピアリングと内部転送ルール数の説明に従って計算されます。

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 ネットワークの観点から見た場合、Google Cloud は次の方法を使用して、ピアリング グループ内の内部ロードバランサに使用される実質的な転送ルール数を計算します。

  • ステップ 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 ネットワークの観点から見た場合、Google Cloud は次の方法を使用してピアリング グループ内の内部ロードバランサに使用される実質的な転送ルール数を計算します。

  • 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 の観点から見ると、1 ピアリング グループあたり 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 の観点から見ると、1 ピアリング グループあたり 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 の観点から見ると、1 ピアリング グループあたり 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 の観点から見ると、1 ピアリング グループあたり 95 になります。

インスタンス単位

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

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

Google Cloud は、エイリアス IP 範囲のネットマスクのサイズを考慮しません。たとえば個々の /24 範囲は単一のエイリアス IP 範囲であり、個々の /23 もまた、単一のエイリアス IP 範囲です。

この上限を引き上げる必要がある場合は、Google Cloud セールスチームにお問い合わせください。
1 VPC ネットワークあたりのネットワーク インターフェース 1 各ネットワーク インターフェースは、一意の VPC ネットワークに接続する必要があります。インスタンスは、特定の VPC ネットワーク内にネットワーク インターフェースを 1 つだけ持つことができます。
アイドル状態の TCP 接続の最大継続時間 10 分 VPC ネットワークは、アイドル状態の TCP 接続を 10 分後に自動的に切断します。この上限は変更できませんが、TCP キープアライブを使用すると、インスタンスへの接続がアイドル状態になることを防止できます。 詳細については、Compute Engine のヒントとトラブルシューティングをご覧ください。
内部 IP アドレスの送信先への下り（外向き）最大データ通信速度 VM のマシンタイプに応じて異なります。 詳細については、Compute Engine ドキュメントの内部 IP アドレスの送信先への下り（外向き）トラフィックとマシンタイプをご覧ください。
外部 IP アドレスの宛先への下り（外向き）最大データ通信速度 すべてのフロー: 約 7 Gbps（ギガビット/秒）持続、
単一フロー: 3 Gbps 持続 		詳細については、Compute Engine ドキュメントの外部 IP アドレスの送信先への下り（外向き）トラフィックをご覧ください。
内部 IP アドレスの送信先への上り（内向き）最大データ通信速度 人為的な制限なし 詳細については、Compute Engine ドキュメントの内部 IP アドレスの送信先への上り（内向き）トラフィックをご覧ください。
外部 IP アドレスの送信先への上り（内向き）最大データ通信速度 20 Gbps 以下
1 秒あたり 1,800,000 パケット以下		 詳細については、Compute Engine ドキュメントの外部 IP アドレスの送信先への上り（内向き）トラフィックをご覧ください。

接続ロギング上限

VM インスタンスごとにログに記録できる最大接続数は、そのインスタンスのマシンタイプによって異なります。接続ロギング上限は、5 秒間にログに記録できる最大接続数として表現されます。

インスタンスのマシンタイプ 5 秒間に記録できる最大接続数
f1-micro 100 接続
g1-small 250 接続
1～8 個の vCPU を備えたマシンタイプ 1 vCPU あたり 500 接続
8 個を超える vCPU を備えたマシンタイプ 4,000（500×8）接続

ハイブリッド接続

以下のリンクを使用して、Cloud VPN、Cloud Interconnect、Cloud Router の割り当てと上限を確認してください。

概要

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

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

権限

割り当て量の表示や、割り当て量の増加のリクエストを行うには、IAM メンバーは以下のいずれかの役割を持つ必要があります。

タスク 必要な役割
プロジェクトの割り当て量をチェックする プロジェクト オーナーまたは編集者、 または 割り当て閲覧者
割り当て量の変更、割り当て量の追加のリクエストを行う プロジェクト オーナーまたは編集者、 割り当て管理者、 または serviceusage.quotas.update 権限を持つカスタム役割

割り当て量を確認する

Cloud Console で、[割り当て] ページに移動します。

gcloud コマンドライン ツールで次のコマンドを実行して、割り当て量を確認します。[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 ステータス コード HTTP 413 Request Entity Too Large を返します。

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

Cloud Console の [割り当て] ページから、追加の割り当てをリクエストします。割り当てのリクエストが処理されるまで、24～48 時間かかります。

  1. [割り当て] ページに移動します。

    [割り当て] ページに移動

  2. [割り当て] ページで、変更する割り当てを選択します。
  3. ページ上部にある [割り当てを編集] ボタンをクリックします。
  4. 名前、メールアドレス、電話番号を入力して、[次へ] をクリックします。
  5. 割り当てリクエストを入力して、[次へ] をクリックします。
  6. リクエストを送信します。

リソースの可用性

各割り当て量は、リソースを使用できるという前提で、作成可能な特定のリソースタイプの最大数を表します。割り当て量によって、リソースの可用性が保証されるわけではない点に注意することが重要です。割り当て量が使用可能でも、新しいリソースを使用できなければ、そのリソースを作成することはできません。たとえば、us-central1 リージョンで新しいリージョンの外部 IP アドレスを作成するための割り当て量が十分にあっても、そのリージョンに使用可能な外部 IP アドレスがない場合、外部 IP アドレスの作成はできません。ゾーンリソースの可用性は、新しいリソースを作成できるかにも影響を及ぼす可能性があります。

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