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 Internal TCP/UDP Load Balancing 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.
Total 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 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.
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 TCP/UDP load balancers. This limit cannot be increased.
Secondary IP ranges per subnet	5	Optionally, you can define up to five secondary CIDR blocks per subnet. These secondary IP ranges can only be used for alias IP addresses. This limit cannot be increased.
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 forwarding rules for Internal TCP/UDP Load Balancing per network	50	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.
Maximum number of forwarding rules for Internal TCP/UDP Load Balancing in the given network	50	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 Internal TCP/UDP Load Balancing in the given network. The number of internal forwarding rules in the peering group is less than an effective number of forwarding rules for Internal TCP/UDP Load Balancing in the peering group, which is calculated as described in VPC Network Peering and internal forwarding rules.
Number of forwarding rules for Internal TCP/UDP Load Balancing in the peering group	75

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 Internal TCP/UDP Load Balancing 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 Internal TCP/UDP Load Balancing in the given network
- Number of forwarding rules for Internal TCP/UDP Load Balancing 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 Internal TCP/UDP Load Balancing in the peer network
- Number of forwarding rules for Internal TCP/UDP Load Balancing 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 Internal TCP/UDP Load Balancing 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 Internal TCP/UDP Load Balancing in the given network	Number of forwarding rules for Internal TCP/UDP Load Balancing in the peering group
`network-a`	160	150
`network-b`	50	60
`network-c`	65	70
`network-d`	50	80

From the perspective of each VPC network, GCP calculates the effective number of forwarding rules for Internal TCP/UDP Load Balancing 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 Internal TCP/UDP Load Balancing 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(50,60) = 60
  - network-c: max(65,70) = 70
3. min(60,70) = 60
4. max(160,60) = 160
  - Effective number of forwarding rules for Internal TCP/UDP Load Balancing: 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 Internal TCP/UDP Load Balancing in the peering group is calculated as follows:
1. In network-b: max(50,60) = 60
2. In the remaining peer networks:
  - network-a: max(160,150) = 160
3. min(160) = 160
4. max(60,160) = 160
  - Effective number of forwarding rules for Internal TCP/UDP Load Balancing 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 Internal TCP/UDP Load Balancing in the peering group is calculated as follows:
1. In network-c: max(65,70) = 70
2. In the remaining peer networks:
  - network-a: max(160,150) = 160
  - network-d: max(50,80) = 80
3. min(160,80) = 80
4. max(70,80) = 80
  - Effective number of forwarding rules for Internal TCP/UDP Load Balancing per peering group from the perspective of network-c: 80
From the perspective of network-d, its peering group contains network-d, and network-c. The effective number of forwarding rules for Internal TCP/UDP Load Balancing in the peering group is calculated as follows:
1. In network-d: max(50,80) = 80
2. In the remaining peer networks:
  - network-c: max(65,70) = 70
3. min(70) = 70
4. max(80,70) = 80
  - Effective number of forwarding rules for Internal TCP/UDP Load Balancing per peering group from the perspective of network-d: 80

Per instance

The following limits apply to VM instances. They cannot be changed. 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.
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 impose bandwidth caps for ingress traffic. The amount of traffic a VM can handle depends on its machine type and operating system. Ingress data rates are not affected by the number of network interfaces a VM has or any alias IP addresses it uses.
Maximum egress data rate	Depends on the machine type of the VM: All shared-core machine types are limited to 1 Gbps. (Beta) 2 Gbps per vCPU, up to 32 Gbps per VM for machine types that use the Skylake CPU platform 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.

Go to the Quotas page.
Go to the Quotas page
In the Quotas page, select the quotas you want to change.
Click the Edit Quotas button at the top of the page.
Fill out your name, email, and phone number and click Next.
Fill in your quota request and click Next.
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.