VPC resource quotas

Quotas and limits

The following sections describe quotas and limits for VPC networks. To change a quota, simply request additional quota using the GCP Console. Limits cannot generally be increased unless specifically noted.

Per project

This table highlights important global quotas for VPC resources in each project. See the quotas page for other quotas.

Item Quota Notes
Networks Quotas This includes the default network, which you can remove.
Subnets Quotas Applies to all subnets in all networks in the project.
Allocated IP address ranges Quotas This quota represents the number of contiguous internal IP address ranges you can allocate for private services access. This quota applies to your project, not to particular VPC networks or regions.
System-generated and
custom static routes		 Quotas This quota does not include custom dynamic routes learned by Cloud Router.
Cloud Routers Quotas This quota represents the number of Cloud Routers you can create within your project, in any network and region. Networks also have a limit on the number of Cloud Routers in any given region. See Cloud Router quotas and limits for more details.
Firewall rules Quotas This quota represents the number of firewall rules you can create for all VPC networks in your project.
Forwarding rules Quotas This quota includes both internal and external forwarding rules. For internal forwarding rules, other limits apply. See Forwarding rules for the internal load balancers per network and VPC Network Peering limits for details.

Shared VPC project limits

The following limits apply to projects that participate in Shared VPC.

Item Limit Notes
Number of service projects that can be attached to a host project Up to 100 This limit can vary and might be lower than 100. Contact your GCP sales team if you have questions or if you need to increase this limit.
Number of Shared VPC host projects in a single organization 100 Contact your GCP sales team if you need to increase this limit.
Number of host projects to which a service project can attach 1 This limit cannot be increased.

Per network

The following limits apply to VPC networks. Unless otherwise noted, these limits can be increased if you contact your GCP sales team.

Item Limit Notes
VM instances per network 15,000 The effective limit on the number of instances that you can create per network might be reduced if you connect the network to others using VPC Network Peering. See VPC Network Peering limits in the next section.
VM instances per subnet No separate restriction.
Assigned alias IP ranges 15,000 An alias IP is either a single IP address (/32) or a CIDR block (for example, a /24 or /16) assigned to a network interface of a VM. Alias IP addresses can come from either the primary or secondary IP ranges of a subnet.
For the purposes of this limit, GCP does not consider the size (netmask) of the alias range. It only counts the number of alias IP ranges assigned to all VMs in the network.

In addition to this quota, there is a per-VM limit on the number of alias IP ranges per network interface.
Primary IP ranges per subnet 1 Each subnet must have exactly one primary IP range (CIDR block). This range is used for VM primary internal IP addresses, VM alias IP addresses, and the IP addresses of internal load balancers. This limit cannot be increased.
Secondary IP ranges per subnet 30 Optionally, you can define up to thirty secondary CIDR blocks per subnet. These secondary IP ranges can only be used for alias IP addresses. This limit cannot be increased.
Number of subnet IP ranges (primary and secondary) 300 The total number of primary and secondary subnet IP ranges that you can assign in a single VPC network.
Maximum number of source tags per firewall rule 30 This is the maximum number of network tags that can be specified as source tags when creating an ingress firewall rule. This limit cannot be increased.
Maximum number of target tags per firewall rule 70 This is the maximum number of network tags that can be specified as target tags when creating an egress or ingress firewall rule. This limit cannot be increased.
Maximum number of source service accounts per firewall rule 10 This is the maximum number of source service accounts that can be specified when creating an ingress firewall rule. This limit cannot be increased.
Maximum number of target service accounts per firewall rule 10 This is the maximum number of target service accounts that can be specified when creating an egress or ingress firewall rule. This limit cannot be increased.
Maximum number of forwarding rules per network for:
- Internal TCP/UDP Load Balancing
- Internal HTTP(S) Load Balancing 		75 This represents the maximum number of internal forwarding rules within a network. See VPC Network Peering limits for additional important details if your network is connected to others using VPC Network Peering.
Cloud Router limits For information about the total number of routers, BGP peers, custom route advertisements, and learned routes, see Cloud Router quotas and limits.

VPC Network Peering limits

