This page describe quotas and limits for Network Connectivity products. To change a quota, request additional quota by using the Google Cloud Console. Limits cannot generally be increased unless specifically noted.
This table covers important quotas per project. See the Cloud Console Quotas page for other quotas.
|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 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
Subject to the Cloud Router quotas and limits, the number of Cloud Routers is entirely independent of the type of Cloud VPN gateway, Classic VPN or HA VPN, that a tunnel is attached to, although 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 a
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.
Refer to Network bandwidth for more details.
Be aware of the following issues:
Google Cloud resources specific to HA VPN are not yet displayed in Cloud Asset Inventory or Cloud Security Command Center. These resources include
compute.externalVpnGateways. But note that 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, you must use Metrics Explorer. See Viewing logs and metrics.
When setting up VPN tunnels to AWS, using IKEv2 and configuring fewer IKE transform sets is required.
This table highlights important quotas for each project. See the Cloud Console Quotas page for other quotas.
|Interconnects||Quota||This is the number of interconnects per project. Interconnects are not associated with regions or VPC networks.|
|Interconnect bandwidth per project||Calculated automatically||This quota represents the total interconnect bandwidth for the project,
calculated by adding up the bandwidths of each interconnect it contains.
The bandwidth of each interconnect is calculated by multiplying the capacities of its circuits (either 10 Gbps or 100Gbps) by the number of circuits in the interconnect. For example, an interconnect consisting of four 10 Gbps circuits has 40 Gbps of bandwidth. If you have two such interconnects in your project, this quota is automatically set to 80 Gbps.
|Interconnect attachments||Quota||This quota represents the number of interconnect attachments (VLANs) that you can configure in each region for your project. Regardless of this quota, you are also limited to a total of 16 interconnect attachments per interconnect. If you require additional attachments per interconnect, refer to Maximum number of interconnect attachments (VLANs) that can be associated with a single interconnect in limits, below.|
|Interconnect attachments total Mbps||Quota||This quota represents the maximum bandwidth capacity of all interconnect attachments in a given region for a given project, irrespective of their relationship with interconnects. In addition to this quota, the limits described in the next table apply.|
|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.|
The following limits apply to interconnects and interconnect attachments. Unless otherwise stated, these limits cannot be increased.
|Maximum number of physical circuits per interconnect||8 x 10 Gbps (80 Gbps) circuits or
2 x 100 Gbps (200 Gbps) circuits
|An interconnect 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||16||Each interconnect supports no more than 16 interconnect attachments (VLANs), even if you would otherwise have quota to create more interconnect attachments.|
|Maximum bandwidth per interconnect attachment||Capacities from 50 Mbps to 50 Gbps||The maximum possible bandwidth per interconnect attachment depends
on the bandwidth capacity you order. See the
for capacities. For Partner Interconnect, not all
partners offer all capacities.
The throughput of individual flows on an interconnect attachment is limited, as described below. To achieve maximum throughput, you must use multiple five-tuple flows (for example: 10+) with packet sizes within the MTU of the interconnect attachment.
|Maximum total packet rate per VLAN attachment||This rate varies according to the attachment's
||This represents the maximum packet rate for the entire VLAN attachment.|
|Maximum bandwidth per traffic flow on an interconnect attachment||3 Gbps. Even if you configure your attachment above 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.
|Maximum packet rate per traffic flow on an interconnect attachment||250,000 packets per second||This number represents the maximum rate of packets per traffic flow, as 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||1440 bytes||The size of the largest IP packet that can be transmitted over an interconnect attachment.|
|Maximum lifetime of (Partner) interconnect attachment pairing key||28 days||The maximum amount of time that can pass between generating a (partner) interconnect attachment pairing key and successful attachment provisioning by the partner. If a pairing key is no longer valid, you just delete and recreate a new pairing key for the partner interconnect provider to use.|
|Cloud Router limits||Because Dedicated Interconnect and Partner Interconnect require Cloud Router, all of 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. Carefully review the Cloud Router Quotas and limits page for more information.|
This table covers important quotas per project. See the Cloud Console Quotas page for other quotas.
|Cloud Interconnects per project||Quota||Regardless of quota, each network is limited to five Cloud Interconnects per region. See limits.|
The following limits for Cloud Interconnect apply to Virtual Private Cloud (VPC) networks. Unless otherwise stated, these limits cannot be increased.
|Maximum number of Cloud Interconnects per combination of VPC network and region||5||If you have sufficient project quota, you can create up to five Cloud Interconnects in a given VPC network and region.|
|Maximum number of BGP peers for each Cloud Interconnect in a given VPC network and region||128||The BGP peer can be a Cloud VPN tunnel using dynamic routing or an interconnect attachment (VLAN) for Dedicated Interconnect or Partner Interconnect.|
|For a given Cloud Interconnect, maximum number of subnet route advertisements per BGP session||No restriction||Cloud Interconnects do not have a limit for the number of subnet routes they can advertise. The number of subnet routes are determined by the number subnets, which are controlled by VPC network quotas and limits.|
|For a given Cloud Interconnect, maximum number of custom route advertisements per BGP session||200||If the custom route advertisements are identical for all BGP sessions on a Cloud Interconnect, this limit represents the total number of unique custom route advertisements for the Cloud Interconnect. 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 Interconnects 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 destinations for learned routes limits without reaching the other. When only one limit has been reached, you can experience unpredictable routing behavior. See the learned route example for details.
Contact your Google Cloud sales team if you need to increase either of these limits on the maximum number of learned routes.
|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 Interconnects from different regions
Learned route example
The following example illustrates unpredictable behavior you can encounter when only one of the limits for maximum number of learned routes is reached.
Suppose you have a Cloud Interconnect in the us-east1 region and another in the us-west1 region. Both Cloud Interconnects learn the same set of routes for 100 unique destinations (to your on-premises network). The next hops for these routes are specific to each Cloud Interconnect because each one connects to a different router at your on-premises network. If your on-premises router connected to the Cloud Interconnect in us-west1 shares a 101st route with a new, unique destination:
The Cloud Interconnect would pick any 100 of the 101 shared routes. Simultaneously, the limit for the number of unique destinations learned by Cloud Interconnects in different regions would be reached in us-east1, so a set of any 100 of those 101 routes would be applied to subnets in us-east1. There is no guarantee that the same 100 routes would be applied in both regions.
VMs in one region can experience loss of other routes. Suppose a route with destination
10.1.2.0/24is shared from on-premises to Cloud Interconnects in both regions. If us-east1 has reached the maximum number of unique destinations for learned routes, the other route with destination
10.1.2.0/24and next hop in us-west1 cannot be made available to subnets in us-east1. Subnets in us-east1 would not have a path to
More generally, if a Cloud Interconnect in a given region and Cloud Interconnects in different regions both learn routes with the same destination (but different next hops), reaching the maximum number of unique destinations for learned routes in the given region causes Google Cloud to ignore routes with that destination whose next hops are on Cloud Interconnects in the other regions.
Google Cloud impõe cotas sobre o uso de recursos por diversos motivos. Por exemplo, as cotas protegem a comunidade de usuários Google Cloud, impedindo picos de uso inesperados. As cotas também ajudam os usuários que estão explorando o Google Cloud com o nível gratuito a permanecer na avaliação.
Todos os projetos começam com as mesmas cotas, que podem ser alteradas com uma solicitação de cota extra. Algumas cotas podem aumentar automaticamente dependendo do uso de um produto.
Para visualizar as cotas ou solicitar aumentos para elas, os membros do IAM precisam ter um dos seguintes papéis.
|Verificar cotas para um projeto||Proprietário ou editor do projeto ou visualizador de cotas|
|Modificar cotas, solicitar cota extra||Proprietário ou editor do projeto, administrador de cotas ou um papel personalizado com a permissão
Como verificar a cota
Em Cloud Console, acesse a página Cotas.
Usando a ferramenta de linha de comando
gcloud, execute o comando a seguir para verificar suas cotas. Substitua
[PROJECT_ID] pelo ID do seu projeto.
gcloud compute project-info describe --project [PROJECT_ID]
Para verificar a cota usada em uma região, execute:
gcloud compute regions describe example-region
Erros ao exceder a cota
Se você exceder uma cota com um comando
gcloud emitirá uma mensagem de erro
quota exceeded e retornará com o código de saída
Solicite cota extra na página Cotas em Cloud Console. As solicitações de cota demoram de 24 a 48 horas para serem processadas.
- Acesse a página Cotas.
- Na página Cotas, selecione as que você quer alterar.
- Clique no botão Editar cotas na parte superior da página.
- Preencha seu nome, e-mail e número de telefone e clique em Avançar.
- Preencha o pedido de cota e clique em Avançar.
- Envie a solicitação.
Disponibilidade de recursos
Cada cota representa um número máximo para um tipo específico de recurso que é possível criar, desde que o recurso esteja disponível. É importante observar que as cotas não garantem a disponibilidade de recursos. Mesmo que você tenha cota disponível, não será possível criar um novo recurso se ele não estiver disponível. Por exemplo, você pode ter cota suficiente para criar um novo endereço IP externo regional na região
us-central1, mas isso não será possível se não houver endereços IP externos disponíveis naquela região. A disponibilidade de recursos zonais também pode afetar a possibilidade de criar um novo recurso.
São raras as situações em que os recursos não estão disponíveis em uma região inteira, mas os recursos dentro de uma região podem se esgotar periodicamente, na maioria das vezes sem impactar o SLA para o tipo de recurso. Para ver mais informações, leia o contrato de nível de serviço (SLA) referente ao recurso.