Private vs Public IP Addresses in GCP | Internal, External, Static, and Ephemeral

Simple explanation

These two concepts answer different questions:

• Private vs public: who can reach this address?
• Static vs ephemeral: does this address stay the same?

A private (internal) IP is an RFC 1918 address drawn from your subnet. It is only reachable within your VPC and any networks connected to it. Nothing on the public internet can send traffic to it directly.

A public (external) IP is an internet-routable address. Anyone on the internet can attempt to connect to it, subject to your firewall rules. This is optional. Most VMs do not need one.

A static address is reserved explicitly and persists even when the VM is stopped or restarted. An ephemeral address is temporary: assigned when the resource starts and released when it stops.

These two dimensions are independent. An internal address can be static or ephemeral. An external address can be static or ephemeral. A database server typically has a static internal IP. A load balancer typically has a static external IP. A short-lived dev VM might have an ephemeral external IP. All four combinations exist and make sense in different situations.

How IP addresses work in GCP

When you create a VM, GCP’s DHCP service assigns it an internal IP from the subnet you selected. That subnet belongs to a VPC network. Every VM in GCP must live in a subnet. There is no network without one.

External IPs are assigned separately, only if you request one. If you leave the external IP field blank when creating a VM, the VM has no public address at all. GCP does not silently attach one.

A few things worth understanding before you go further:

• VPC boundaries control reachability. VMs in the same VPC can communicate using internal IPs across regions. VMs in different VPCs cannot communicate privately unless you connect them via VPC Peering or Shared VPC.
• Firewall rules apply to all traffic, not just external. Even VM-to-VM traffic within a VPC is subject to firewall policy. See Firewall Rules Explained for how ingress and egress rules work.
• Having no external IP is a stronger guarantee than a restrictive firewall. A firewall rule can be misconfigured or modified by mistake. A VM with no external IP cannot receive inbound internet traffic by any route. There is simply no address for internet hosts to send to.
• Public vs private is separate from static vs ephemeral. You can mix and match freely. The two dimensions do not constrain each other.

Private vs public IP addresses

If a resource does not need to receive traffic from the internet, and does not need to initiate outbound internet connections on its own, it should have no external IP. Most internal services fit that description: app servers, databases, caches, background workers.

For VMs that need outbound internet access but should not be reachable inbound, use Cloud NAT. For VMs that only need to reach Google APIs, use Private Google Access instead, which never touches the public internet at all.

Ephemeral vs static IP addresses

Static and ephemeral are about persistence, not visibility. This applies equally to internal and external addresses.

You reserve a static address with gcloud compute addresses create. You can specify a region (for regional VMs), global (for global load balancers), and whether it is internal or external.

# Reserve a static external IP in a region
gcloud compute addresses create web-server-ip \
  --region=us-central1

# Reserve a static global external IP (for global load balancers)
gcloud compute addresses create my-global-ip \
  --global

# Reserve a static internal IP at a specific address
gcloud compute addresses create db-internal-ip \
  --region=us-central1 \
  --subnet=db-subnet \
  --addresses=10.0.2.5

# List all reserved addresses (check for idle ones)
gcloud compute addresses list

When to use each option

Internal app server connecting to a database

Both should have only internal IPs. The app connects to the database’s internal address. No external IP is needed on either. If the database restarts and could get a new address, reserve a static internal IP to keep the connection config stable.

Publicly reachable web server

One external IP, ideally on a load balancer rather than the VM itself. The load balancer holds the stable public address and backend VMs remain private. If the web server is standalone, assign a static external IP so DNS records do not break on restart. See Creating Your First VM for where external IPs are configured at creation time.

Private VM that needs to download packages

No external IP on the VM. Configure Cloud NAT on the subnet region instead. Cloud NAT translates outbound connections from the private IP to a shared public NAT address. The VM remains unreachable from the internet while still being able to reach apt, yum, Docker Hub, or any external API.

Admin SSH access to private VMs

Rather than assigning a public IP to every admin VM, use Identity-Aware Proxy (IAP) tunneling. IAP lets you open an SSH connection to a VM without an external IP using your Google identity and IAM permissions. See SSH Access in Compute Engine for both IAP and bastion host approaches.

Load balancer frontend address

Reserve a static external IP and assign it to the load balancer. Backend VMs stay private. The static address is what you put in DNS. Load balancers are long-lived, so a static address here prevents DNS drift as VMs are replaced or rotated.

Private VM that only needs Google APIs

Enable Private Google Access on the subnet. This lets the VM reach Cloud Storage, BigQuery, and other Google APIs without any internet path. No external IP and no Cloud NAT needed for those destinations.

Clearing up the most common confusion

Private vs public and static vs ephemeral are two completely independent dimensions. The confusion usually comes from hearing “static IP” and “public IP” used interchangeably, when they describe entirely different properties.

Here is a concrete way to think through the four combinations:

• Private + static: a database VM with a reserved internal IP. Not reachable from the internet, and the address never changes on restart. The right choice for any database or internal service.
• Public + static: a load balancer with a reserved external IP. Internet-routable and stable for DNS records. The standard pattern for production web traffic.
• Public + ephemeral: a dev web server with a temporary external IP. Internet-reachable but the address changes on restart. Fine for short-lived testing. Not suitable for production DNS.
• Private + ephemeral: the default for most VMs. A background worker or app server that only talks to other VMs in the same VPC. No internet exposure, no persistent address needed.

If you are troubleshooting connectivity and not sure which type of address is involved, Troubleshooting Network Issues covers how to inspect VM network interfaces and verify what addresses are actually assigned.