Quotas and limits

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.

Cloud VPN

Quotas

This table covers important quotas per project. For other quotas, see the Google Cloud console Quotas page.

Item	Quota	Notes
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.
Routers	Quota	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

Limits

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.

Item	Limit	Notes
Bandwidth per VPN tunnel	250,000 packets per second for the sum of ingress and egress	250,000 packets per second is roughly equivalent to 1 Gbps to 3 Gbps, depending on the average packet size within the tunnel. Cloud VPN only throttles egress IPsec traffic. It does not throttle ingress traffic. For more details, see Network bandwidth.

Item

Limit

Notes

Bandwidth per VPN tunnel

250,000 packets per second for the sum of ingress and egress

250,000 packets per second is roughly equivalent to 1 Gbps to 3 Gbps, depending on the average packet size within the tunnel.

Cloud VPN only throttles egress IPsec traffic. It does not throttle ingress traffic.

For more details, see Network bandwidth.

Known issues

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.vpnGateways and compute.externalVpnGateways. However, the compute.vpnTunnels resource 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.

Cloud Interconnect

Quotas

This table highlights important quotas for each project. For other quotas, see the Google Cloud console Quotas page.

Item	Quota	Notes
Interconnect connections	Quota	The number of Dedicated Interconnect connections per project. Interconnect connections are not associated with regions or VPC networks.
VLAN attachments	Quota	The number of VLAN attachments that you can configure in each region for your project. This includes VLAN attachments for both Dedicated Interconnect and Partner Interconnect. In addition to this quota, the VLAN attachments per Interconnect applies.
VLAN attachments per Interconnect	Quota	The number of VLAN attachments that you can configure on a single interconnect connection.
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.
Cloud Routers	Quota	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.

Limits

The following limits apply to Interconnect connections and VLAN attachments. Unless otherwise stated, these limits cannot be increased.

Item	Limit	Notes
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: Up to 2 x 100 Gbps (200-Gbps) circuits. 10-Gbps increments up to eight circuits (80 Gbps) to increase the maximum total bandwidth of all VLAN attachments that use the Interconnect connection to 80 Gbps. To determine the bandwidth, multiply the number of physical circuits by the bandwidth per circuit (10 Gbps).
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	Dataplane v1: This rate varies according to the attachment's capacity: The maximum rate for a 50-Gbps VLAN attachment is 6.25 M packets per second (pps). The maximum rate for a 10-Gbps VLAN attachment is 1.25 M packets per second (pps).	The maximum packet rate for the entire VLAN attachment.
Maximum bandwidth per traffic flow on a VLAN attachment	Dataplane v2: 10 Gbps Dataplane v1: 3 Gbps Even if you configure your attachment with a higher bandwidth, an individual traffic flow might be limited to the maximum defined for the Dataplane version.	A traffic flow to a destination in a VPC network is identified by either a five-tuple hash for non-fragmented packets or a three-tuple hash for fragmented packets. In addition, traffic flows that use Private Google Access for on-premises hosts are identified by a three-tuple hash. A five-tuple hash consists of a protocol, source IP address, source port, destination IP address, and destination port. A three-tuple hash consists of a protocol, source IP address, and destination IP address. The following cases describe where the maximum bandwidth is lower than the 3 Gbps or 10 Gbps limit: If the bandwidth capacity of your VLAN attachment is less than the maximum for its Dataplane version (3 Gbps or 10 Gbps), the bandwidth per traffic flow is limited by the bandwidth of the VLAN attachment. If you reach the maximum packet rate per traffic flow (as described in the next section).
Maximum packet rate per traffic flow on a VLAN attachment	Dataplane v2: 10,000,000 packets per second (pps) Dataplane v1: 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)	1,440 bytes 1,460 bytes 1,500 bytes 8,896 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 routes and on the number of advertised routes. For more information, see the Cloud Router Quotas and limits page.

Cloud Router

Quotas

This table covers important quotas per project. For other quotas, see the Google Cloud console Quotas & System Limits page.

