Managing VPC Networking: Subnets, Static IPs, Cloud DNS, and Cloud NAT

You resize a subnet by expanding its primary IPv4 range with a single command — and expansion is the only direction allowed. Google Cloud lets you decrease the prefix length (a /24 can become a /20), which adds addresses, but you can never increase it to shrink the range, because addresses already assigned inside it could become invalid. The command is:

gcloud compute networks subnets expand-ip-range web-subnet \
  --region=us-central1 \
  --prefix-length=20

The expansion happens in place with no downtime — existing VMs keep their addresses and the subnet simply gains room. The new range keeps the same network address and grows around it, so the whole enlarged CIDR must be free.

When an expansion is refused

The request fails if the enlarged range would:

• overlap any other subnet range in the VPC — primary or secondary (alias IP ranges used by GKE Pods and Services count);
• overlap a subnet range in a peered VPC (peered networks exchange subnet routes, so their ranges must stay distinct);
• contain the destination of an existing custom static route — a subnet cannot grow to swallow a static route's destination, because subnet routes may not overlap more-specific static routes. Delete or change the static route first;
• go beyond /16 for a subnet that was created automatically by an auto mode VPC. That ceiling stays even after you convert the network to custom mode — conversion changes how new subnets are created, not the limit on the auto-created ones. Subnets you create yourself in a custom mode network have no such cap.

Also plan around ranges learned dynamically over Cloud VPN or Cloud Interconnect, such as on-premises networks. Google Cloud does not refuse an expansion that overlaps them, but the overlap is still a design problem: traffic to those addresses would follow the subnet route and stop reaching on-premises. Check your address plan before expanding.

An expansion also changes nothing else: firewall rules, routes and allowlists that name the old CIDR are not rewritten. A rule that allowed 10.10.0.0/24 still allows only that block, so VMs that receive addresses from the new part of the range are silently outside it until you update the rule's source or destination ranges (or switch it to tag or service-account matching).

If you truly need a smaller range, there is no shrink operation — create a new subnet with the desired range, migrate workloads, and delete the old one. When a subnet is running out of IPs and workloads must keep running, expanding in place is the operation; recreating the subnet is only for shrinking or moving to a non-contiguous range.

You reserve a static IP address so an endpoint keeps the same address across instance stops, restarts, and re-creations. Ephemeral addresses are not permanent, and they are released at different moments: an ephemeral external IP is released when the VM stops (a reset keeps it) or is deleted, while an ephemeral internal IP survives a stop but is released when the VM is deleted. Google Cloud has two kinds of static address, reserved with the same command family:

Scope and attachment

The scope of an external address must match what uses it. A VM needs a regional address in the VM's region — and that address can be attached to a VM in any zone of that region, because zones do not scope addresses. A global external Application Load Balancer needs a global address (--global); a global address cannot be assigned to a VM, and a regional one cannot front a global load balancer. An external address is in use by one resource at a time: to move it, remove it from the current VM's access config first, then assign it to the new one. Assign a reserved external address at creation with gcloud compute instances create ... --address=app-ip.

Ephemeral, chosen, or reserved internal addresses

Choosing an internal address at VM creation (--private-network-ip=10.10.0.50) only picks which address the VM gets; unless that address was reserved, it is still ephemeral and goes back to the subnet's pool when the VM is deleted, where another resource can claim it. A reserved static internal address stays allocated to your project after the VM is gone, so a rebuilt VM can take it again.

Promoting an address already in use

To keep an address a running VM already has, promote the ephemeral address: run gcloud compute addresses create with the in-use address in --addresses (plus --subnet for an internal one) and it becomes static with no interruption — this works for both external and internal addresses, and is the way to protect an address that partners have already allowlisted or that other systems have hard-coded.

Operationally, remember that external IPv4 addresses are billed, and a reserved external address that is not attached to anything bills at a higher rate than one in use — release addresses you no longer need with gcloud compute addresses delete. Internal static addresses simply consume an address from the subnet range.

