割り当てと上限

以下の各セクションでは、Virtual Private Cloud（VPC）ネットワークの割り当てと上限について説明します。

割り当て

Google Cloud Console を使用して、追加の割り当てをリクエストします。

プロジェクト単位

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

Cloud Monitoring を使用してプロジェクトごとに割り当てをモニタリングするには、Consumer Quota リソースタイプで指標 serviceruntime.googleapis.com/quota/allocation/usage のモニタリングを設定します。割り当てタイプに到達するように、追加のラベルフィルタ（service、quota_metric）を設定します。割り当て指標のモニタリングの詳細については、割り当て指標の使用をご覧ください。

割り当て 説明
インターネット下り（外向き）帯域幅 プロジェクトのすべての VPC ネットワーク内の Google Cloud VM から送信される、リージョンあたりのインターネット下り（外向き）帯域幅。
ネットワーク default ネットワーク（削除可能）が含まれます。
サブネット プロジェクト内のすべてのネットワークのすべてのサブネットに適用されます。
ルート プロジェクト内のすべての VPC ネットワークで定義されているカスタム静的ルートをカウントします。次のタイプのルートは含まれません。
  • プロジェクト内の VPC ネットワークのサブネット ルート
  • プロジェクト内の Cloud Router が学習したカスタム動的ルート
  • プロジェクト内の VPC ネットワークにインポートされたピアリング接続のサブネット ルート
  • プロジェクト内の VPC ネットワークにインポートされたピアリング接続のカスタムルート
Cloud Router 任意のネットワークとリージョンで、プロジェクト内に作成できる Cloud Router の数。また、各ネットワークには、リージョン内の Cloud Router 数にも上限があります。詳細については、Cloud Router の割り当てと上限をご覧ください。
ファイアウォール ルール プロジェクト内のすべての VPC ネットワークに対して作成できるファイアウォール ルールの数。
転送ルール この割り当ては、外部 HTTP(S) 負荷分散、SSL プロキシ負荷分散、TCP プロキシ負荷分散、Classic VPN ゲートウェイの転送ルールにのみ適用されます。
これらを除く転送ルールの使用例については、次の行をご覧ください。
外部 TCP / UDP ネットワーク負荷分散の転送ルール 外部 TCP / UDP ネットワーク ロードバランサ（バックエンド サービスとターゲット プール アーキテクチャの両方）で使用される転送ルール。
外部プロトコルの転送ルール ターゲット インスタンスへの外部プロトコル転送の転送ルール。
Traffic Director の転送ルール Traffic Director の転送ルール
内部転送ルール 内部 HTTP(S) 負荷分散、内部 TCP / UDP 負荷分散、内部プロトコル負荷分散で使用されるすべての内部転送ルールについては、ネットワーク割り当てをご覧ください。
内部 IP アドレス プロジェクトの各リージョンで予約できる静的リージョン内部 IP アドレスの数。
グローバル内部 IP アドレス プライベート サービス アクセス用に予約できる割り振り済み範囲の数。各範囲は、連続した内部 IP アドレス範囲です。
静的 IP アドレス プロジェクトの各リージョンで予約できる静的リージョン外部 IP アドレスの数。
静的 IP アドレス グローバル プロジェクトで予約できる静的グローバル外部 IP アドレスの数。
Packet Mirroring ポリシー 任意のネットワークとリージョンで、プロジェクト内に作成できるパケット ミラーリング ポリシーの数。この割り当てを増やす必要がある場合は、Google Cloud セールスチームにお問い合わせください。

ネットワーク単位

次の表は、重要なネットワーク割り当てをまとめたものです。その他の割り当てについては、Cloud Console の [割り当て] ページをご覧ください。

Cloud Monitoring を使用した使用可能な指標のモニタリングについては、割り当て指標の使用をご覧ください。

割り当て 説明
ネットワークあたりの VM インスタンス

VPC ネットワーク ピアリングを使用してネットワークを他のネットワークに接続すると、この上限が低下することがあります。詳細については、VPC ネットワーク ピアリングに関する上限をご覧ください。

割り当て名:
INSTANCES_PER_NETWORK_GLOBAL

利用可能な指標

  • compute.googleapis.com/quota/instances_per_vpc_network/limit
  • compute.googleapis.com/quota/instances_per_vpc_network/usage
  • compute.googleapis.com/quota/instances_per_vpc_network/exceeded
