以下の各セクションでは、Virtual Private Cloud（VPC）ネットワークの割り当てと上限について説明します。
割り当て
Google Cloud Console を使用して、追加の割り当てをリクエストします。
プロジェクト単位
次の表は、プロジェクト単位の VPC リソースの重要なグローバル割り当てを示しています。その他の割り当てについては、Cloud Console の [割り当て] ページをご覧ください。
| 割り当て | 説明 |
|---|---|
| インターネット下り（外向き）帯域幅 | プロジェクトのすべての VPC ネットワーク内の Google Cloud VM から送信される、リージョンあたりのインターネット下り（外向き）帯域幅。 |
| ネットワーク | default ネットワーク（削除可能）が含まれます。 |
| サブネット | プロジェクト内のすべてのネットワークのすべてのサブネットに適用されます。 |
| ルート | プロジェクト内のすべての VPC ネットワークで定義されているカスタム静的ルートをカウントします。次のタイプのルートは含まれません。 |
| Cloud Router | 任意のネットワークとリージョンで、プロジェクト内で作成できる Cloud Router の数。また、各ネットワークには、リージョン内の Cloud Router 数にも上限があります。詳細については、Cloud Router の割り当てと上限をご覧ください。 |
| ファイアウォール ルール | プロジェクト内のすべての VPC ネットワークに対して作成できるファイアウォール ルールの数。 |
| 転送ルール | 内部と外部両方の転送ルール数が含まれます。内部転送ルール数には、異なる上限が適用されます。詳しくは、ネットワーク単位の内部ロードバランサに使用される転送ルール数と VPC ネットワーク ピアリングに関する上限をご覧ください。 |
| 内部 IP アドレス | プロジェクトの各リージョンで予約できる静的リージョン内部 IP アドレスの数。 |
| グローバル内部 IP アドレス | プライベート サービス アクセス用に予約できる割り振り済み範囲の数。各範囲は、連続した内部 IP アドレス範囲です。 |
| 静的 IP アドレス | プロジェクトの各リージョンで予約できる静的リージョン外部 IP アドレスの数。 |
| 静的 IP アドレス グローバル | プロジェクトで予約できる静的グローバル外部 IP アドレスの数。 |
| Packet Mirroring ポリシー | 任意のネットワークとリージョンで、プロジェクト内に作成できるパケット ミラーリング ポリシーの数。この割り当てを増やす必要がある場合は、Google Cloud セールスチームにお問い合わせください。 |
上限
特に注記がある場合を除き、一般的に上限を引き上げることはできません。
組織単位
以下の上限は、組織に適用されます。
| 項目 | 上限 | 注 |
|---|---|---|
| 組織単位の階層型ファイアウォール ポリシー数 | 10 | この上限を引き上げる必要がある場合は、Google Cloud セールスチームにお問い合わせください。 |
| 階層型ファイアウォール ポリシーにおける階層型ファイアウォール ルール属性数 | 250 | 階層型ファイアウォール ポリシーにおけるすべてのルールのルール属性数。ルール数ではなく、ポリシーにおけるすべてのルールの総属性数のみで算出します。 ルール「属性」とは、IP 範囲、プロトコル、ポート（の範囲）、サービス アカウントを指します。例:
ポリシーの属性数を確認するには、ポリシーの説明をご覧ください。この上限を引き上げる必要がある場合は、Google Cloud セールスチームにお問い合わせください。 |
共有 VPC プロジェクトの上限
共有 VPC に参加するプロジェクトには、次の上限が適用されます。
| 項目 | 上限 | 注 |
|---|---|---|
| ホスト プロジェクトに接続可能なサービス プロジェクトの数 | 1,000 | この上限を引き上げる必要がある場合は、Google Cloud セールスチームにお問い合わせください。 |
| 単一の組織における共有 VPC ホスト プロジェクトの数 | 100 | この上限を引き上げる必要がある場合は、Google Cloud セールスチームにお問い合わせください。 |
| サービス プロジェクトが接続可能なホスト プロジェクトの数 | 1 | この上限を引き上げることはできません。 |
ネットワーク単位
VPC ネットワークには次の上限が適用されます。これらの上限は、割り当てを使用して内部的に適用されます。ネットワーク単位の上限を超過すると、内部割り当て名での QUOTA_EXCEEDED エラーが表示される場合があります。これらの上限は、特に明記されていない限り、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 範囲の最大数。この上限を引き上げることはできません。 |
| 内部負荷分散 | ||
次に使用される転送ルールの最大数:
|
75 | 内部ロードバランサに使用される転送ルールの最大数。 この上限は、内部負荷分散に使用される転送ルールの合計数に適用されます。各リージョンに個別には適用されません。 ネットワークが VPC ネットワーク ピアリングを使用して他のネットワークに接続している場合は、VPC ネットワーク ピアリングに関する上限をご覧ください。 割り当て名: |
| プロトコル転送 | ||
| 内部プロトコル転送に使用される転送ルールの最大数 | 50 | 内部プロトコル転送に使用される転送ルールの最大数。 この上限は、内部プロトコル転送に使用される転送ルールの合計数に適用されます。各リージョンに個別には適用されません。 ネットワークが VPC ネットワーク ピアリングを使用して他のネットワークに接続している場合は、VPC ネットワーク ピアリングに関する上限をご覧ください。 割り当て名: |
| Google API 向けの Private Service Connect | ||
| Google API 向けの Private Service Connect に使用される転送ルールの最大数 | 20 | この上限は、Private Service Connect に使用される転送ルールの最大数を表します。 この上限は、すべてのリージョンで Private Service Connect に使用される転送ルールの合計数に適用されます。この上限を引き上げることはできません。 作成できるグローバル内部アドレスの数に関する重要な詳細については、プロジェクトごとをご覧ください。 割り当て名: |
VPC ネットワーク ピアリングに関する上限
VPC ネットワーク ピアリングを使用して接続している VPC ネットワークには、次の上限が適用されます。それぞれの上限は、互いに直接ピアリングしている VPC ネットワークの集合である、ピアリング グループに適用されます。特定の VPC ネットワークの観点から見た場合、その VPC ネットワークとそのすべてのピア ネットワークは 1 つのピアリング グループに属します。ピアリング グループにはピア ネットワークのピアは含まれません。
これらの上限は引き上げることができる場合もあります。上限の引き上げに関するご質問は、Google Cloud セールスチームにお問い合わせください。
| 項目 | 上限 | 注 |
|---|---|---|
| ピアリング グループ | ||
| 1 つの VPC ネットワークへの最大接続数 | 25 | 特定の VPC ネットワークに VPC ネットワーク ピアリングを使用して接続できるネットワークの最大数。 |
| ピアリング グループ内の最大サブネット ルート数 | 特に制限なし | 交換できるサブネット ルートの数は、このドキュメントの後半で説明する、サブネット IP 範囲の最大数（プライマリとセカンダリ）によって制限されます。 |
| ピアリング グループ内の最大静的ルート数 | 300 | カスタムルートのインポートとエクスポートをする際にピアリング グループ内のネットワーク間で交換できる静的ルートの最大数。ピアリング グループがこの上限を超える場合、Google Cloud ではネットワークのピアリング接続を作成できません。 |
| ピアリング グループ内の最大動的ルート数 | 300 | カスタムルートのインポートとエクスポートをする際に、Cloud Router でピアリング グループのすべてのネットワークに適用できる動的ルートの最大数。動的ルート数がこの上限を超える場合、Google Cloud では特定のネットワークの動的ルートをインポートする方法が以下のように調整されます。
|
| インスタンス | ||
| VM インスタンスの最大数 | ネットワークあたり 15,000 ピアリング グループあたり 15,500 |
Google Cloud では、以下のすべての条件を満たす限り、特定の VPC ネットワークで新しいインスタンスを作成できます。
例については、VPC ネットワーク ピアリングと最大 VM 数をご覧ください。 上限超過のエラーコード: |
| サブネット IP 範囲 | ||
| サブネット IP 範囲の最大数（プライマリとセカンダリ） | 400 | ピアリング グループ内のすべてのネットワークでサブネットに割り当てられる、プライマリおよびセカンダリのサブネット IP 範囲の最大数です。 上限超過のエラーコード: |
| 内部負荷分散 | ||
次に使用される転送ルールの最大数:
|
ネットワークあたり 75 ピアリング グループあたり 175 |
以下のすべての条件に該当する場合、内部負荷分散のための新しいリージョン内部転送ルールを作成できます。
上限超過のエラーコード: |
| プロトコル転送 | ||
| 内部プロトコル転送に使用される転送ルールの最大数 | ネットワークあたり 50 ピアリング グループあたり 100 |
以下のすべての条件に該当する場合、プロトコル転送のための新しいリージョン内部転送ルールを作成できます。
上限超過のエラーコード: |
| ピアリング グループ内のエイリアス IP 範囲の割り当ての最大数 | 15,000 | エイリアス IP 範囲は、VM のネットワーク インターフェースに割り当てられた単一の IP アドレス（/32）または CIDR ブロック（/24 または /16）のどちらかです。エイリアス IP アドレスはサブネットのプライマリまたはセカンダリ IP 範囲のどちらかから取得されます。 この上限において、Google Cloud は範囲のネットマスクのサイズを考慮しません。ネットワーク内のすべての VM に割り当てられるエイリアス IP 範囲の数のみがカウントされます。 この割り当てに加えて、ネットワーク インターフェース単位のエイリアス IP 範囲の数には VM ごとに上限があります。 上限超過のエラーコード: |
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が含まれています。ピアリング グループ内の内部ロードバランサに使用される実質的な転送ルール数は、次のように計算されます。network-a:max(160,150) = 160- 残りのピア ネットワークでは次のようになります。
network-b:max(75,80) = 80network-c:max(75,75) = 75
min(80,75) = 75max(160,75) = 160- 内部ロードバランサに使用される実質的な転送ルール数は、
network-aの観点から見ると、1 ピアリング グループあたり160になります。
- 内部ロードバランサに使用される実質的な転送ルール数は、
network-bの観点から見た場合、ピアリング グループにはnetwork-b、network-aが含まれています。ピアリング グループ内の内部ロードバランサに使用される実質的な転送ルール数は、次のように計算されます。network-b:max(75,80) = 80- 残りのピア ネットワークでは次のようになります。
network-a:max(160,150) = 160
min(160) = 160max(80,160) = 160- 内部ロードバランサに使用される実質的な転送ルール数は、
network-bの観点から見ると、1 ピアリング グループあたり160になります。
- 内部ロードバランサに使用される実質的な転送ルール数は、
network-cの観点から見た場合、ピアリング グループにはnetwork-c、network-a、network-dが含まれています。ピアリング グループ内の内部ロードバランサに使用される実質的な転送ルール数は、次のように計算されます。network-c:max(75,75) = 75- 残りのピア ネットワークでは次のようになります。
network-a:max(160,150) = 160network-d:max(75,95) = 95
min(160,95) = 95max(75,95) = 95- 内部ロードバランサに使用される実質的な転送ルール数は、
network-cの観点から見ると、1 ピアリング グループあたり95になります。
- 内部ロードバランサに使用される実質的な転送ルール数は、
network-dの観点から見た場合、ピアリング グループにはnetwork-d、network-cが含まれています。ピアリング グループ内の内部ロードバランサに使用される実質的な転送ルール数は、次のように計算されます。network-d:max(75,95) = 95- 残りのピア ネットワークでは次のようになります。
network-c:max(75,75) = 75
min(75) = 75max(95,75) = 95- 内部ロードバランサに使用される実質的な転送ルール数は、
network-dの観点から見ると、1 ピアリング グループあたり95になります。
- 内部ロードバランサに使用される実質的な転送ルール数は、
インスタンス単位
VM インスタンスには次の上限が適用されます。特に明記のない限り、これらの上限を引き上げることはできません。VM に関する割り当てについては、Compute Engine の割り当てをご覧ください。
| 項目 | 上限 | 注 |
|---|---|---|
| Maximum Transmission Unit（MTU） | VPC の構成に応じて 1,460 バイトまたは 1,500 バイト | これよりも大きい MTU サイズを使用するインスタンスでは、パケットがドロップされる可能性があります。 この MTU 値を引き上げることはできません。 |
| ネットワーク インターフェースの最大数 | 8 | ネットワーク インターフェースは、インスタンスの作成時に定義されます。後からインスタンスを編集して変更することはできません。 |
| 1 ネットワーク インターフェースあたりのエイリアス IP 範囲の最大数 | 10 | VPC ネットワークに割り当てられたエイリアス IP 範囲の合計数の割り当てを超過しない限り、ネットワーク インターフェースに割り当てることのできるエイリアス IP 範囲の数です。 Google Cloud は、エイリアス 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 を試しているユーザーをトライアルに留めておくのにも役立ちます。
すべてのプロジェクトは同じ割り当て量で開始しますが、追加の割り当て量をリクエストすることで変更できます。一部の割り当て量は、プロダクトの使用状況に応じて自動的に増える場合があります。
権限
Identity and Access Management（IAM）のメンバーが割り当ての表示や、割り当ての増加のリクエストをするには、以下のいずれかのロールが必要です。
| タスク | 必要なロール |
|---|---|
| プロジェクトの割り当て量をチェックする | プロジェクトのオーナーまたは編集者、または割り当て閲覧者 |
| 割り当て量の変更、割り当て量の追加のリクエストを行う | プロジェクト
オーナーまたは編集者、
割り当て管理者、
または serviceusage.quotas.update 権限を持つカスタムロール
|
割り当て量を確認する
Console
- Cloud Console で、[割り当て] ページに移動します。
- 更新する割り当てを検索するには、[表をフィルタリング] を使用します。 割り当ての名前がわからない場合は、このページにあるリンクを使用します。
gcloud
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 時間かかります。
Console
- Cloud Console で、[割り当て] ページに移動します。
- [割り当て] ページで、変更する割り当てを選択します。
- ページの上部にある [割り当てを編集] をクリックします。
- 名前、メールアドレス、電話番号を入力して、[次へ] をクリックします。
- 割り当てリクエストを入力して、[完了] をクリックします。
- リクエストを送信します。
リソースの可用性
各割り当て量は、リソースを使用できるという前提で、作成可能な特定のリソースタイプの最大数を表します。割り当て量によって、リソースの可用性が保証されるわけではない点に注意することが重要です。割り当て量が使用可能でも、新しいリソースを使用できなければ、そのリソースを作成することはできません。
たとえば、us-central1 リージョンで新しいリージョンの外部 IP アドレスを作成するための割り当て量が十分にあっても、そのリージョンに使用可能な外部 IP アドレスがない場合、外部 IP アドレスは作成できません。ゾーンリソースの可用性は、新しいリソースを作成できるかにも影響を及ぼす可能性があります。
リージョン全体でリソースを使用できない状況はまれです。ただし、ゾーン内のリソースは随時消費される可能性があります。通常、リソースタイプのサービスレベル契約（SLA）には影響しません。詳細については、リソースに関連する SLA をご覧ください。