This page describe quotas and limits for Network Connectivity products. To change a quota, see requesting additional quota. Limits cannot generally be increased unless specifically noted.
This table covers important quotas per project. For other quotas, see the Cloud Console Quotas page.
|VPN gateways||Quota||For HA VPN only|
|External VPN gateways||Quota||For HA VPN only|
|VPN tunnels||Quota||This quota represents the combined total number of Classic VPN tunnels and HA VPN tunnels.|
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. For more details, see Cloud Router quotas and limits.
Subject to the Cloud Router quotas and limits, the number of Cloud Routers is independent of the type of Cloud VPN gateway, Classic VPN or HA VPN, that a tunnel is attached to. The quota is applied the same to either type of gateway.
|Target VPN gateways||Quota||For Classic VPN only|
|Forwarding rules||Quota||For Classic VPN only|
The following limits apply to Cloud VPN. In this table, VPN tunnel means either a Classic VPN tunnel or an HA VPN tunnel. Unless otherwise stated, these limits cannot be increased.
|Bandwidth per VPN tunnel||Up to 3 Gbps for the sum of ingress and egress||
This maximum bandwidth can only be achieved by using an MTU size of 1,460 bytes and a packet rate of 250,000 packets per second (pps).
Cloud VPN only throttles egress IPsec traffic. It does not throttle ingress traffic.
For more details, see Network bandwidth.
Be aware of the following issues:
Google Cloud resources specific to HA VPN are not yet displayed in Cloud Asset Inventory or Security Command Center. These resources include
compute.externalVpnGateways. However, the
compute.vpnTunnelsresource is listed in both locations and is required for a working HA VPN connection.
To view Cloud Monitoring metrics for HA VPN, use Metrics Explorer. For more information, see Viewing logs and metrics.
When setting up VPN tunnels to AWS, use IKEv2 and configure fewer IKE transform sets.
This table highlights important quotas for each project. For other quotas, see the Cloud Console Quotas page.
The number of Interconnect connections per project.
Interconnect connections are not associated with regions or VPC networks.
|Interconnect connection bandwidth per project||Calculated automatically||
The total Interconnect connection bandwidth for the project, calculated by adding up the bandwidths of each connection it contains.
The bandwidth of each connection is calculated by multiplying the capacities of its circuits (either 10 Gbps or 100 Gbps) by the number of circuits in the connection.
For example, an Interconnect connection consisting of four 10-Gbps circuits has 40 Gbps of bandwidth. If you have two such connections in your project, this quota is automatically set to 80 Gbps.
The number of VLAN attachments that you can configure in each region for your project.
Regardless of this quota, you are also limited to a total of 16 VLAN attachments per Interconnect connection. If you require additional attachments per connection, see the Maximum number of VLAN attachments that can be associated with a single Interconnect connection in the Limits table.
|VLAN attachments total Mbps||Quota||
The maximum bandwidth capacity of all VLAN attachments in a given region for a given project, irrespective of their relationship with Interconnect connections.
In addition to this quota, the limits described in the Limits table apply.
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.
For more details, see Cloud Router quotas and limits.
The following limits apply to Interconnect connections and VLAN attachments. Unless otherwise stated, these limits cannot be increased.
|Maximum number of physical circuits per Interconnect connection||8 x 10 Gbps (80-Gbps) circuits or
2 x 100 Gbps (200-Gbps) circuits
An Interconnect connection is a logical connection to Google, made up of one or more physical circuits. You can request one of the following circuit choices:
|Maximum number of VLAN attachments that can be associated with a single Interconnect connection||16||Each Interconnect connection supports no more than 16 VLAN attachments, even if you would otherwise have quota to create more VLAN attachments.|
|Maximum bandwidth per VLAN attachment||Capacities from 50 Mbps to 50 Gbps||
The maximum possible bandwidth per VLAN attachment depends on the bandwidth capacity that you order. For capacities, see the Pricing page. For Partner Interconnect, not all service providers offer all capacities.
The throughput of individual flows on a VLAN attachment is limited. To achieve maximum throughput, you must use multiple five-tuple flows (for example: 10+) with packet sizes within the MTU of the VLAN attachment.
|Maximum total packet rate per VLAN attachment||
This rate varies according to the attachment's capacity:
|The maximum packet rate for the entire VLAN attachment.|
|Maximum bandwidth per traffic flow on a VLAN attachment||
Even if you configure your attachment higher than 3 Gbps, your per-flow capacity is capped at 3 Gbps.
A traffic flow is identified by either a five-tuple hash for non-fragmented packets or a three-tuple hash for fragmented packets:
The following cases describe where the maximum bandwidth is lower than 3 Gbps:
|Maximum packet rate per traffic flow on a VLAN attachment||250,000 packets per second||The maximum rate of packets per traffic flow, identified by a five-tuple hash for non-fragmented packets and by a three-tuple hash for fragmented packets (as described in the previous section).|
|Maximum transmission unit (MTU)||1440 or 1500 bytes||Depending on the VLAN attachment MTU setting, the size of the largest IP address packet that can be transmitted over a VLAN attachment. For more information, see the Cloud Interconnect MTU section.|
|Maximum lifetime of (Partner Interconnect) VLAN attachment pairing key||28 days||
The maximum amount of time that can pass between generating a (Partner Interconnect) VLAN attachment pairing key and successful attachment provisioning by the service provider.
If a pairing key is no longer valid, you delete and create a new pairing key for the Partner Interconnect service provider to use.
|Cloud Router limits||
Because Dedicated Interconnect and Partner Interconnect require Cloud Router, all the Cloud Router quotas and limits apply.
There are limits on the maximum number of learned custom dynamic routes and on the number of advertised routes. For more information, see the Cloud Router Quotas and limits page.
This table covers important quotas per project. For other quotas, see the Cloud Console Quotas page.
|Cloud Routers per project||Quota||Regardless of quota, each network is limited to five Cloud Routers per region. See Limits.|
The following limits for Cloud Router apply to Virtual Private Cloud (VPC) networks. Unless otherwise stated, these limits cannot be increased.
|Maximum number of Cloud Routers per combination of VPC network and region||5||If you have sufficient project quota, you can create up to five Cloud Routers in a given VPC network and region.|
|Maximum number of BGP peers for each Cloud Router in a given VPC network and region||128||The BGP peer can be a Cloud VPN tunnel using dynamic routing or a VLAN attachment for Dedicated Interconnect or Partner Interconnect.|
|For a given Cloud Router, maximum number of subnet route advertisements per BGP session||No restriction||Cloud Routers do not have a limit for the number of subnet routes they can advertise. The number of subnet routes are determined by the number of subnets, which are controlled by VPC network quotas and limits.|
|For a given Cloud Router, maximum number of custom route advertisements per BGP session||200||If the custom route advertisements are identical for all BGP sessions on a Cloud Router, this limit represents the total number of unique custom route advertisements for the Cloud Router. In this case, each session receives the same set of custom route advertisements.|
|Maximum number of unique destinations for learned routes that can be applied to subnets in a given region by all Cloud Routers in the same region||100||
For both limits on the maximum number of unique destinations for learned routes:
Routes are grouped by unique destinations. Routes with identical destinations but different next hops only count as a single destination. Routes with identical destinations and identical next hops also only count as a single destination.
For networks in global dynamic routing mode, it is possible to reach one of the maximum number of unique destination limits without reaching the other. When either of the limits has been reached, you can experience intermittent connectivity issues when the routes are dropped. For details, see the learned route example.
For more information about these limits, including metrics that you can use to understand your current limits and usage, see Check quotas and limits in Troubleshooting.
If you need to increase either of these limits, contact your Google Cloud sales team.
Only applicable to VPC networks in global dynamic routing mode:
Maximum number of unique destinations for learned routes that can be applied to subnets in a given region by Cloud Routers from different regions
Learned route example
The following examples illustrate the route dropping behavior that you can encounter when the regional or global limit is exceeded.
Suppose you have Cloud Routers in the
us-east1 region and
Cloud Routers in the
us-west1 region in the same VPC network, and
global dynamic routing is enabled. The Cloud Routers in each region
learn a set of routes for 100 unique destinations. For the purpose of this
example, the Cloud Routers in each region don’t learn any of the same
Regardless of which Cloud Routers learn the routes within each region, each region’s regional limit is exhausted because 100 of 100 unique destinations are learned by the Cloud Routers in each region. The global limits for both regions are exhausted because the Cloud Routers in each region import 100 unique destinations from the Cloud Routers in the other region. If the example VPC network used regional dynamic routing, the global limits in each region would not apply because the regional dynamic routing mode does not propagate learned custom dynamic routes from one region to another.
Exceeding a region’s regional limit
Suppose your on-premises router that's connected to a Cloud Router in
us-west1 advertises a new route with a 101 destination. Cloud Routers in
us-west1 region pick the routes for 100 of the 101 unique destinations
following a deterministic order. The routes that use these selected (100 unique)
destinations are made available to resources in the
us-west1 region. Those
same routes are made available to other regions, subject to each other region’s
Exceeding a region’s global limit
When 101 unique destinations are learned by Cloud Routers in the
us-west1 region, routes for 100 of those 101 unique destinations from
are made available to resources in the
us-east1 region, because the
region’s global limit can only accept 100 unique destinations.
Suppose that you create a Cloud Router in a third region,
the same VPC network. Suppose that the new Cloud Router learns 10 unique
destinations from its BGP peer. Although the
us-central1 region’s regional
destination limit has not been exceeded, the
us-central1 region’s global
unique destination limit has been exceeded because a total of 200 unique
destinations are provided by the other two regions (100 from
us-east1 and a
different 100 from
us-west1). In each region, the deterministic route order
selects routes for no more than 100 unique destinations from other regions, as
indicated in the following table.
Unique destinations local to the region
(usage of region’s regional limit)
Unique destinations from other regions
(usage of region’s global limit)
|us-west1||101 received. 100 of the 101 are considered according to the deterministic route dropping. Only the 100 selected prefixes are advertised to remote regions.||
110 received (100 from
|us-east1||100 received. All 100 are considered and advertised to remote regions.||
110 received (100 from
|us-central1||10 received. All 10 are considered.||
200 received (100 from
us-central1 region’s global limit is exceeded, its regional quota can accept routes whose next hops are in the
Deterministic route dropping behavior
Cloud Router implements a deterministic route dropping behavior so that, as long as the same prefixes are received in each region, a consistent set of routes are made available to resources within that region. This consistency is preserved when Cloud Router tasks restart. If a limit is exceeded, Cloud Router drops prefixes according to a predictable algorithm regardless of when the routes were learned or the MED values of these routes. A new route can cause a previously learned route to be dropped by the algorithm.
As shown in exceeding a region’s global limit, the deterministic dropping behavior is applied independently to each region’s regional limit and each region’s global limit. The set of 100 unique prefixes that are not dropped in each region due to reaching each region’s global limit (the last column) is not guaranteed to be the same.
Avoiding route dropping
During route dropping, you lose connectivity for the prefixes that are dropped. To avoid route dropping, monitor each region’s regional and global prefix usage by using Cloud Monitoring or Cloud Logging, and make sure not to advertise more unique destinations than each limit.
Consider aggregating prefixes (for example, by aggregating prefixes into a prefix of smaller length) to reduce the number of unique destinations. If aggregating prefixes isn’t possible, contact your Google Cloud Sales team to discuss alternative options.
Quotas that apply to network routes for Cloud Router also apply to routes for Router appliance spokes attached to Network Connectivity Center hubs.
For more information, see Cloud Router quotas.
In addition to the Network Connectivity Center limits, the following limits apply to Router appliance:
If your deployment includes more than 1,000 VMs, you might be unable to establish BGP sessions between the router appliance instance and the Cloud Router. This 1,000-VM limit includes any VMs that are accessible through VPC Network Peering.
The following limits for Cloud Router also apply to Router appliance:
- The maximum number of Cloud Routers per combination of VPC network and region
- The maximum number of BGP peers for each Cloud Router in a given VPC network and region
For more information, see Cloud Router limits.
Network Connectivity Center
Quotas that apply to network routes for Cloud Router also apply to routes for Network Connectivity Center hubs and spokes. For more information, see Cloud Router Quotas.
|Number of VPN tunnel spokes||Quota||For HA VPN only and for each project in the specific region|
|Number of VLAN attachment spokes||Quota||For each project in the specific region|
|Number of Router appliance spokes||Quota||For each project in the specific region|
Network Connectivity Center enforces the following usage limits.
|Number of hubs that a project can have||1|
|Number of VPN tunnels that can be linked to a spoke||64|
|Number of VLAN attachments that can be linked to a spoke||6|
|Number of router appliance instances that can be attached to a spoke||128|
Google Cloud enforces quotas on resource usage for various 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.
To view quotas or request quota increases, Identity and Access Management (IAM) members need one of the following roles.
|Check quotas for a project||One of the following:|
|Modify quotas, request additional quota||One of the following:|
Checking your quota
- In the Cloud Console, go to the Quotas page.
- To search for the quota that you want to update, use the Filter table. If you don't know the name of the quota, use the links on this page instead.
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 the following command:
gcloud compute regions describe example-region
Errors when exceeding your quota
If you exceed a quota with a
gcloud outputs a
quota exceeded error
message and returns with the exit code
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
To increase or decrease most quotas, use the Google Cloud Console. Some quotas can't be increased above their default values.
For more information, see the following sections of Working with quotas:
- In the Cloud Console, go to the Quotas page.
- On the Quotas page, select the quotas that you want to change.
- At the top of the page, click Edit quotas.
- Fill out your name, email, and phone number, and then click Next.
- Fill in your quota request, and then click Done.
- Submit your request. Quota requests take 24 to 48 hours to process.
Each quota represents a maximum number for a particular type of resource that you can create, if that resource is available. It's important to note that quotas do not guarantee resource availability. Even if you have available quota, you can't create a new resource if it is not available.
For example, you might have sufficient quota to create a new regional, external IP address
us-central1 region. However, that is not possible if there are 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.