IP addresses

Many Google Cloud resources can have internal IP addresses and external IP addresses. For example, you can assign an internal and external IP address to Compute Engine instances. The instances use these addresses to communicate with other Google Cloud resources and external systems.

Each network interface used by an instance must have one primary internal IPv4 address. Each network interface can also have one or more alias IPv4 ranges, and one external IPv4 address. If the instance is connected to a subnet that supports IPv6, each network interface can also have internal or external IPv6 addresses assigned.

An instance can communicate with instances on the same Virtual Private Cloud (VPC) network, using the instance's internal IPv4 address. If the instances have IPv6 configured, you can also use one of the instance's internal or external IPv6 addresses. As a best practice, use internal IPv6 addresses for internal communication.

To communicate with the internet, you can use an external IPv4 or external IPv6 address configured on the instance. If no external address is configured on the instance, Cloud NAT can be used for IPv4 traffic.

Similarly, you must use the instance's external IPv4 or external IPv6 to connect to instances outside of the same VPC network. However, if the networks are connected in some way, such as by using VPC Network Peering, you can use the instance's internal IP address.

For information about identifying the internal and external IP address for your instances, see View the network configuration for an instance.

Internal IP addresses

The network interfaces for an instance are assigned IP addresses from the subnet that they are connected to. Each network interface has one primary internal IPv4 address, which is assigned from the subnet's primary IPv4 range. If the subnet has an internal IPv6 range, then in addition to the primary internal IPv4 address, you can optionally configure the network interface with a primary internal IPv6 address.

Internal IPv4 addresses can be assigned in the following ways:

  • Compute Engine assigns a single IPv4 address from the primary IPv4 subnet ranges automatically.
  • You can assign a specific internal IPv4 address when you create a compute instance.

Internal IPv6 addresses can be assigned to instances that are connected to a subnet that has an internal IPv6 range in the following ways:

You can also reserve a static internal address from the subnet's IPv4 or IPv6 range and assign it to an instance.

Compute instances can also have alias IP addresses and ranges. If you have more than one service running on an instance, you can assign each service its own unique IP address.

Internal DNS names

Google Cloud automatically resolves the fully qualified DNS name (FQDN) of an instance to the internal IP addresses of the instance. Internal DNS names work only within the instance's VPC network.

For more information about fully qualified domain names (FQDN), see Internal DNS.

External IP addresses

If you need to communicate with the internet or with resources in another VPC network, you can assign an external IPv4 or IPv6 address to an instance. If firewall rules or hierarchical firewall policies allow the connection, sources from outside a VPC network can reach a specific resource using its external IP address. Only resources with an external IP address can directly communicate with resources outside of the VPC network. Communicating with a resource using an external IP address can cause additional billed charges.

Alternatives to using an external IP address

Internal, or private, IP addresses provide a number of advantages over external, or public, IP addresses, including:

  • Reduced attack surface. Removing external IP addresses from compute instances makes it more difficult for attackers to reach the instances and exploit potential vulnerabilities.
  • Increased flexibility. Introducing a layer of abstraction, such as a load balancer or a NAT service, allows more reliable and flexible service delivery when compared with static, external IP addresses.

The following table summarizes the ways that compute instances can access or be accessed from the internet when they don't have an external IP address.

Access method Solution Best used when
Interactive Configure TCP forwarding for Identity-Aware Proxy (IAP) You want to use administrative services like SSH and RDP to connect to your backend instances, but the requests must pass authentication and authorization checks before they get to their target resource.
Fetching Cloud NAT gateway

You want your Compute Engine instances that don't have external IP addresses to connect to the internet (outbound), but hosts outside of your VPC network can't initiate their own connections to your compute instances (inbound). You might use this approach for OS updates or external APIs.

Secure Web Proxy You need to isolate your Compute Engine instances from the Internet by creating new TCP connections on their behalf, while adhering to the administered security policy.
Serving Create an external load balancer You want clients to connect to resources without external IP addresses anywhere in Google Cloud while protecting your compute instances from DDoS attacks and direct attacks.

Regional and global IP addresses

When you list or describe IP addresses in your project, Google Cloud labels addresses as global or regional, which indicates how a particular address is being used. When you associate an address with a regional resource, such as an instance, Google Cloud labels the address as regional. Regions are Google Cloud regions, such as us-east4 or europe-west2.

Global IP addresses are used in the following configurations:

For instructions on how to create a global IP address, see Reserve a new static external IP address.

Overview of the SLA for Compute Engine networking

Compute Engine has a Service Level Agreement (SLA), which defines service level objectives (SLOs) for the monthly uptime percentage for network service tiers.

When you create a Compute Engine instance, by default you get an internal IP address. You can additionally configure an external IP address with either Premium Tier (default) or Standard Tier networking. Which network service tier you choose depends on your cost and quality of service requirements. Each network service tier has a different SLO.

When you create the compute instance, you can configure multiple NICs attached to the instance, and each NIC can have a different network configuration, as shown in the following diagram:

An instance with three NICs, each of which handles different network traffic with different network service tiers.

Figure 1. An instance with three NICs, each of which handles different network traffic with different network service tiers.

In the preceding diagram, the example instance named VM appliance has three NICs, which are configured as follows:

  • nic0 is configured with an internal IP subnet.
  • nic1 is configured with an external IP subnet and uses the Standard networking tier.
  • nic2 is configured with an external IP subnet and uses the Premium networking tier.

In this example, the VM instance is not a memory-optimized VM. Depending on which NIC suffers a connectivity loss, different SLOs are applicable. The following list describes the SLA for the different NICs in this example.

  • nic0: A single-instance VM with internal IP addresses. The monthly uptime percentage is 99.9%.
  • nic1: A single-instance VM with an external IP address that uses the Standard networking tier. This VM isn't protected by any SLA. Only multiple instances across zones are protected at 99.9% with the Standard networking tier.
  • nic2: A single-instance VM with external IP address that uses the Premium networking tier. The monthly uptime percentage is 99.9%. For multiple instances across zones, the monthly uptime percentage is 99.99% with the Premium networking tier.

What's next