Subnets & IP Addressing in Google Cloud
In Google Cloud Platform (GCP), networking is fundamentally different from traditional on-premises setups or even other cloud providers. While a Virtual Private Cloud (VPC) is a global resource, its subnets are regional resources. Mastering how IP addresses are allocated and managed is a core requirement for the Associate Cloud Engineer exam.
The Hotel Analogy
Imagine a global hotel chain called “VPC International.”
- The VPC is the hotel chain’s brand—it exists everywhere.
- The Regions are the cities where the hotels are built (e.g., London, Tokyo).
- The Subnets are the specific floors in those hotels. A floor (subnet) exists only in one city (region).
- The IP Addresses are the room numbers. Even if you have thousands of rooms, every guest needs a unique number to receive mail (data packets).
Core Concepts & Detail Elaboration
1. Regional Subnets vs. Global VPC
In GCP, when you create a VPC, you don’t define an IP range for the entire VPC. Instead, you define IP ranges for individual subnets within specific regions. This allows a single VPC to span the globe while keeping traffic management localized to regions.
2. IP Address Types
- Internal IP: Allocated from the subnet range via DHCP. Used for communication within the VPC or across connected VPCs.
- External IP: Can be Ephemeral (temporary) or Static (reserved). Static IPs can be regional or global (for Load Balancers).
- Alias IP Ranges: Allows you to assign multiple internal IP addresses to a single VM network interface. Crucial for GKE (Google Kubernetes Engine) pods.
Comparison: Network Service Tiers
| Feature | Premium Tier (Default) | Standard Tier |
|---|---|---|
| Routing | Google’s global fiber backbone. | Public Internet (ISP networks). |
| Performance | High reliability, low latency. | Variable, depends on ISP congestion. |
| Cost | Higher (egress based on distance). | Lower (egress based on region). |
| Availability | Global Load Balancing supported. | Regional Load Balancing only. |
Decision Matrix: If/Then Scenarios
- IF you need to connect multiple services on one VM (like containers) THEN use Alias IP Ranges.
- IF you need a VM to keep its IP after a reboot/deletion THEN use a Static Reserved IP.
- IF you want to minimize costs for non-critical traffic THEN use Standard Tier Networking.
- IF you need to expand a subnet range without downtime THEN use the
expand-ip-rangecommand (CIDR masks can only be shrunk by recreating).
Exam Tips: Golden Nuggets
- Reserved IPs: Google reserves the first two and last two addresses in every subnet range (e.g., .0, .1, .254, .255 in a /24).
- Subnet Expansion: You can expand a subnet’s CIDR range (e.g., /24 to /22) without deleting the subnet or interrupting VMs.
- Private Google Access: This allows VMs with only internal IPs to reach Google APIs and services (like Cloud Storage) via the Google backbone.
- Auto Mode VPC: Creates one subnet per region automatically using a predefined /20 range. Avoid for production as ranges may overlap during VPC Peering.
VPC Architecture Visualized
Key Services
Cloud NAT: Allows VMs without external IPs to access the internet for updates.
Cloud DNS: Managed 1.1.1.1-style resolution for your internal VPC names.
Common Pitfalls
Overlapping Ranges: You cannot peer VPCs if their subnet IP ranges overlap.
Firewall Rules: By default, all ingress is denied. You must allow traffic even if IPs are correct.
Architecture Patterns
Shared VPC: One host project manages the network; service projects use the subnets.
Hub-and-Spoke: Central VPC (Hub) connected to multiple Spoke VPCs via Peering.