You add a custom static route when the system-generated routes are not enough — typically to send traffic for a destination range through a network virtual appliance, a VPN tunnel, or an internal load balancer, or to give a specific route to the internet gateway. Every VPC already has subnet routes (one per subnet range, created automatically) and usually a default route (0.0.0.0/0 to the default internet gateway, at priority 1000). Custom static routes layer on top:

gcloud compute routes create to-onprem \
  --network=prod-vpc \
  --destination-range=192.168.0.0/16 \
  --next-hop-vpn-tunnel=onprem-tunnel \
  --next-hop-vpn-tunnel-region=us-central1 \
  --priority=100

Next hops

Each route has exactly one next hop: --next-hop-gateway=default-internet-gateway, --next-hop-instance (an appliance VM, which must have IP forwarding enabled at creation with --can-ip-forward), --next-hop-address (an internal IP of such a VM), a VPN tunnel, or --next-hop-ilb. The ILB next hop must be the forwarding rule of an internal passthrough Network Load Balancer; because the load balancer health-checks its backends, traffic only goes to healthy appliances, which makes it the standard pattern for highly available appliances. Proxy-based load balancers such as the internal Application Load Balancer are not valid next hops.

How a route is chosen

1. Most specific destination wins: a /24 route beats a /16 for addresses in both, whatever their priorities.
2. Among routes with the same destination, the lower priority value wins (0 to 65535, default 1000).
3. Routes with the same destination and the same priority are all used: traffic is spread across their next hops with equal-cost multipath (ECMP) hashing.

That is why the default route's priority matters. A custom 0.0.0.0/0 route to an appliance only takes over internet-bound traffic if its priority number is lower than 1000; at exactly 1000 it ties with the default route and shares the traffic, and above 1000 it is never used while the default route exists.

Scoping with tags

--tags limits a route to VMs with those network tags. Scoping matters most for an appliance default route: an untagged 0.0.0.0/0 route to an appliance applies to every VM, including the appliance itself, so the appliance's own internet-bound traffic is sent back to itself in a loop. Tag the route to the workload VMs only, and the appliance keeps using the default internet gateway.

Subnet routes win outright

Subnet routes can never be overridden by a custom static route. You cannot even create a static route whose destination exactly matches or fits inside a subnet range — the request is rejected — so to inspect traffic between two subnets you need a different design (for example, placing workloads in separate VPCs joined through the appliance). A static route with a broader destination (a /16 around a /24 subnet) is allowed; it simply loses to the subnet route for that subnet's addresses. Dynamic routes learned by Cloud Router via BGP sit alongside static ones and compete under the same specificity-then-priority logic.

Cloud DNS is Google Cloud's managed, authoritative DNS service, and the operational unit is the managed zone — a container for the records of a DNS suffix. A public zone answers queries from the internet for a domain you own; a private zone answers only queries that originate from the VPC networks you authorize, which is how you give internal services friendly names like db.corp.internal without exposing them.

gcloud dns managed-zones create corp-internal \
  --dns-name=corp.internal. \
  --description="Internal names" \
  --visibility=private \
  --networks=prod-vpc

Omit --visibility (or set public) for a public zone; after creating one you must delegate the domain by pointing your registrar at the Google name servers listed on the zone. To let another VPC use a private zone, add that network to the zone's authorized networks.

Record sets

Records live in record sets — a name, a type, a TTL, and one or more values:

gcloud dns record-sets create www.example.com. \
  --zone=example-public \
  --type=A --ttl=300 \
  --rrdatas=203.0.113.10

Pick the type by the question being answered: A (IPv4) and AAAA (IPv6) map a name to an address, CNAME aliases one name to another, MX and TXT serve mail and verification. A PTR record serves only reverse lookups (address to name, in a reverse zone); it never makes a name resolve to an address — forward resolution always needs an A or AAAA record. Matching update and delete commands manage the lifecycle, and the older transaction workflow (gcloud dns record-sets transaction start/add/execute) batches multiple changes atomically.

Split horizon