サブネット単位の VM インスタンスの最大数 特に制限はありません。
ネットワークごとのエイリアス IP 範囲

エイリアス IP 範囲は、VM のネットワーク インターフェースに割り当てられた単一の IP アドレス（/32）または CIDR ブロック（/24 または /16）のどちらかです。エイリアス IP アドレスはサブネットのプライマリまたはセカンダリ IP 範囲のどちらかから取得されます。

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

この割り当てに加えて、ネットワーク インターフェース単位のエイリアス IP 範囲の数には VM ごとに上限があります。

割り当て名:
ALIASES_PER_NETWORK_GLOBAL

利用可能な指標

  • compute.googleapis.com/quota/ip_aliases_per_vpc_network/limit
  • compute.googleapis.com/quota/ip_aliases_per_vpc_network/usage
  • compute.googleapis.com/quota/ip_aliases_per_vpc_network/exceeded
VPC ネットワークあたりのサブネット IP 範囲（プライマリとセカンダリ）

VPC ネットワーク内のすべてのサブネットに割り当てられたプライマリおよびセカンダリのサブネット IP 範囲の合計数です。

割り当て名:
SUBNET_RANGES_PER_NETWORK

利用可能な指標

  • compute.googleapis.com/quota/subnet_ranges_per_vpc_network/limit
  • compute.googleapis.com/quota/subnet_ranges_per_vpc_network/usage
  • compute.googleapis.com/quota/subnet_ranges_per_vpc_network/exceeded
VPC ネットワークあたりの内部ロードバランサ転送ルール

内部ロードバランサに使用される転送ルールの最大数。

  • 内部 TCP / UDP 負荷分散
  • 内部 HTTP(S) 負荷分散

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

ネットワークが VPC ネットワーク ピアリングを使用して他のネットワークに接続している場合は、VPC ネットワーク ピアリングに関する上限をご覧ください。

割り当て名:
INTERNAL_FORWARDING_RULES_PER_NETWORK

利用可能な指標

  • compute.googleapis.com/quota/internal_lb_forwarding_rules_per_vpc_network/limit
  • compute.googleapis.com/quota/internal_lb_forwarding_rules_per_vpc_network/usage
  • compute.googleapis.com/quota/internal_lb_forwarding_rules_per_vpc_network/exceeded
内部プロトコル転送の転送ルール

内部プロトコル転送に使用される転送ルールの最大数。

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

ネットワークが VPC ネットワーク ピアリングを使用して他のネットワークに接続している場合は、VPC ネットワーク ピアリングに関する上限をご覧ください。

割り当て名:
INTERNAL_FORWARDING_RULES_WITH_TARGET_INSTANCE_PER_NETWORK

利用可能な指標

  • compute.googleapis.com/quota/internal_protocol_forwarding_rules_per_vpc_network/limit
  • compute.googleapis.com/quota/internal_protocol_forwarding_rules_per_vpc_network/usage
  • compute.googleapis.com/quota/internal_protocol_forwarding_rules_per_vpc_network/exceeded
Private API Connect for Google API の転送ルール

Private Service Connect に使用される転送ルールの最大数。

この上限は、すべてのリージョンで Private Service Connect に使用される転送ルールの合計数に適用されます。

この上限を引き上げることはできません。

作成できるグローバル内部アドレスの数に関する重要な詳細については、プロジェクトごとをご覧ください。

割り当て名:
PSC_GOOGLE_APIS_FORWARDING_RULES_PER_NETWORK

利用可能な指標

  • compute.googleapis.com/quota/psc_google_apis_forwarding_rules_per_vpc_network/limit
  • compute.googleapis.com/quota/psc_google_apis_forwarding_rules_per_vpc_network/usage
  • compute.googleapis.com/quota/psc_google_apis_forwarding_rules_per_vpc_network/exceeded

上限

特に注記がある場合を除き、一般的に上限を引き上げることはできません。

組織単位

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

項目 上限 注
組織単位の非関連階層型ファイアウォール ポリシー数 50

非関連ポリシーは、Google Cloud 組織に存在しているものの、ノードには関連付けられていないポリシーです。組織が持つことのできるノードに関連付けられるポリシーの数に上限はありませんが、各ノードには 1 つのポリシーしか関連付けられません。

この上限を増やす必要がある場合は、Google Cloud セールスチームにお問い合わせください。
階層型ファイアウォール ポリシーにおける階層型ファイアウォール ルール属性数 2,000

