VPC resource quotas

Quotas and limits

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

Per organization

The following limits apply to organizations.

Item	Limit	Notes
Hierarchical firewall policies per organization	10	Contact your Google Cloud sales team if you need to increase this limit.
Hierarchical firewall rule attributes in a hierarchical firewall policy	250	The number of rule attributes in all rules in a hierarchical firewall policy. The number of rules does not matter, only the total number of attributes in all rules in the policy. A rule "attribute" is an IP range, protocol, or protocol-and-port-range. Examples: A rule that specifies a source IP range of 10.100.0.1/32 and destination ports of tcp:5000-6000 counts as two attributes, one for the IP range and one for the protocol-and-port-range. A rule that specifies source ranges of 10.100.0.1/32 and 10.100.1.1/32 and specifies destination protocols and ports of tcp:80,tcp:443, udp:4000-5000, and icmp count as six, one each for the two IP ranges and one each for the four protocols or protocols-and-port-ranges. To view how many attributes your policy has, see Describe a policy. Contact your Google Cloud sales team if you need to increase this limit.

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.
System-generated and custom static routes	Quotas	This quota does not include custom dynamic routes that are learned by Cloud Router.
Cloud Routers	Quotas	This quota represents the number of Cloud Routers that 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.
Internal IP addresses	Quotas	This quota represents the number of static regional internal IP addresses that you can reserve in each region in your project.
Global internal IP addresses	Quotas	This quota represents the number of allocated ranges that you can reserve for private services access. Each range is a contiguous internal IP address range.
Static IP addresses	Quotas	This quota represents the number of static regional external IP addresses that you can reserve in each region in your project.
Static IP addresses global	Quotas	This quota represents the number of static global external IP addresses that you can reserve in your project.
Packet mirroring policies	Quotas	This limit represents the number packet mirroring policies that you can create in your project, in any network and region. Contact your Google Cloud sales team if you need to increase this limit.

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	1,000	Contact your Google Cloud sales team if you need to increase this limit.
Number of Shared VPC host projects in a single organization	100	Contact your Google Cloud 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 Google Cloud sales team.

Item	Limit	Notes
Instances
Maximum number of VM instances per network	15,000	This limit might be lower when you connect the network to others using VPC Network Peering. See VPC Network Peering limits for details.
Maximum number of VM instances per subnet		No separate restriction.
Maximum number of assigned alias IP ranges	15,000	An alias IP range 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, Google Cloud does not consider the size of the range's netmask. 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.
Subnet IP ranges
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 ranges, and the IP addresses of internal load balancers. This limit cannot be increased.
Maximum number of 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 ranges. This limit cannot be increased.
Maximum number of subnet IP ranges (primary and secondary)	300	The total number of primary and secondary subnet IP ranges assigned to all subnets in a 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.
Internal load balancing
Maximum number of forwarding rules for: - Internal TCP/UDP Load Balancing - Internal HTTP(S) Load Balancing	75	This represents the maximum number of forwarding rules for internal load balancers. This limit applies to the total number of forwarding rules for internal load balancing; it does not apply to each region individually. See VPC Network Peering limits for additional important details if your network is connected to others using VPC Network Peering.
Protocol forwarding
Maximum number of forwarding rules for internal protocol forwarding	50	This represents the maximum number of forwarding rules for internal protocol forwarding. This limit applies to the total number of forwarding rules for internal protocol forwarding; it does not apply to each region individually. See VPC Network Peering limits for additional important details if your network is connected to others using VPC Network Peering.

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 Google Cloud sales team if you have questions about increasing them.

