VPC Networking and Firewalls

Google Compute Engine offers a configurable and flexible Virtual Private Cloud (VPC) networking system that enables you to permit connections between the outside world and your instances. You can manage your VPC network by configuring the network, firewall, and instance settings.

VPC networks

Your Cloud Platform Console project can contain multiple VPC networks. Each VPC network contains subnets, each with a defined IP range, and each capable of holding multiple instances and other resources. Instances and other resources draw their internal IP addresses from their subnet, making subnets the logical isolation partitions for the VPC network.

Every project is provided with a default VPC network with preset configurations and firewall rules. You can choose to customize the default VPC network by adding or removing rules, or you can create new networks in that project. Generally, most users only need one network, although you can have up to five networks per project by default.

Each instance can only belong to one network. All VPC networks use the IPv4 protocol. Compute Engine networks currently do not support IPv6. However, Google is a major advocate of IPv6 and it is an important future direction.


Each VPC network has its own firewall controlling access to the instances.

All traffic to instances, even from other instances, is blocked by the firewall unless firewall rules are created to allow it. The exception is the default VPC network that is created automatically with each project. This network has certain automatically created default firewall rules.

For all VPC networks except the automatically created default VPC network, you must create any firewall rules you need. To allow incoming network connections on a manually created VPC network, you need to set up firewall rules to permit these connections. Each firewall rule represents a single rule that determines what connections are permitted to enter or leave instances. It is possible to have many rules and to be as general or specific with these rules as you need. For example, you can create a firewall rule that allows all traffic through port 80 to all instances, or you can create a rule that only allows traffic from one specific IP or IP range to one specific instance.

Firewall rules are connection tracking, and therefore only regulate the initial connection. Once a connection has been established with an instance, traffic is permitted in both directions over that connection.

Blocked traffic

Compute Engine blocks or restricts traffic through all of the following ports/protocols between the Internet and virtual machines, and between two virtual machines when traffic is addressed to their external IP addresses through these ports (this also includes load-balanced addresses).

  • All outgoing traffic to port 25 (SMTP) is blocked.
  • Most outgoing traffic to port 465 or 587 (SMTP over SSL) is blocked, except for known Google IP addresses.
  • Traffic that uses a protocol other than TCP, UDP, and ICMP is blocked, unless explicitly allowed through Protocol Forwarding.

IP Addresses

If the instance has an external IP address, it can also send outgoing packets outside the VPC network. By default, gcloud compute instances create assigns an ephemeral external IP address to all new instances, unless otherwise specified. If you are using the API to create new instances, you can explicitly request an external IP address. All traffic through an external IP address, including traffic between instances in the same network, will be billed according to the price sheet.

Every instance also has an internal IP address that is unique to the VPC network. Within the VPC network, instances can also be addressed by instance name and the network will resolve an instance name into an internal IP address.

External load balancers also require an external IP address to be able to communicate with outside sources. Depending on the load balancer type, you might need a regional or global external IP address.

To learn more about IP addresses, read the IP Addresses documentation.


Every VPC network has a routes collection that contains all routes for that network. A route specifies how packets have a particular destination should be directed. For example, a route might specify that packets destined for a particular IP range should be handled by a gateway virtual machine instance that you configure and operate.

When you add a route to the routes collection, you can also specify which instances the route should apply to. By default, all routes apply to all instances in your network, but you can limit this by using instance tags. Applicable virtual machine instances in your project then pull from this centralized routes collection to create a read-only individual routes table. Compute Engine uses this routes table to direct outgoing packets for those instances.

A single route is made up of a route name, a destination range, a next-hop specification, any instance tags, and a priority value. By default, every network has routes that directs traffic to the Internet and that direct traffic to other instances within the VPC network.

Routes allow you to implement more advanced networking functions in your virtual machines, such as setting up one-to-many NAT and transparent proxies. If you do not need any advanced routing solutions, the default routes should be sufficient for handling most traffic.

For more information, see Routes.

Egress throughput caps

Outbound or egress traffic from a virtual machine is subject to maximum network egress throughput caps. These caps are dependent on the number of vCPUs that a virtual machine instance has. Each core is subject to a 2 Gbits/second (Gbps) cap for peak performance. Each additional core increases the network cap, up to a theoretical maximum of 16 Gbps for each virtual machine; however, the actual performance you experience can vary depending on your workload. All caps are meant as maximum possible performance, and not sustained performance. For example, a virtual machine instance with 4 vCPUs has a network throughput cap of 2 Gbps * 4 = 8 Gbps.

Specific workloads and benchmarks are regularly measured:

  • A single stream performance test can achieve 8.5 Gbps on average.
  • A multistream performance test can achieve 15 Gbps on average.

Instances that have 0.5 or fewer vCPUs, such as shared-core machine types, are treated as having 0.5 vCPUs and have a network throughput cap of 1 Gbit/sec.

Both persistent disk write I/O and network traffic count towards the instance's network cap. Depending on your needs, ensure your instance can support any desired persistent disk throughput for your applications. For more information, see the persistent disk specifications.

What's next

Send feedback about...

Compute Engine Documentation