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 virtual machine (VM) instances. You can manage your VPC network by configuring the network, firewall, and VM instance settings.

VPC networks

Your GCP 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 has a primary interface that connects to one network. The instance can optionally have multiple network interfaces, with each additional interface connecting to a different 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.

Firewalls

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). These ports are permanently blocked; they cannot be opened using firewall rules.

  • 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.
  • GRE traffic is blocked, even between VMs.
  • Traffic that uses a protocol other than TCP, UDP, ICMP, and IPIP is blocked, unless explicitly allowed through protocol forwarding.

For more information, see Firewall Rules.

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.

Routes

Every VPC network has a routes collection that contains all routes for that network. A route specifies how packets that 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.

Ingress and egress throughput caps

Ingress throughput caps

GCP does not artificially cap VM instance inbound or ingress traffic. VMs are allowed to receive as much traffic as resources and network conditions allow. For purposes of capacity planning, you should assume that each VM instance can handle no more than 10 Gbps of external Internet traffic. This value is an approximation, is not covered by an SLA, and is subject to change. Adding Alias IP addresses or multiple network interfaces to a VM does not increase its ingress capacity.

Egress throughput caps

Outbound or egress traffic from a VM instance is subject to maximum network egress throughput caps and is independent of other network conditions. Egress traffic includes any outbound network traffic to the following locations:

  • Over the external IP address of an instance to external networks even if those networks are in the same zone
  • Over the internal VPC network to other VM instances in the same zone
  • Data being written to persistent disk resources attached to the VM instance
  • Data sent to other Cloud Platform services over the internal VPC network

The egress throughput cap is dependent on the number of vCPUs that a virtual machine instance has. Each vCPU has a 2 Gbps egress cap for peak performance. Each additional vCPU increases the network cap, up to a theoretical maximum of 16 Gbps for each virtual machine. For example, a virtual machine instance with 4 vCPUs has an intra-zone network throughput cap of 2 Gbps * 4 = 8 Gbps. A virtual machine instance with 8 vCPUs has an intra-zone network throughput cap of 2 Gbps * 8 = 16 Gbps.

Specific workloads and benchmarks are regularly measured:

  • A single stream performance test can achieve a maximum of 8.5 Gbps on average.
  • A multistream performance test can achieve a maximum of 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

Was this page helpful? Let us know how we did:

Send feedback about...

Compute Engine Documentation