Resources that are in the same VPC can communicate using internal IP addresses, as well as using a project-internal DNS facility. This is true even if the resources are in different regions. For instance, consider two VMs, one in the US and the other in the UK; provided these are in the same VPC, they will be able to communicate using internal IP addresses despite their physical distance.

By contrast, if two resources are in different VPCs, even if they happen to be in the same region or even on the same underlying bare metal box (remember that GCP VMs are multi-tenanted), they will still have to communicate using external IP addresses, which implies that the network traffic between them will have to pass over the internet (or Google’s global network in this case).

Internal IP addresses are assigned from the subnet range using the familiar DHCP protocol, and they are renewed every 24 hours. Each VM on a subnet is accessible using a network-scoped DNS. The Fully Qualified Domain Name (FQDN) for a VM is of the form:

    [HOST_NAME].c.[PROJECT_ID].internal

External IP addresses, on the other hand, are ephemeral by default. If you'd like to fix an external IP address, you need to reserve it. Such reserved external IP addresses are said to be static and are chargeable if they are not in use. This is meant to deter folks from needlessly reserving IP addresses and then not using them.

Finally, you should be aware that a VM is not aware of its external IP address, that's a part of the metadata and is stored in a metadata server. So, if you run ifconfig on a VM, what you see is the internal IP address.

Communication on internal IP addresses has several advantages:

• Cost: Remember that network egress traffic incur charges. Communication over internal IP addresses costs as low as $0.01/GB.
• Security: Google's internal networks are relatively invulnerable to intrusion and security attacks. After all, Google has been under siege from hackers for over a decade now. However, once traffic leaves Google's internal networks and touches the internet, all bets are off.
• Latency: Google internal networks are blazingly fast. This is partially a legacy of Google's investments in YouTube, and in trying to get video served at acceptable latencies in all or most regions of the world. Internal traffic on the GCP is able to hitch a ride on these really fast internal links.

If you do have resources in different VPCs or even different projects that you'd like to hook up with internal links, two relatively advanced features you can consider are:

• VPC peering: This is a way to establish a pipe between a pair of VPCs. In case you are wondering how this differs from VPN, the encryption is done at network layer itself and is applied to private IPs within the same VPC.
• Shared VPC: This is a way to create a VPC in project A, and then have resources such as VMs that reside in a different project (projects B and C) which still reside on the same VPC. Project A is called the host project, and incurs the costs associated with the shared VPC.