VPC リソースの割り当て

割り当てと上限

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

プロジェクト単位

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

項目	割り当て	注
ネットワーク	割り当て	`default` ネットワーク（削除可能）が含まれます。
サブネット	割り当て	プロジェクト内のすべてのネットワークのすべてのサブネットに適用されます。
割り当て済みの IP アドレス範囲	割り当て	この割り当ては、プライベートサービスアクセス用に割り当て可能な、連続する内部 IP アドレス範囲の数を表します。この割り当ては、VPC ネットワークやリージョンではなく、プロジェクトに適用されます。
システム生成ルートとカスタム静的ルート	割り当て	この割り当てには、Cloud Router が学習するカスタム動的ルートは含まれません。
Cloud Router	割り当て	この割り当ては、任意のネットワークとリージョンで、プロジェクト内に作成できる Cloud Router の数を表します。また、各ネットワークには、リージョン内の Cloud Router 数にも上限があります。詳しくは、Cloud Router の割り当てと制限をご覧ください。
ファイアウォールルール	割り当て	この割り当ては、プロジェクト内のすべての VPC ネットワークに対して作成できるファイアウォールルールの数を表します。
転送ルール	割り当て	この割り当てには、内部と外部両方の転送ルール数が含まれています。内部転送ルール数には、異なる上限が適用されます。詳しくは、ネットワークあたりの内部 TCP / UDP 負荷分散に使用される転送ルールの最大数と 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）または IP アドレスの CIDR ブロック（/24 か /16）のいずれかです。エイリアス IP アドレスはサブネットのプライマリまたはセカンダリ IP 範囲のいずれかから取得されます。この上限において、GCP はエイリアス範囲のサイズ（ネットマスク）を考慮しません。ネットワーク内のすべての VM に割り当てられるエイリアス IP（範囲）の数のみがカウントされます。この割り当てに加えて、ネットワークインターフェースごとのエイリアス IP 範囲の数には VM ごとに上限があります。
サブネットあたりのプライマリ IP 範囲	1	各サブネットにはプライマリ IP 範囲（CIDR ブロック）が 1 つ必要です。この範囲は、VM のプライマリ内部 IP アドレス、VM のエイリアス IP アドレス、内部 TCP / UDP ロードバランサの IP アドレスに使用されます。この上限を引き上げることはできません。
サブネットあたりのセカンダリ IP 範囲	5	必要に応じて、サブネットごとに最大 5 つのセカンダリ CIDR ブロックを定義できます。このセカンダリ IP 範囲は、エイリアス IP アドレスにのみ使用できます。この上限を引き上げることはできません。
ファイアウォールルールあたりの最大ソースタグ数	30	この上限は、上りのファイアウォールルール作成時にソースタグとして指定できるネットワークタグの最大数です。この上限を引き上げることはできません。
ファイアウォールルールあたりの最大ターゲットタグ数	70	この上限は、下りまたは上りのファイアウォールルール作成時にターゲットタグとして指定できるネットワークタグの最大数です。この上限を引き上げることはできません。
ファイアウォールルールあたりの最大ソースサービスアカウント数	10	この上限は、上りのファイアウォールルール作成時に指定できるソースサービスアカウントの最大数です。この上限を引き上げることはできません。
ファイアウォールルールあたりの最大ターゲットサービスアカウント数	10	この上限は、下りまたは上りのファイアウォールルール作成時に指定できるターゲットサービスアカウントの最大数です。この上限を引き上げることはできません。
ネットワークあたりの内部 TCP / UDP 負荷分散に使用される転送ルールの最大数	50	この上限は、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 数のセクションに、この上限の具体例を示します。
特定のネットワーク内の内部 TCP / UDP 負荷分散に使用される転送ルールの最大数	50	GCP では、以下のすべての条件を満たす限り、特定の VPC ネットワークで新しい内部転送ルールを作成できます。特定ネットワークのプロジェクト内に存在する転送ルールの総数（内部転送ルール数だけではない）が、プロジェクトあたりの転送ルールの割り当て未満であること。特定ネットワークの内部転送ルール数が、ネットワークの内部 TCP / UDP 負荷分散に使用される転送ルールの最大数未満であること。ピアリンググループの内部転送ルール数が、ピアリンググループ内の内部 TCP / UDP 負荷分散に使用される実質的な転送ルール数未満であること。これは、VPC ネットワークピアリングと内部転送ルール数の説明に従って計算されます。
ピアリンググループ内の内部 TCP / UDP 負荷分散に使用される転送ルール数	75

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 は次の方法を使用して、ピアリンググループ内の内部 TCP / UDP 負荷分散に使用される実質的な転送ルール数を計算しています。