The following limits apply to VPC networks connected using VPC Network Peering. Each limit applies to a peering group, which a collection of VPC networks that are directly peered to each another. From the perspective of a given VPC network, it and all of its peer networks are in one peering group. Peering groups do not include the peers of peer networks.

These limits can sometimes be increased. Contact your GCP sales team if you have questions about increasing them.

Item Limit Notes
Number of peering connections from a single VPC network 25 This limit represents the maximum number of networks in the peering group, not including the network itself.
Number of static routes in a peering group 300 This limit represents the total number of static routes that network administrators can create in all networks of a peering group. GCP prevents you from creating a peering connection to a network if that causes the peering group to exceed this limit.
Number of dynamic routes in a peering group 300

This limit represents the total number of dynamic routes that Cloud Routers can apply to all networks of a peering group. If the number of dynamic routes exceeds this limit, GCP adjusts how it imports dynamic routes for a given network:

  • GCP drops imported dynamic routes from peered networks. GCP uses an internal algorithm to drop dynamic routes, which means GCP might drop older ones and not just the recently added routes. You cannot predict which imported dynamic routes will be dropped. Instead, you should reduce the number of dynamic routes in the peering group.
  • Subject to Cloud Router limits, GCP never drops dynamic routes that are learned by Cloud Routers in the local network.
  • If a peering connection causes this limit to be exceeded, GCP still allows you to create the peering connection without warning.
Total VM instances in a peering group 15,500 This limit represents the sum total of instances possible in the directly connected networks of a peering group.

See VPC Network Peering and maximum VMs following this table for clarifying examples of this limit.
Number of subnet IP ranges (primary and secondary) 400 The total number of primary and secondary subnet IP ranges that can be assigned in all networks of a peering group.
Maximum number of forwarding rules in the given network for:
- Internal TCP/UDP Load Balancing
- Internal HTTP(S) Load Balancing 		75 GCP allows you to create a new internal forwarding rule in a given VPC network as long as all of the following are true:
  • The total number of forwarding rules (not just internal forwarding rules) in the given network's project is less than the per-project forwarding rules quota.
  • The number of internal forwarding rules for the given network is less than the maximum number of forwarding rules for the internal load balancer in the given network.
  • The number of internal forwarding rules in the peering group is less than an effective number of forwarding rules for the internal load balancer in the peering group, which is calculated as described in VPC Network Peering and internal forwarding rules.
Number of forwarding rules in the peering group for:
- Internal TCP/UDP Load Balancing
- Internal HTTP(S) Load Balancing 		175

VPC Network Peering and maximum VMs

Up to 15,500 VM instances are allowed among the networks in a peering group. As clarifying examples, suppose network-b is peered with two other networks, network-a and network-c:

  • If network-b has 5,000 VMs, the total number of VMs you can create in both network-aand network-c combined must be less than or equal to 10,500.
  • If network-b has 500 VMs, the total number of VMs you can create in both network-aand network-c combined must be less than or equal to 15,000.

VPC Network Peering and internal forwarding rules

From the perspective of a given VPC network, GCP calculates an effective number of forwarding rules for the internal load balancers in the peering group using this method:

  • Step 1. For the given network, find the greater of these two limits:

    • Maximum number of forwarding rules for the internal load balancers in the given network
    • Number of forwarding rules for the internal load balancers in the peering group

  • Step 2. For each of the remaining networks in the peering group, find the greater of these two limits:

    • Maximum number of forwarding rules for the internal load balancers in the peer network
    • Number of forwarding rules for the internal load balancers in the peering group

  • Step 3. Find the smallest value from the list created by Step 2.

  • Step 4. Take the greater of the two numbers from Step 1 and Step 3. This number is the effective number of forwarding rules for the internal load balancers that can be created in the peering group from the perspective of the given network.

Suppose that you have four VPC networks, network-a, network-b, network-c, and network-d:

  • network-a is peered with network-b, and network-b is peered with network-a
  • network-a is peered with network-c, and network-c is peered with network-a
  • network-c is peered with network-d, and network-d is peered with network-c

And each network has the following limits:

Network Maximum number of forwarding rules for the internal load balancers in the given network Number of forwarding rules for the internal load balancers in the peering group
network-a 160 150
network-b 75 80
network-c 75 75
network-d 75 95

