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 bothnetwork-a
andnetwork-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 bothnetwork-a
andnetwork-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 withnetwork-b
, andnetwork-b
is peered withnetwork-a
network-a
is peered withnetwork-c
, andnetwork-c
is peered withnetwork-a
network-c
is peered withnetwork-d
, andnetwork-d
is peered withnetwork-c
And that the configured number of forwarding rules for Internal Load Balancing in a peering group in each network are:
network-a
: 150network-b
: 60network-c
: 70network-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 containsnetwork-a
,network-b
, andnetwork-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 containsnetwork-b
andnetwork-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 containsnetwork-c
,network-a
, andnetwork-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 containsnetwork-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.
- 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.