Item	Quota	Notes
Cloud Routers per project	Quota	Regardless of quota, each network is limited to five Cloud Routers per region. See Limits.
Unique Cloud Router dynamic route prefixes from own region per region per VPC network The maximum number of assured unique destination prefixes for learned routes to be applied to subnets in a given region by all Cloud Routers in the same region. This is referred to as a region's from-own-region quota.	Quota	Both IPv4 and IPv6 prefixes count toward this quota. All learned routes count toward this quota, including custom learned routes and BGP-received 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 unique dynamic route prefix quotas without reaching the other. If either of the quotas has been exceeded, you may experience intermittent connectivity issues when routes are dropped./ For details, see the learned route example. For more information about these quotas, including metrics that you can use to understand your current usage, see Troubleshoot BGP routes and route selection.
Only applicable to VPC networks in global dynamic routing mode. Unique Cloud Router dynamic route prefixes from other regions per region per VPC network The maximum number of assured unique destinations for learned routes that can be applied to subnets in a given region by Cloud Routers from different regions. This is referred to as a region's from-other-regions quota.	Quota	Both IPv4 and IPv6 prefixes count toward this quota. All learned routes count toward this quota, including custom learned routes and BGP-received 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 unique dynamic route prefix quotas without reaching the other. If either of the quotas has been reached, you might experience intermittent connectivity issues when routes are dropped. For details, see the learned route example. For more information about these quotas, including metrics that you can use to understand your current usage, see Troubleshoot BGP routes and route selection.

Item

Quota

Notes

Cloud Routers per project

Quota

Regardless of quota, each network is limited to five Cloud Routers per region. See Limits.

Unique Cloud Router dynamic route prefixes from own region per region per VPC network

The maximum number of assured unique destination prefixes for learned routes to be applied to subnets in a given region by all Cloud Routers in the same region. This is referred to as a region's from-own-region quota.

Quota

Both IPv4 and IPv6 prefixes count toward this quota.

All learned routes count toward this quota, including custom learned routes and BGP-received 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 unique dynamic route prefix quotas without reaching the other. If either of the quotas has been exceeded, you may experience intermittent connectivity issues when routes are dropped./ For details, see the learned route example.

For more information about these quotas, including metrics that you can use to understand your current usage, see Troubleshoot BGP routes and route selection.

Only applicable to VPC networks in global dynamic routing mode.

Unique Cloud Router dynamic route prefixes from other regions per region per VPC network

The maximum number of assured unique destinations for learned routes that can be applied to subnets in a given region by Cloud Routers from different regions. This is referred to as a region's from-other-regions quota.

Quota

Both IPv4 and IPv6 prefixes count toward this quota.

All learned routes count toward this quota, including custom learned routes and BGP-received routes.

For networks in global dynamic routing mode, it is possible to reach one of the unique dynamic route prefix quotas without reaching the other. If either of the quotas has been reached, you might experience intermittent connectivity issues when routes are dropped. For details, see the learned route example.

For more information about these quotas, including metrics that you can use to understand your current usage, see Troubleshoot BGP routes and route selection.

Limits

The following limits for Cloud Router apply to Virtual Private Cloud (VPC) networks. Unless otherwise stated, these limits cannot be increased.

Item	Limit	Notes
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 any of the following: A Cloud VPN tunnel using dynamic routing A VLAN attachment for any of the following: Dedicated Interconnect Partner Interconnect Cross-Cloud Interconnect A Router appliance within Network Connectivity Center
Maximum number of prefixes that Cloud Router accepts from a single BGP peer	5,000	If a BGP peer advertises more than 5,000 prefixes, Cloud Router resets the BGP session.
Maximum number of terms of all applied BGP route policies within a single BGP peer or direction	1,000	This limit isn't split across resources, but combined. There isn't a limit on the size of a single match or action expression, number of actions in a term, number of terms in a single policy, or the number of policies.
For a given Cloud Router, the 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, the maximum number of custom advertised routes per BGP session	200	If the custom advertised routes are identical for all BGP sessions on a Cloud Router, this limit represents the total number of unique IPv4 and IPv6 custom advertised routes for the Cloud Router. In this case, each session receives the same set of custom advertised routes.
For a given Cloud Router, the combined maximum size of all match and action expression literals used in BGP route policies when encoded as UTF-8.	250 KiB limit	For a given Cloud Router, this limit isn't split across resources, but combined. There isn't a limit on the size of a single match or action expression, number of actions in a term, number of terms in a single BGP route policy, or the number of BGP route policies.
Maximum queries per minute for `list-bgp-routes` calls on a single Cloud Router	1500	This quota is from `compute.googleapis.com/list_requests_per_region`. For more information, see Rate quotas.
Maximum number of BGP route policies per Cloud Router.	500
For a given BGP session, the maximum number of custom learned routes	10	For more information about this feature, see Custom learned routes.
For a given region in a VPC network, the maximum number of unique IP prefixes that can be configured as custom learned routes; this limit allows for the same ranges to be used on multiple peers	10	For more information about this feature, see Custom learned routes.

Learned route example

The following examples illustrate the route dropping behavior that you can encounter when the from-own-region quota or the from-other-regions quota 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. Each Cloud Router in each region learns 250 unique destinations. For illustrative purposes of this example, each Cloud Router in each region doesn't learn any of the same destinations.