A private zone and a public zone can share a suffix: VMs in the authorized networks get the private answers, the internet gets the public ones. The private zone is authoritative for the whole namespace inside those networks — if a name exists only in the public zone, internal clients get NXDOMAIN, with no fallback to public DNS. Every name internal clients need must therefore exist in the private zone too.

Resolving across VPCs and on-premises

Three details decide DNS peering questions. A peering zone's target is always another VPC network, never a set of name server IPs (that is a forwarding zone). VPC Network Peering does not share DNS — peered networks exchange routes, not private zone records — and DNS peering works whether or not the networks are VPC-peered, so it lets you keep one copy of the records in a producer network that consumers query. Creating the peering zone requires the DNS Peer role (roles/dns.peer) on the project that owns the target (producer) network. If a scenario says VMs in a VPC must resolve internal names that the internet must never see, the answer is a private zone attached to that network.

Cloud NAT gives VMs (and GKE nodes, and other private resources) outbound internet access without external IP addresses — the standard fix when private instances need to pull OS patches, container images, or external APIs while remaining unreachable from the internet. It is a fully managed, software-defined service: there is no NAT appliance VM to size, patch, or fail over, and it performs source NAT for egress only — it never admits unsolicited inbound connections, so your instances stay private.

Cloud NAT is configured on a Cloud Router in the same region and VPC network as the instances it serves:

gcloud compute routers create nat-router \
  --network=prod-vpc --region=us-central1

gcloud compute routers nats create prod-nat \
  --router=nat-router --region=us-central1 \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges

Cloud NAT or Private Google Access?

A VM without an external IP that only talks to Google services needs Private Google Access; one that must reach anything else on the internet needs Cloud NAT. Instances still need a route to the default internet gateway (the default route suffices) for either.

NAT IPs and ports

NAT IP allocation is either automatic (Google adds and removes external IPs as demand grows, so the set of source addresses can change) or manual (--nat-external-ip-pool with reserved static regional addresses — choose this when a partner must allowlist your egress IPs; you then own the capacity planning and add addresses yourself). Scope is either all subnet ranges in the region or specific subnets and ranges.

Capacity is counted in source ports. Each NAT IP provides 64,512 ports, and each VM is given at least the minimum ports per VM (default 64), so one NAT IP serves about 64,512 ÷ 64 = 1,008 VMs at the default. Raising the minimum to 1,024 ports leaves room for only 63 VMs per NAT IP. When VMs open many concurrent connections to the same destination and you see dropped connections from port exhaustion, raise the minimum ports per VM (or enable dynamic port allocation) and add NAT IPs so the total still covers the fleet — with manual allocation, add those IPs explicitly.

Other gotchas: Cloud NAT is regional — one gateway does not serve VMs in another region; a VM that has its own external IP bypasses NAT entirely; and NAT logging can record translation and drop events into Cloud Logging for troubleshooting.

VPC firewall rules control which connections may reach or leave your instances, and managing them is routine day-2 work. Rules are defined at the network level but enforced per instance, and connection tracking is stateful — allow the inbound request and the response is automatically allowed back. Every VPC carries two implied rules you cannot delete: allow all egress and deny all ingress, both at the lowest priority (65535), so any traffic you want to admit needs an explicit allow rule.

gcloud compute firewall-rules create allow-web \
  --network=prod-vpc \
  --direction=INGRESS --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web

Each rule has a direction (ingress or egress), an action (allow or deny), a protocol and port list, a source or destination filter, a priority from 0 to 65535 where the lower number wins (default 1000), and a target — all instances in the network, instances with a network tag, or instances running as a service account. Prefer target service accounts over network tags for security-relevant rules: anyone with compute.instances.setTags on a VM can change its tags and so change which rules apply, while changing a VM's service account requires stopping the VM and holding permission to act as that account, which is far more tightly controlled. Tags and service accounts cannot be mixed as targets in the same rule. When an allow rule and a deny rule match the same traffic at the same priority, the deny wins; to let an allow override a deny, give it a lower priority number.

Changing rules in place

