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 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.
Forwarding rules	Quotas	This quota includes both internal and external forwarding rules. For internal forwarding rules, other limits apply. See Forwarding rules for Internal 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	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 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.
Forwarding rules for Internal Load Balancing per network	50	This represents the maximum number of internal forwarding rules within a given 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 is a collection of VPC networks that are directly peered to one another. 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 a peering group, not including the network itself.
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 forwarding rules for Internal Load Balancing in a peering group	75	GCP uses this limit along with other information to determine if you can create a new internal forwarding rule in a VPC network connected to others using VPC Network Peering. See VPC Network Peering and internal forwarding rules following this table for an explanation.

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

GCP allows you to create a new internal forwarding rule in a given VPC network only if all three of these conditions are true:

The number of all forwarding rules (not just internal forwarding rules) for all networks in the network's project is less than or equal to that project's forwarding rules quota.
The number of internal forwarding rules in the given network is less than or equal to the number of forwarding rules for Internal Load Balancing for that network.
The number of internal forwarding rules in the given network is less than or equal to an effective number of forwarding rules for Internal Load Balancing in the network's peering group, which is calculated from both the number of forwarding rules for Internal Load Balancing in the peering group set on the given VPC network and the number of forwarding rules for Internal Load Balancing in the peering group set on the other networks in that same group. The details for this method are described below.

From the perspective of the given VPC network, GCP calculates an effective number of forwarding rules for Internal Load Balancing in the peering group using this method:

Step 1. Find the minimum of the number of forwarding rules for Internal Load Balancing in a peering group for every network in the peering group except the given network.
Step 2. Pick the maximum between the given network's number of forwarding rules for Internal Load Balancing in a peering group and the number from Step 1. This number becomes the effective number of forwarding rules for Internal Load Balancing in a peering group for 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 that the configured number of forwarding rules for Internal Load Balancing in a peering group in each network are:

network-a: 150
network-b: 60
network-c: 70
network-d: 80

From the perspective of each VPC network, GCP calculates the effective number of forwarding rules for Internal 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 Load Balancing in its peering group is: max(150, min(60,70)) = 150
From the perspective of network-b, its peering group contains network-b and network-a. The effective number of forwarding rules for Internal Load Balancing in its peering group is: max(60, min(150)) = 150
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 Load Balancing in its peering group is: max(70, min(150,80)) = 80
From the perspective of network-d, its peering group contains network-d network-c. The effective number of forwarding rules for Internal Load Balancing in its peering group is: max(80, min(70)) = 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	2 Gbps per vCPU Up to 16 Gbps	GCP limits egress traffic to 2 Gbps per vCPU for machine types with eight or fewer vCPUs. Machine types with more than eight vCPUs are limited to 16 Gbps, and shared-core machine types are limited to 1 Gbps. Actual egress rates depend on other factors; refer to this page for more information. Egress rates include data transfer rates to persistent disks.

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

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.