DNS, NAT, and IPs

Exam guide§3.3

Three managed pieces that show up constantly: how names resolve (Cloud DNS), how private VMs reach the internet (Cloud NAT), and how addresses are assigned (static vs ephemeral).

Cloud DNS

Managed, authoritative DNS with a 100% availability SLA.

?DECISIONPublic or private DNS zone?

Your external domain (example.com)→Publicresolvable from the internet

Internal names (db.internal)→Privateresolvable from only VPCs you authorize

Pick this when: public = resolvable on the internet; private = resolvable only inside your VPC(s)

#NumbersDNS facts

• Cloud DNS SLA: 100%. Served from Google's global anycast name servers for low latency + high availability.
• Managed and authoritative - create records via UI, gcloud, or API with no DNS servers to run; scales to millions of records.
• Private zones are attached to one or more VPCs; unauthorized VPCs cannot resolve them.
• Use DNS peering or forwarding to resolve on-prem names from GCP and vice versa.

Cloud NAT

Gives VMs without external IPs outbound internet access (egress), while blocking unsolicited inbound.

⚠GotchaCloud NAT is egress-only and needs no agent on the VM

Cloud NAT does not let the internet initiate connections in - it is outbound only. It is a regional, software-defined service (no NAT gateway VM to manage) and attaches to a Cloud Router. It is the standard way to let private VMs pull updates without giving them public IPs.

Outbound NAT: private instances reach an update server (green, allowed). Inbound is not translated - the internet cannot initiate connections in (red, blocked).

≡FactsCloud NAT logging

• Optional per-gateway; sends entries to Cloud Logging. Choose Translation (connection created), Errors (dropped - no port available), or both.
• Enable at create time or by editing the gateway (Advanced configurations → Logging).
• If ports run out, raising minimum ports per VM or adding NAT IPs fixes the dropped-packet errors.

Private Google Access

Lets VMs that have only internal IPs reach the external IPs of Google APIs and services (Cloud Storage, BigQuery, ...). Enabled per subnet.

Solid = traffic to Google APIs & Services, dashed = traffic to the internet. PGA is on for subnet-a, off for subnet-b. VM A1 (no public IP) reaches Google APIs via PGA; VMs with a public IP reach both. Only VM B1 (no public IP, PGA off) is blocked from Google APIs.

#NumbersWho can reach Google APIs

• VM A1 - internal IP only, subnet has PGA on → reaches APIs via Private Google Access.
• VM A2 / VM B2 - have a public IP → always reach APIs, PGA is irrelevant.
• VM B1 - internal IP only, subnet has PGA off → cannot reach APIs.

⚠GotchaPGA is a subnet toggle, and only matters for internal-only VMs

Private Google Access has no effect on VMs that already have an external IP. It is enabled subnet by subnet, so a VM's access depends on which subnet it sits in.

Static vs ephemeral IPs

?DECISIONStatic or ephemeral IP?

	Ephemeral	Static (reserved)
Survives VM stop/start	No (external ephemeral changes)	Yes
Cost when in use	Free	Free while attached
Cost when idle	n/a	Charged if reserved but unattached
Use for	Short-lived / disposable VMs	DNS records, firewall allowlists, LB front-ends

Pick this when: static when the address must survive a restart or be whitelisted; ephemeral otherwise

⚠GotchaA reserved static external IP costs money when NOT attached

Reserving a static external IP and leaving it unassigned incurs a charge - Google bills idle reserved IPs to discourage hoarding. Release IPs you no longer need.

≡FactsIP facts

• Internal IPs come from the subnet's range and can be static (reserved) or ephemeral.
• External IPs can be regional (VMs, regional LBs) or global (global external Application LB).
• A global anycast IP requires Premium network tier.