Operational habits the exam rewards: scope source ranges tightly instead of 0.0.0.0/0 wherever possible, and remember that rules naming CIDR ranges are not updated when a subnet is expanded. Firewall Rules Logging (--enable-logging) records the connections a rule allows or denies — configuring it is covered with the other logs in the monitoring and logging lesson. To answer "why can't I SSH to this VM," check that an ingress allow for tcp:22 exists, matches the VM's tags or service account, is not disabled, and is not beaten by a deny at a lower or equal priority number.

Cloud NGFW (Next Generation Firewall) is the evolution of Google Cloud's firewalling into policy-based management: instead of individual rules attached to one network, you build firewall policies — containers of rules — and associate them where they should apply. There are three kinds:

Hierarchical policies let a security team enforce non-negotiable rules (for example, always allow the health-check ranges, always deny a known-bad range) that project teams cannot override. Network firewall policies replace sprawling per-network rule lists with one managed object per network — pick a regional policy when rules should cover a single region's resources and a global one when they should follow the network everywhere.

Evaluation order

Hierarchical policies evaluate first, top-down — organization, then folder — and a rule there can allow, deny, or delegate the decision downward with goto_next. Only if no hierarchical rule decides does evaluation continue to the network level. There, the order depends on the network's firewall policy enforcement order:

• AFTER_CLASSIC_FIREWALL (the default): classic VPC firewall rules, then the global network firewall policy, then the regional network firewall policy.
• BEFORE_CLASSIC_FIREWALL: the global and regional network firewall policies are evaluated before the classic VPC firewall rules — set with gcloud compute networks update prod-vpc --network-firewall-policy-enforcement-order=BEFORE_CLASSIC_FIREWALL. Teams migrating from classic rules to policies use this so the policy decides first.

The practical consequence: a hierarchical deny can never be undone by a project-level allow, which is exactly the guarantee central security teams want; and when a network-policy rule seems to be ignored, check whether a classic VPC rule is matching first under the default enforcement order.

Cloud NGFW also modernizes targeting and inspection. Policy rules can match on secure tags (IAM-governed resource tags, stronger than freeform network tags), FQDN and geolocation objects, and Google-maintained threat-intelligence lists. The service is tiered — NGFW Essentials covers the policy model, NGFW Standard adds the richer matching objects, and NGFW Enterprise adds intrusion prevention with TLS inspection for deep packet inspection. At associate depth: know the three policy attachment points, that hierarchical wins first, and how network policies are ordered around classic VPC firewall rules.

Tie the tasks together with a typical day-2 scenario. Your team runs a fleet of internal-only VMs (no external IPs) in app-subnet, a /24 in us-central1 on prod-vpc. Three problems arrive at once: the managed instance group cannot scale because the subnet is out of addresses; the VMs fail to download OS security updates from a third-party repository; and a partner needs to allowlist the fixed IP your traffic will come from.

Work them in order. First, the address shortage: gcloud compute networks subnets expand-ip-range app-subnet --region=us-central1 --prefix-length=22 quadruples the space in place, with no downtime and no changes to running VMs — after verifying that the enlarged /22 overlaps no other subnet's primary or secondary range, no peered or on-premises range, and no static route destination. Then update any firewall rule that names the old /24, or the new VMs will fall outside it. Second, the failed updates: the VMs have no external IPs and the repository is not a Google API, so Private Google Access alone will not help; create a Cloud Router and a Cloud NAT gateway in us-central1 on prod-vpc. Third, the allowlist: reserve a static regional external IP and configure the NAT gateway with manual NAT IP allocation pointing at it, so egress always presents that address — automatic allocation would hand Google-chosen addresses that can change as capacity scales. Check that one NAT IP's 64,512 ports cover the fleet at its minimum ports per VM, and add reserved IPs if not.

Finish with the guardrails: an ingress firewall rule allowing only the load balancer and health-check ranges to reach the fleet's service account, and a private Cloud DNS zone so other internal services reach the fleet by name rather than by individual addresses that change as instances are replaced. Every step is a gcloud command against live infrastructure with zero rebuilds — which is precisely what this exam topic is checking you can do.