Google Compute Engine offers a configurable and flexible networking system that enables you to permit connections between the outside world and your instances. You can manage your Compute Engine network by configuring the network, firewall, and instance settings.
Your Cloud Platform Console project can contain
multiple networks, and each network can have multiple
instances attached to it. A network allows you to define a gateway IP and
the network range for the instances attached to that network. Every
project is provided with a
default network with preset configurations and
firewall rules. You can choose to customize the
default 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.
A network belongs to only one project, and each instance can only belong to one network. All Compute Engine networks use the IPv4 protocol. Compute Engine currently does not support IPv6. However, Google is a major advocate of IPv6 and it is an important future direction.
Each 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 network that is created automatically with each project. This network
has certain automatically created
For all networks except the automatically created
default network, you
must create any firewall rules you need. To allow
incoming network traffic on a manually created network, you need to set up
firewall rules to permit these connections. Each firewall rule represents
a single rule that determines what traffic
is permitted into the network. 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
you can create a rule that only allows traffic from one specific IP or IP range
to one specific instance.
Firewall rules only regulate incoming traffic to an instance. Once a connection has been established with an instance, traffic is permitted in both directions over that connection. To prevent an instance from sending outgoing packets, use another technology such as iptables.
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).
If the instance has an
external IP address,
it can also send outgoing packets outside the 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 addressable only within the network. Within the 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 Compute Engine project has a Routes collection that contains all routes for that project. A route specifies how packets leaving a virtual machine instance should be directed. For example, a route might specify that packets destined for a particular network 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 must also specify which instances the route should apply to. Each virtual machine instance in your project then pulls 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 two default routes: a route that directs traffic to the Internet and a route that directs traffic to other instances within the 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 outgoing 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.
For workloads and benchmarks that the Compute Engine team regularly measure:
- 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 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.