階層型ファイアウォール ポリシーにおけるすべてのルールのルール属性数。ルール数ではなく、ポリシーにおけるすべてのルールの総属性数のみで算出します。

ルールの属性は、IP 範囲、プロトコル、ポートまたはポート範囲、ターゲット サービス アカウント、またはターゲット リソースです。例:

  • 10.100.0.1/32 のソース IP 範囲と tcp:5000-6000 の宛先ポートを指定するルールでは、IP 範囲 1 つ、プロトコル 1 つ、ポート範囲 1 つで、3 つの属性として数えられます。
  • 10.100.0.1/32 と 10.100.1.1/32 のソース範囲、tcp:80、tcp:443、udp:4000-5000、icmp の宛先プロトコルと宛先ポートを指定するルールでは、2 つの IP 範囲に対して 1 つずつ、4 つのプロトコルに対して 1 つずつ、3 つのポートまたはポート範囲に対して 1 つずつで、9 つの属性として数えられます。

ポリシーの属性数を確認するには、ポリシーの説明をご覧ください。この上限を増やす必要がある場合は、Google Cloud セールスチームにお問い合わせください。

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

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

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

ネットワーク単位

VPC ネットワークには次の上限が適用されます。これらの上限は、割り当てを使用して内部的に適用されます。ネットワーク単位の上限を超過すると、内部割り当て名での QUOTA_EXCEEDED エラーが表示される場合があります。

項目 上限 注
サブネット IP 範囲
サブネット単位のプライマリ IP 範囲 1 各サブネットにはプライマリ IP 範囲（CIDR ブロック）が 1 つ必要です。この範囲は、VM のプライマリ内部 IP アドレス、VM のエイリアス IP 範囲、内部ロードバランサの IP アドレスに使用されます。この上限を引き上げることはできません。
サブネット単位のセカンダリ IP 範囲の最大数 30 必要に応じて、サブネットごとに最大 30 個のセカンダリ CIDR ブロックを定義できます。このセカンダリ IP 範囲は、エイリアス IP 範囲にのみ使用できます。この上限を引き上げることはできません。
1 つのファイアウォール ルールあたりの最大ソースタグ数 30 上り（内向き）ファイアウォール ルールの作成時にソースタグとして指定できるネットワーク タグの最大数。この上限を引き上げることはできません。
ファイアウォール ルール単位の最大ターゲットタグ数 70 下り（外向き）または上り（内向き）ファイアウォール ルールの作成時にターゲットタグとして指定できるネットワーク タグの最大数。この上限を引き上げることはできません。
ファイアウォール ルール単位の最大ソースサービス アカウント数 10 上り（内向き）ファイアウォール ルールの作成時に指定できるソース サービス アカウントの最大数。この上限を引き上げることはできません。
ファイアウォール ルール単位の最大ターゲット サービス アカウント数 10 下り（外向き）または上り（内向き）ファイアウォール ルールの作成時に指定できるターゲット サービス アカウントの最大数。この上限を引き上げることはできません。
ファイアウォール ルール単位の最大ソース範囲数 256 上り（内向き）ファイアウォール ルールの作成時に指定できるソース IP 範囲の最大数。この上限を引き上げることはできません。
ファイアウォール ルール単位の最大送信先範囲数 256 下り（外向き）ファイアウォール ルールの作成時に指定できる宛先 IP 範囲の最大数。この上限を引き上げることはできません。

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

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

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

項目 上限 注
ピアリング グループ
1 つの VPC ネットワークへの最大接続数 25 特定の VPC ネットワークに VPC ネットワーク ピアリングを使用して接続できるネットワークの最大数。
ピアリング グループ内の最大サブネット ルート数 特に制限なし 交換できるサブネット ルートの数は、このドキュメントの後半で説明する、サブネット IP 範囲の最大数（プライマリとセカンダリ）によって制限されます。
ピアリング グループ内の最大静的ルート数 300 カスタムルートのインポートとエクスポートをする際にピアリング グループ内のネットワーク間で交換できる静的ルートの最大数。ピアリング グループがこの上限を超える場合、Google Cloud ではネットワークのピアリング接続を作成できません。
ピアリング グループ内の最大動的ルート数 300 カスタムルートのインポートとエクスポートをする際に、Cloud Router でピアリング グループのすべてのネットワークに適用できる動的ルートの最大数。動的ルート数がこの上限を超える場合、Google Cloud では特定のネットワークの動的ルートをインポートする方法が以下のように調整されます。
  • Google Cloud では、ピアリングされたネットワークからインポートした動的ルートがドロップされます。 内部アルゴリズムを使用して動的ルートをドロップするため、最近追加されたルートだけでなく、古いルートもドロップされる可能性があります。インポートした動的ルートのうち、どの動的ルートがドロップされるかを予測することはできません。そこで、ピアリング グループ内の動的ルートの数を減らすことをおすすめします。
  • Cloud Router の上限の適用により、ローカル ネットワークの Cloud Router が学習した動的ルートが Google Cloud によってドロップされることはありません。
  • ピアリング接続することでこの上限を超える場合でも、Google Cloud でピアリング接続を作成できます。警告は表示されません。