Regardless of which Cloud Routers learn the routes within each region, each region's from-own-region quota is exhausted because 250 of 250 unique destinations are learned by the Cloud Routers in each region. The from-other-regions quotas for both regions are also exhausted because each Cloud Router imports 250 unique destinations from the other region. If the example VPC network used regional dynamic routing, the from-other-regions quotas in each region doesn't apply because regional dynamic routing mode instructs the VPC network to only create dynamic routes in the region that matches the route's next hop.

Exceeding a region's from-own-region quota

Suppose your on-premises router that's connected to a Cloud Router in us-west1 advertises a 251st destination. Cloud Routers in the us-west1 region pick 250 of the 251 unique destinations following a deterministic route order. These routers send those 250 unique destinations to the VPC network, creating 250 dynamic routes in the us-west1 region.

Because the VPC network uses global dynamic routing mode, it also creates no more than 250 dynamic routes in every other region, subject to each other region's from-other-regions unique destination quota. The next section describes what happens in other regions in more detail.

Exceeding a region's from-other-regions quota

When 251 unique destinations are learned by Cloud Routers in the us-west1 region, 250 of the 251 unique destinations from us-west1 are made available to resources in the us-east1 region because the us-east1 region's from-other-regions quota can only accept 250 unique destinations.

Suppose that you create a Cloud Router in a third region, us-central1, in the same VPC network. Suppose that the new Cloud Router learns 10 unique destinations from its BGP peer. Although the us-central1 region's from-own-region quota has not been exceeded, the us-central1 region's from-other-regions quota has been exceeded because a total of 500 unique destinations are provided by the other two regions (250 from us-east1 and a different 250 from us-west1).

On a region-by-region basis, the deterministic route order selects routes for no more than 250 unique destinations in other regions, as indicated in the following table.

