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.
This table highlights important global quotas for each project. See the quotas page for other quotas.
|Networks||Quotas||This includes includes the
|Subnets||Quotas||Applies to all subnets in all networks in the project.|
custom static routes
|Quotas||This quota does not include custom dynamic routes learned by Cloud Router. See Cloud Router quotas for applicable quota and limit details for dynamic routes.|
|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 Routers per region in the next table, below.|
|Forwarding rules||Quotas||This quota includes all forwarding rules, regardless of their targets. Networks also have a limit on the total number of internal forwarding rules. See Internal forwarding rules per network in the next table, below.|
Shared VPC project limits
The following limits apply to projects that participate in Shared VPC.
|Number of service projects that can be attached to a host project||100||Contact your GCP sales team if you need to increase this limit.|
|Number of Shared VPC host projects||100||This limit cannot be increased.|
|Number of host projects to which a service project can attach||1||This limit cannot be increased.|
The following limits apply to VPC networks. Unless otherwise noted, these limits can be increased if you contact your GCP sales team.
|VM instances per network||15,000||The number of instances per network may be reduced you connect the network to others using VPC Network Peering. See Total VM instances among peered networks for details.|
|VM instances per subnet||No separate restriction.|
|Total VM instances among peered networks||15,500||This limit represents the total number of instances possible among all
networks in a VPC Network Peering relationship.
As clarifying examples, suppose network
• If network
• If network
|Total alias IP addresses||15,000||Each VPC network can have a maximum of 15,000 alias IP addresses, in total.|
|Secondary (alias) IP ranges per subnet||5||This limit cannot be increased.|
|Cloud Routers per region||5||This represents the maximum number of Cloud Routers per region within a given VPC network. This limit cannot be increased.|
|Internal forwarding rules per network||50||This represents the maximum number of internal forwarding rules that can be created within a given network.|
The following limits apply to VM instances. They cannot be changed. See Compute Engine quotas for quotas relevant to VMs.
|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 IP aliases 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.|
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.
To view quotas or request quota increases, IAM members need one of the following roles.
|Check quotas for a project||Project owner or editor or Quota Viewer|
|Modify quotas, request additional quota||Project
owner or editor,
or custom role with the
Checking your quota
In the GCP Console, go to the Quotas page.
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.
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.