Quotas and limits

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.

Cloud VPN

Quotas

This table covers important quotas per project. See the Cloud Console Quotas page for other quotas.

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

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

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

Known issues

Be aware of the following issues:

Cloud Interconnect

Quotas

This table highlights important quotas for each project. See the Cloud Console Quotas page for other quotas.

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

Limits

The following limits apply to interconnects and interconnect attachments. Unless otherwise stated, these limits cannot be increased.

Item Limit Notes
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:
  • 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 interconnect attachments that use the interconnect to 80 Gbps.
    To determine the bandwidth, multiply the number of physical circuits by the bandwidth per circuit (10 Gbps).
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 Pricing page 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 capacity:
  • The maximum rate for a 50 Gbps interconnect attachment (VLAN) is 6.25M packets per second (pps).
  • The maximum rate for a 10 Gbps interconnect attachment (VLAN) is 1.25M packets per second (pps)
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.
  • 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 3 Gbps:
  • If the bandwidth capacity of your interconnect attachment itself is less than 3 Gbps, then the bandwidth per traffic flow is limited by the bandwidth of the interconnect attachment.
  • If you reach the maximum packet rate per traffic flow, described next.
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.

Cloud Router

Quotas

This table covers important quotas per project. See the Cloud Console Quotas page for other quotas.

Item Quota Notes
Cloud Interconnects per project Quota Regardless of quota, each network is limited to five Cloud Interconnects per region. See limits.

Limits

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

Item Limit Notes
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
100

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/24 is 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/24 and next hop in us-west1 cannot be made available to subnets in us-east1. Subnets in us-east1 would not have a path to 10.1.2.0/24.

  • 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.

Visão geral

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.

Permissões

Para visualizar as cotas ou solicitar aumentos para elas, os membros do IAM precisam ter um dos seguintes papéis.

Tarefa Papel obrigatório
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 serviceusage.quotas.update

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, o gcloud emitirá uma mensagem de erro quota exceeded e retornará com o código de saída 1.

Se você exceder uma cota com uma solicitação de API, o Google Cloud retornará o seguinte código de status HTTP: HTTP 413 Request Entity Too Large.

Como solicitar cota extra

Solicite cota extra na página Cotas em Cloud Console. As solicitações de cota demoram de 24 a 48 horas para serem processadas.

  1. Acesse a página Cotas.

    Acessar a página "Cotas"

  2. Na página Cotas, selecione as que você quer alterar.
  3. Clique no botão Editar cotas na parte superior da página.
  4. Preencha seu nome, e-mail e número de telefone e clique em Avançar.
  5. Preencha o pedido de cota e clique em Avançar.
  6. 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.