手順 1. 特定のネットワークについて、次の 2 つの上限のうち値が大きい方を見つけます。
- 特定のネットワーク内の内部 TCP / UDP 負荷分散に使用される転送ルールの最大数
- ピアリンググループ内の内部 TCP / UDP 負荷分散に使用される転送ルール数
手順 2. ピアリンググループ内の残りの各ネットワークについて、次の 2 つの上限のうち値が大きい方を見つけます。
- ピアネットワーク内の内部 TCP / UDP 負荷分散に使用される転送ルールの最大数
- ピアリンググループ内の内部 TCP / UDP 負荷分散に使用される転送ルール数
手順 3. 手順 2 で作成したリストから最小値を見つけます。
手順 4. 手順 1 と手順 3 の 2 つの数のうち値が大きい方を選びます。この数が、特定のネットワークの観点から見た場合にピアリンググループ内で作成できる、内部 TCP / UDP 負荷分散に使用される実質的な転送ルール数となります。

たとえば、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 とピアリングされています。

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

ネットワーク	特定のネットワーク内の内部 TCP / UDP 負荷分散に使用される転送ルールの最大数	ピアリンググループ内の内部 TCP / UDP 負荷分散に使用される転送ルール数
`network-a`	160	150
`network-b`	50	60
`network-c`	65	70
`network-d`	50	80

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

network-a の観点から見た場合、ピアリンググループには network-a、network-b、network-c が含まれています。ピアリンググループ内の内部 TCP / UDP 負荷分散に使用される実質的な転送ルール数は、次のように計算されます。
1. network-a では max(160,150) = 160 になります。
2. 残りのピアネットワークでは次のようになります。
  - network-b では max(50,60) = 60 になります。
  - network-c では max(65,70) = 70 になります。
3. min(60,70) = 60
4. max(160,60) = 160
  - ピアリンググループあたりの内部 TCP / UDP 負荷分散に使用される実質的な転送ルール数は、network-a の観点から見ると 160 になります。
network-b の観点から見た場合、ピアリンググループには network-b、network-a が含まれています。ピアリンググループ内の内部 TCP / UDP 負荷分散に使用される実質的な転送ルール数は、次のように計算されます。
1. network-b では max(50,60) = 60 になります。
2. 残りのピアネットワークでは次のようになります。
  - network-a では max(160,150) = 160 になります。
3. min(160) = 160
4. max(60,160) = 160
  - ピアリンググループあたりの内部 TCP / UDP 負荷分散に使用される実質的な転送ルール数は、network-b の観点から見ると 160 になります。
network-c の観点から見た場合、ピアリンググループには network-c、network-a、network-d が含まれています。ピアリンググループ内の内部 TCP / UDP 負荷分散に使用される実質的な転送ルール数は、次のように計算されます。
1. network-c では max(65,70) = 70 になります。
2. 残りのピアネットワークでは次のようになります。
  - network-a では max(160,150) = 160 になります。
  - network-d では max(50,80) = 80 になります。
3. min(160,80) = 80
4. max(70,80) = 80
  - ピアリンググループあたりの内部 TCP / UDP 負荷分散に使用される実質的な転送ルール数は、network-c の観点から見ると 80 になります。
network-d の観点から見た場合、ピアリンググループには network-d、network-c が含まれています。ピアリンググループ内の内部 TCP / UDP 負荷分散に使用される実質的な転送ルール数は、次のように計算されます。
1. network-d では max(50,80) = 80 になります。
2. 残りのピアネットワークでは次のようになります。
  - network-c では max(65,70) = 70 になります。
3. min(70) = 70
4. max(80,70) = 80
  - ピアリンググループあたりの内部 TCP / UDP 負荷分散に使用される実質的な転送ルール数は、network-d の観点から見ると 80 になります。

インスタンス単位

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 に接続された永続ディスクへのデータ転送も含まれます。実際の下り速度はその他の要因に左右されます。詳細については、こちらのページをご覧ください。

概要

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

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

権限

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

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

割り当て量を確認する

GCP 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 リクエストで割り当てを超えた場合、GCP は次の HTTP ステータスコードを返します。HTTP 413 Request Entity Too Large。

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

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

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

リソースの可用性

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

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