Region Unique destinations local to the region
(usage of region's from-own-region quota) Unique destinations from other regions
(usage of region's from-other-regions quota)

Region	Unique destinations local to the region (usage of region's from-own-region quota)	Unique destinations from other regions (usage of region's from-other-regions quota)
us-west1	251 received. 250 of the 251 are selected, and one of the 251 is dropped by the deterministic route order. 250 dynamic routes with next hops in `us-west1` are created in `us-west1`. The 250 selected prefixes are shared with other regions.	260 received (250 from `us-east1`, 10 from `us-central1`). 250 of the 260 are selected, and 10 of the 260 are dropped by the deterministic route order. 250 dynamic routes with next hops outside of `us-west1` are created in `us-west1`.
us-east1	250 received. All 250 are selected by the deterministic route order. 250 dynamic routes with next hops in `us-east1` are created in `us-east1`. All 250 selected prefixes are shared with other regions.	260 received (250 from `us-west1`, 10 from `us-central1`). 250 of the 260 are selected, and 10 of the 260 are dropped by the deterministic route order. 250 dynamic routes with next hops outside of `us-east1` are created in `us-east1`.
us-central1	10 received. All 10 are selected by the deterministic route order. 10 dynamic routes with next hops in `us-central1` are created in `us-central1`. All 10 selected prefixes are shared with other regions.	500 received (250 from `us-west1`, 250 from `us-east1`). 250 of the 500 are selected, and 250 of the 500 are dropped by the deterministic route order. 250 dynamic routes with next hops outside of `us-central1` are created in `us-central1`.

us-west1

251 received. 250 of the 251 are selected, and one of the 251 is dropped by the deterministic route order. 250 dynamic routes with next hops in us-west1 are created in us-west1.

The 250 selected prefixes are shared with other regions.

260 received (250 from us-east1, 10 from us-central1). 250 of the 260 are selected, and 10 of the 260 are dropped by the deterministic route order.

250 dynamic routes with next hops outside of us-west1 are created in us-west1.

us-east1

250 received. All 250 are selected by the deterministic route order. 250 dynamic routes with next hops in us-east1 are created in us-east1.

All 250 selected prefixes are shared with other regions.

260 received (250 from us-west1, 10 from us-central1). 250 of the 260 are selected, and 10 of the 260 are dropped by the deterministic route order.

250 dynamic routes with next hops outside of us-east1 are created in us-east1.

us-central1

10 received. All 10 are selected by the deterministic route order. 10 dynamic routes with next hops in us-central1 are created in us-central1.

All 10 selected prefixes are shared with other regions.

500 received (250 from us-west1, 250 from us-east1). 250 of the 500 are selected, and 250 of the 500 are dropped by the deterministic route order.

250 dynamic routes with next hops outside of us-central1 are created in us-central1.

Although the us-central1 region's from-other-regions quota is exceeded, its from-own-region quota can accept destinations whose next hops are in the us-central1 region.

Deterministic route dropping behavior

Cloud Router implements a deterministic route dropping behavior based on the subnet mask length and lexicographic characteristics of each prefix received. Within each region, the following process applies independently to the region's from-own-region destinations list and the region's from-other-regions unique destinations list:

The list is sorted first from shortest to longest subnet mask length, then lexicographically. For example, 10.0.0.0/8 comes before 10.2.1.0/24, which comes before 10.99.1.0/24.
The first 250 entries in the list are preserved. All others are discarded.

As shown in exceeding a region's from-other-regions quota, the deterministic dropping behavior is applied independently to each region's from-own-region quota and each region's from-other-regions quota.

The deterministic route dropping behavior has the following consequences:

When IPv4 and IPv6 prefixes are both received, Cloud Router generally discards IPv6 prefixes first whenever a unique destination quota is exceeded. This happens because the most common shortest subnet mask length for IPv6 (/48) is longer than the longest possible subnet mask length for IPv4 (/32).
If the set of prefixes learned in each region remains constant, Google Cloud programs a consistent set of local dynamic routes in every region, subject to the dynamic routing mode of the VPC network. This consistency, including which routes are dropped by Cloud Router, is preserved when Cloud Router tasks restart.

Avoiding route dropping

During route dropping, you lose connectivity for the prefixes that are dropped. To avoid route dropping, monitor each region's from-own-region and from-other-regions prefix usage by using Cloud Monitoring or Cloud Logging, and make sure not to advertise more unique destinations than each quota.

Consider summarizing routes to reduce the number of unique destinations. For example, if you have the four subnets 10.10.10.0/24, 10.10.10.1/24, 10.10.10.2/24, and 10.10.10.3/24, then you can summarize them as one prefix, 10.10.0.0/22.

If summarization isn't possible, contact your Google Cloud Sales team to discuss alternative options.

Router appliance

Quotas

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.

Limits

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

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 and limits.

Item	Quota	Notes
Number of hubs per project	Quota	Per project, global
Number of Cloud VPN tunnel spokes per project per region	Quota	Per project in each region; only HA VPN tunnels are supported
Number of Cloud Interconnect VLAN attachment spokes per project per region	Quota	Per project in each region
Number of Router appliance spokes per project per region	Quota	Per project in each region
Number of VPC spokes per project	Quota	Includes VPC spokes (edge and center spokes combined) even if they are not connected to any hub.
Number of active VPC spokes per hub	Quota	Only applicable to VPC spokes that have been accepted into a hub; not applicable to VPC spokes that are pending review or that have been rejected.
Number of subnet routes per hub route table	Quota	Only applicable to hubs with VPC spokes

Limits

Network Connectivity Center enforces the following usage limits.

Item	Value
Number of VPN tunnels that can be linked to a spoke	8
Number of VLAN attachments that can be linked to a spoke	6
Number of router appliance instances that can be linked to a spoke	8
Number of active VPC spokes per hub	250
Maximum number of VPC spokes (active and inactive) per hub	1,000
Number of export filters per spoke	16
Maximum number of routing VPCs supported per Network Connectivity Center hub	40
Number of dynamic routes per hub route table	500

Manage quotas

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 might increase automatically based on your use of a product.

Permissions

To view quotas or request quota increases, Identity and Access Management (IAM) principals need one of the following roles.

Task	Required role
Check quotas for a project	One of the following: Project Owner (`roles/owner`) Project Editor (`roles/editor`) Quota Viewer (`roles/servicemanagement.quotaViewer`)
Modify quotas, request additional quota	One of the following: Project Owner (`roles/owner`) Project Editor (`roles/editor`) Quota Administrator (`roles/servicemanagement.quotaAdmin`) A custom role with the `serviceusage.quotas.update` permission

Check your quota

Console

In the Google Cloud console, go to the Quotas page.
Go to Quotas
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

Using the Google Cloud CLI, 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 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: 413 Request Entity Too Large.

Request additional quota

To adjust most quotas, use the Google Cloud console. For more information, see Request a quota adjustment.

Console

In the Google Cloud console, go to the Quotas page.
Go to Quotas
On the Quotas page, select the quotas that you want to change.
At the top of the page, click Edit quotas.
For Name, enter your name.
Optional: For Phone, enter a phone number.
Submit your request. Quota requests take 24 to 48 hours to process.

Resource availability

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 don't 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 in the 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.