From the perspective of each VPC network, GCP calculates the effective number of forwarding rules for the internal load balancers in that peering group:

  • From the perspective of network-a, its peering group contains network-a, network-b, and network-c. The effective number of forwarding rules for the internal load balancers in the peering group is calculated as follows:

    1. In network-a: max(160,150) = 160
    2. In the remaining peer networks:
      • network-b: max(75,80) = 80
      • network-c: max(75,75) = 75
    3. min(80,75) = 75
    4. max(160,75) = 160
      • Effective number of forwarding rules for the internal load balancers: per peering group from the perspective of network-a: 160

  • From the perspective of network-b, its peering group contains network-b and network-a. The effective number of forwarding rules for the internal load balancers in the peering group is calculated as follows:

    1. In network-b: max(75,80) = 80
    2. In the remaining peer networks:
      • network-a: max(160,150) = 160
    3. min(160) = 160
    4. max(80,160) = 160
      • Effective number of forwarding rules for the internal load balancers per peering group from the perspective of network-b: 160

  • From the perspective of network-c, its peering group contains network-c, network-a, and network-d. The effective number of forwarding rules for the internal load balancers in the peering group is calculated as follows:

    1. In network-c: max(75,75) = 75
    2. In the remaining peer networks:
      • network-a: max(160,150) = 160
      • network-d: max(75,95) = 95
    3. min(160,95) = 95
    4. max(75,95) = 95
      • Effective number of forwarding rules for the internal load balancers per peering group from the perspective of network-c: 95

  • From the perspective of network-d, its peering group contains network-d, and network-c. The effective number of forwarding rules for the internal load balancers in the peering group is calculated as follows:

    1. In network-d: max(75,95) = 95
    2. In the remaining peer networks:
      • network-c: max(75,75) = 75
    3. min(75) = 75
    4. max(95,75) = 95
      • Effective number of forwarding rules for the internal load balancers per peering group from the perspective of network-d: 95

Per instance

The following limits apply to VM instances. Unless otherwise noted, these limits cannot be increased. See Compute Engine quotas for quotas relevant to VMs.

Item Limit Notes
Maximum Transmission Unit (MTU) 1,460 bytes Instances using larger MTU sizes can experience dropped packets. You cannot increase this MTU value.
Maximum number of network interfaces 8 Network interfaces are defined at instance creation time, and cannot be changed by editing the instance later.
Maximum number of alias IP ranges per network interface 10 The number of alias IP ranges that you can assign to a network interface as long as you don't exceed the quota for the total number of assigned alias IP ranges in the VPC network

Contact your GCP sales team if you need to increase this limit.
Network interfaces per VPC network 1 Each network interface must be connected to a unique VPC network. An instance can only have one network interface in a given VPC network.
Maximum duration for idle TCP connections 10 minutes VPC networks automatically drop idle TCP connections after ten minutes. You cannot change this limit, but you can use TCP keepalives to prevent connections to instances from becoming idle. See the Compute Engine tips and troubleshooting page for details.
Maximum ingress data rate Depends on machine type GCP does not artificially cap VM instance inbound or ingress traffic. VMs are allowed to receive as much traffic as resources and network conditions allow. For purposes of capacity planning, you should assume that each VM instance can handle no more than 10 Gbps of external Internet traffic. This value is an approximation, is not covered by an SLA, and is subject to change. Adding Alias IP addresses or multiple network interfaces to a VM does not increase its ingress capacity.
Maximum egress data rate Depends on the machine type of the VM:
  • All shared-core machine types are limited to 1 Gbps.
  • 2 Gbps per vCPU, up to 32 Gbps per VM for machine types that use the Skylake or later CPU platforms with 16 or more vCPUs. This egress rate is also available for ultramem machine types.
  • 2 Gbps per vCPU, up to 16 Gbps per VM for all other machine types with eight or more vCPUs.
 Egress traffic is the total outgoing bandwidth shared among all network interfaces of a VM. It includes data transfer to persistent disks connected to the VM.

Actual egress rates depend on other factors; refer to this page for more information.

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, GCP 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.

Was this page helpful? Let us know how we did:

Send feedback about...

This page
Documentation feedback
VPC
Product feedback