Item	Limit	Notes
Peering group
Maximum number of connections to a single VPC network	25	This limit represents the maximum number of networks that can connect to a given VPC network using VPC Network Peering.
Maximum number of subnet routes in a peering group	No separate restriction	The number of subnet routes that can be exchanged is limited by the maximum number of subnet IP ranges (primary and secondary) per peering group, described below.
Maximum number of static routes in a peering group	300	This limit represents the maximum number of static routes that can be exchanged among networks in a peering group when importing and exporting custom routes. Google Cloud prevents you from creating a peering connection to a network if that would cause the peering group to exceed this limit.
Maximum number of dynamic routes in a peering group	300	This limit represents the maximum number of dynamic routes that Cloud Routers can apply to all networks of a peering group when importing and exporting custom routes. If the number of dynamic routes exceeds this limit, Google Cloud adjusts how it imports dynamic routes for a given network: Google Cloud drops imported dynamic routes from peered networks. Google Cloud uses an internal algorithm to drop dynamic routes, which means Google Cloud 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, Google Cloud never drops dynamic routes that are learned by Cloud Routers in the local network. If a peering connection causes this limit to be exceeded, Google Cloud still allows you to create the peering connection without warning.
Instances
Maximum number VM instances	15,000 per network 15,500 per peering group	Google Cloud allows you to create a new instance in a given VPC network as long as all of the following are true: You have not exceeded the per network maximum defined by this limit. You have not exceeded the per peering group maximum defined by this limit. For examples, see VPC Network Peering and maximum VMs.
Subnet IP ranges
Maximum number of subnet IP ranges (primary and secondary)	400	The maximum number of primary and secondary subnet IP ranges that can be assigned to subnets in all networks of a peering group.
Internal load balancing
Maximum number of forwarding rules for: - Internal TCP/UDP Load Balancing - Internal HTTP(S) Load Balancing	75 per network 175 per peering group	You can create new regional internal forwarding rules for internal load balancing if all of the following conditions 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. You have not exceeded the per network maximum defined by this limit. For internal load balacing, the number of internal forwarding rules must be less than the effective number of forwarding rules in the peering group. The effective number is a calculation that is described in VPC Network Peering and internal forwarding rules.
Protocol forwarding
Maximum number of forwarding rules for internal protocol forwarding	50 per network 100 per peering group	You can create new regional internal forwarding rules for protocol forwarding if all of the following conditions 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. You have not exceeded the per network maximum defined by this limit. The number of internal forwarding rules, for protocol forwarding, in the peering group, is less than an effective number of forwarding rules in the peering group, which is calculated as described in VPC Network Peering and internal forwarding rules.

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, Google Cloud 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, Google Cloud 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 Google Cloud does not consider the size of the alias IP range's netmask. For example, an individual /24 range is a single alias IP range and an individual /23 range is also a single alias IP range. Contact your Google Cloud 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 to an internal IP address	No artificial limit	Google Cloud does not artificially cap VM instance ingress traffic unless the traffic is sent to an associated external IP address. See Inbound bandwidth to an internal IP address in the Compute Engine documentation for details.
Maximum ingress data rate to an external IP address	no more than 20Gb/s no more than 1,800,000 packets per second	Traffic sent to the external IP address associated with a VM cannot exceed 20Gb/s or 1,800,000 packets per second, whichever limit is reached first. Neither of these limits is a guarantee — ingress data rates are also limited by other factors, such as machine type. See Inbound bandwidth to an external IP address in the Compute Engine documentation for details.
Maximum egress data rate	Depends on the machine type of the VM. For more information, see the network bandwidth for each machine type.	Egress traffic is the total outgoing bandwidth shared among all network interfaces of a VM, including data transfer to persistent disks that are connected to the VM. Actual egress rates depend on additional factors, and egress to the internet is described in the next row.
Maximum egress data rate to an external IP address	all flows: about 7Gb/s sustained single flow: 3Gb/s sustained	A single flow is defined as a unique 5-tuple of source IP address, source port, destination IP address, destination port, and protocol. This egress rate is applicable when connecting to an external IP address used by a Google Cloud resource or when sending traffic to the internet.

Connection logging limits

The maximum number of connections that can be logged per VM instance depends on its machine type. Connection logging limits are expressed as the maximum number of connections that can be logged in a five-second interval.

Important: Firewall log entries are created on a best effort basis according to the following table. It is possible for entries to not be logged during periods of heavy traffic, even if the maximum number of logged connections for a machine type has not been reached.

Instance machine type	Maximum number of connections logged in a 5-second interval
f1-micro	100 connections
g1-small	250 connections
Machine types with 1–8 vCPUs	500 connections per vCPU
Machine types with more than 8 vCPUs	4,000 (500×8) connections

Hybrid connectivity

Use the following links to find quotas and limits for Cloud VPN, Cloud Interconnect, and Cloud Router:

• Cloud VPN quotas and limits
• Cloud Interconnect quotas and limits
• Cloud Router quotas and limits

Overview

Virtual Private Cloud enforces quotas on resource usage for a variety of reasons. For example, quotas protect the community of Google Cloud users by preventing unforeseen spikes in usage. Quotas also help users who are exploring Google Cloud 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, Cloud Identity and Access Management (Cloud 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 Cloud 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, Google Cloud returns the following HTTP status code: HTTP 413 Request Entity Too Large.

Requesting additional quota

Request additional quota from the Quotas page in the Cloud Console. Quota requests take 24 to 48 hours to process.

1. Go to the Quotas page.

   Go to the Quotas page

2. On the Quotas page, select the quotas that 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 then click Next.
5. Fill in your quota request, and then 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 a 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 service level agreement (SLA) for the type of resource. For more information, review the relevant SLA for the resource.