インスタンス
VM インスタンスの最大数

ネットワークあたり 15,000

ピアリング グループあたり 15,500

Google Cloud では、以下のすべての条件を満たす限り、特定の VPC ネットワークで新しいインスタンスを作成できます。

  • この上限で定義された 1 ネットワークあたりの最大数を超えていないこと。
  • この上限で定義された 1 ピアリング グループあたりの最大数を超えていないこと。

例については、VPC ネットワーク ピアリングと最大 VM 数をご覧ください。

上限超過のエラーコード:
INSTANCES_PER_NETWORK_WITH_PEERING_LIMITS_EXCEEDED
サブネット IP 範囲
サブネット IP 範囲の最大数（プライマリとセカンダリ） 400

ピアリング グループ内のすべてのネットワークでサブネットに割り当てられる、プライマリおよびセカンダリのサブネット IP 範囲の最大数です。

上限超過のエラーコード:
SUBNET_RANGES_PER_NETWORK_LIMITS_EXCEEDED_PEERING
内部負荷分散

次に使用される転送ルールの最大数:

  • 内部 TCP / UDP 負荷分散
  • 内部 HTTP(S) 負荷分散

ネットワークあたり 75

ピアリング グループあたり 175

以下のすべての条件に該当する場合、内部負荷分散のための新しいリージョン内部転送ルールを作成できます。

  • この割り当てで定義された 1 ネットワークあたりの最大数を超えていないこと。
  • 内部負荷分散の場合は、内部転送ルール数が、ピアリング グループ内の実質的な転送ルール数未満であること。実質的な転送ルール数は、VPC ネットワーク ピアリングと内部転送ルール数の説明に従って計算されます。

上限超過のエラーコード:
INTERNAL_FORWARDING_RULES_WITH_PEERING_LIMITS_EXCEEDED
プロトコル転送
内部プロトコル転送に使用される転送ルールの最大数

ネットワークあたり 50

ピアリング グループあたり 100

以下のすべての条件に該当する場合、プロトコル転送のための新しいリージョン内部転送ルールを作成できます。

  • この割り当てで定義された 1 ネットワークあたりの最大数を超えていないこと。
  • ピアリング グループ内のプロトコル転送で使用される内部転送ルール数が、ピアリング グループ内の実質的な転送ルール数未満であること。これは、VPC ネットワーク ピアリングと内部転送ルール数の説明に従って計算されます。

上限超過のエラーコード:
INTERNAL_FORWARDING_RULES_WITH_TARGET_INSTANCE_LIMITS_EXCEEDED_PEERING
ピアリング グループ内のエイリアス IP 範囲の割り当ての最大数 15,000

エイリアス IP 範囲は、VM のネットワーク インターフェースに割り当てられた単一の IP アドレス（/32）または CIDR ブロック（/24 または /16）のどちらかです。エイリアス IP アドレスはサブネットのプライマリまたはセカンダリ IP 範囲のどちらかから取得されます。

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

この割り当てに加えて、ネットワーク インターフェース単位のエイリアス IP 範囲の数には VM ごとに上限があります。

上限超過のエラーコード:
ALIASES_PER_NETWORK_PEERING_LIMITS_EXCEEDED

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） VPC の構成に応じて 1,460 バイトまたは 1,500 バイト これよりも大きい 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 を試しているユーザーをトライアルに留めておくのにも役立ちます。

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

権限

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

タスク 必要なロール
プロジェクトの割り当て量をチェックする 次のいずれかが必要です。
割り当て量の変更、割り当て量の追加のリクエストを行う 次のいずれかが必要です。

割り当て量を確認する

Console

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

    [割り当て] に移動

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

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

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

    [割り当て] に移動

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

リソースの可用性

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

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

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