# VPC Subnets and IP Addressing > Chapter 3 of the Courseiva GOOGLE-PCNE curriculum — https://courseiva.com/learn/google-pcne/vpc-subnets-and-ip-addressing **Official objective:** 2.2 — Design and implement subnets and IP address allocation ## Introduction 2.3 — Design and implement subnets and IP address allocation is the exam domain that governs this chapter. VPC subnets and IP addressing are the fundamental building blocks that let you organise your cloud network in a logical, secure, and scalable way. For the PCNE exam, mastering this concept is non-negotiable because every network design question — from routing to firewall rules — depends on how you carve up your IP address space. ## The Urban Mail Delivery Route Analogy A postal route manager for a large city is the real-world role at the centre of this analogy. Their job is to organise how mail gets delivered across thousands of addresses every day. The city itself is the cloud region, and the entire postal network of sorting centres and delivery vans is the Virtual Private Cloud (VPC). The manager can't just send one van to every house at once — that would be chaos. Instead, they divide the city into delivery zones called subnets. Each subnet gets its own local sorting office (a subnet route table) and a contiguous block of postal codes (an IP address range, like 10.0.1.0 through 10.0.1.255). The manager assigns specific postal code ranges to specific neighbourhoods so that mail from one street never gets mixed up with mail from another street. Some zones are public-facing, like a high-street delivery point where anyone can send parcels (a public subnet with an internet gateway). Other zones are private, like a gated community where only authorised delivery vans can enter (a private subnet with no direct internet access). The manager also reserves a few postal codes for special purposes — for example, the first and last house numbers in each zone are kept aside for network addresses and broadcast addresses, just like the first and last IP addresses in a subnet are reserved for the network identifier and the broadcast address. Every parcel that arrives at the city sorting centre must be labelled with the correct zone and the specific house number — otherwise, the delivery van will never know where to go. This is exactly how IP routing works in a VPC: each packet of data carries a destination IP address, and the subnet structure determines which router and which local network the packet is delivered to. Without carefully planned subnets, data would end up at the wrong building or get lost entirely. ## Core explanation In cloud networking, a Virtual Private Cloud (VPC) is your own isolated slice of a public cloud provider's infrastructure. Think of it as a virtual data centre that sits inside the cloud. Before you can put any resources — like virtual machines (VMs) or databases — into that VPC, you must organise it into smaller segments called subnets. A subnet is a logical subdivision of an IP network. In plain terms, a subnet is a range of IP addresses that live inside your VPC. Let's break down what an IP address is. An IP address is a numerical label assigned to every device connected to a computer network that uses the Internet Protocol (IP) for communication. It works like a mailing address for your computer. There are two main versions: IPv4, which looks like 192.168.1.1, and IPv6, which looks like 2001:0db8:85a3:0000:0000:8a2e:0370:7334. For the PCNE exam, you will mostly deal with IPv4, though IPv6 knowledge is also tested. Each IP address on a subnet must be unique. If two VMs in the same subnet had the same IP address, the network wouldn't know which one to send data to — like two houses sharing the same postal code and house number. The cloud provider automatically assigns an IP address to each resource you launch, but you choose which subnet it goes into and, optionally, a specific private IP address within that subnet's range. When you create a subnet, you must specify its IP address range using Classless Inter-Domain Routing (CIDR) notation. CIDR notation is a compact way to write an IP address and its associated routing prefix. For example, 10.0.1.0/24 means 'all addresses from 10.0.1.0 to 10.0.1.255'. The '/24' part is the subnet mask, telling you how many bits of the address represent the network portion. The bigger the number after the slash, the fewer individual IP addresses are available. A /24 gives 256 total addresses, but some are reserved. A /16 gives 65,536 addresses. Choosing the right size for your subnet is critical. If your subnet is too small, you might run out of IP addresses and be unable to launch new resources. If it is too large, you waste IP address space that could be used by other subnets. The cloud provider reserves the first four IP addresses and the last one in each subnet range for internal networking purposes. For example, in a 10.0.1.0/24 subnet, the addresses 10.0.1.0 (network address), 10.0.1.1 (gateway), 10.0.1.2 (DNS), 10.0.1.3 (reserved for future use), and 10.0.1.255 (broadcast) are not available for you to use. This is important to remember for exam questions that ask you to calculate usable host addresses. Why do subnets exist in the first place? They exist for several reasons: - Isolation: Different subnets can be placed in different availability zones (AZs) to protect against a single datacentre failure. - Security: You can attach different firewall rules (called security groups or network ACLs) to different subnets. For instance, you might put a web server in a public subnet that allows internet traffic, and a database in a private subnet that only allows traffic from the web server subnet. - Organisation: Subnets let you group resources by function, environment (production vs. development), or team. In the exam, you will also encounter the concept of 'VPC peering' and 'shared VPCs'. VPC peering connects two VPCs so they can route traffic using private IP addresses, like linking two separate office networks with a private cable. A shared VPC lets multiple projects or teams use the same VPC and its subnets, allowing centralised control over IP address management. When you design subnets for a Google Cloud project, you must decide whether to use auto-mode VPC networks or custom-mode VPC networks. Auto-mode networks automatically create subnets in each region with predetermined IP ranges. Custom-mode networks give you full control to define your own subnets. The exam expects you to know the trade-offs: auto-mode is simpler but can run out of IP space for large deployments; custom-mode offers flexibility but requires careful manual planning. Finally, IP address allocation isn't just about choosing a CIDR block. You also need to think about whether IP addresses are ephemeral (temporary, released when the resource stops) or static (permanent, reserved until you explicitly release it). The exam tests which scenarios require static IP addresses — for example, when you need a DNS record to point to a fixed address for a production service. Understanding VPC subnets and IP addressing thoroughly is the foundation for every other network concept you will learn for the PCNE exam. ## Real-world context A network engineer at a mid-sized e-commerce company is asked to design the network for a new cloud-deployed application that will serve customers in Europe and Asia. The application has three tiers: a web frontend that faces the internet, an application logic layer, and a database that stores customer orders. Here is exactly what that engineer does with VPC subnets and IP addressing. First, the engineer opens Google Cloud Console and creates a custom-mode VPC network named 'ecommerce-prod-vpc'. They choose custom mode because the auto-mode default ranges might overlap with IP addresses used by the company's on-premises data centre in Frankfurt. The engineer allocates a large IP range of 10.0.0.0/8 for the whole VPC, but immediately divides it into smaller ranges for each region. Next, they create subnets in two regions: europe-west1 (Belgium) and asia-east1 (Taiwan). For europe-west1, they create three subnets: - A public subnet with the CIDR range 10.0.10.0/24 for web frontend VMs. - A private subnet with the CIDR range 10.0.20.0/24 for application servers. - A private subnet with the CIDR range 10.0.30.0/24 for the managed database service. For asia-east1, they replicate the same structure but with different CIDR ranges: 10.0.110.0/24, 10.0.120.0/24, and 10.0.130.0/24. They carefully check that none of these ranges overlap — both within the same VPC and with the on-premises network (which uses 172.16.0.0/12). Overlapping ranges would break VPC peering and site-to-site VPN connectivity. The engineer then configures firewall rules. The public subnet allows inbound HTTP/HTTPS traffic from the entire internet (0.0.0.0/0). The application subnet only allows traffic from the web subnet (10.0.10.0/24). The database subnet only allows traffic from the application subnet (10.0.20.0/24). They also ensure that no subnet has a default route to the internet except the public ones. During deployment, one of the application servers in europe-west1 needs a static internal IP address because a legacy on-premises reporting tool is configured to connect to that specific IP every night via a VPN tunnel. The engineer reserves a specific IP (10.0.20.5) for that server using Google Cloud's static internal IP feature. Later, the company acquires a smaller business that also runs a VPC in Google Cloud. The engineer sets up VPC peering between the two VPCs. To make it work, the CIDR ranges in the acquired company's VPC must not overlap with 10.0.0.0/8 or 10.0.200.0/16. They discover an overlap in the 10.0.100.0/24 range and must re-IP some of the acquired company's subnets before peering — a painful but necessary process. Finally, the engineer documents the entire IP allocation scheme in a spreadsheet shared with the operations team, listing each subnet's name, region, CIDR, purpose, and firewall rules. This documentation is critical for troubleshooting and for future expansions. In the real world, this kind of subnet planning can take days or weeks for large enterprises. Mistakes made at the start — such as picking a CIDR range that is too small or that overlaps with existing networks — can cause outages that are expensive and time-consuming to fix. ## Exam focus The PCNE exam tests VPC subnets and IP addressing in several distinct ways. Expect to see multiple-choice and multiple-select questions that require you to design or troubleshoot subnet schemes. Here are the specific question types and trap patterns you must know: - Calculating usable IP addresses: The exam will give you a CIDR range like 10.1.0.0/27 and ask for the maximum number of usable IP addresses. You must subtract 5 reserved addresses (network, gateway, DNS, reserved, broadcast) from the total. /27 gives 32 total addresses, so 27 are usable. They will also test with /28, /29, and /30 ranges. Memorise the formula: Total IPs = 2^(32 - prefix_length). Usable = Total IPs - 5. - Subnet sizing for growth: A scenario will describe a new service that expects to have N instances initially, but plans to double within two years. The question asks which CIDR range to choose. The trap is picking a range that is exactly enough for the current need, ignoring future growth. Always pick the next power of two that covers the projected maximum. - Auto-mode vs. custom-mode: The exam tests the default IP ranges for auto-mode subnets. Auto-mode VPCs automatically create subnets in every region using the 10.128.0.0/9 range. A question might describe a network design and ask whether auto-mode or custom-mode is more appropriate. The correct answer depends on whether the ranges need to be non-overlapping with on-premises or other VPCs. - IP address reservation: Topics covered include: - Primary vs. secondary IP ranges (subnets can have additional CIDR blocks attached). - Internal (private) IP addresses vs. external (public) IP addresses. - Alias IP ranges (assigning multiple IP addresses to a single VM's network interface). - VPC peering and overlapping CIDRs: A classic trap question presents two VPCs that need to be peered but their CIDR ranges overlap. The correct answer is that overlapping ranges prevent peering because VPC peering uses private IP addresses that must be unique. The candidate must recognise that you cannot peer VPCs with overlaps unless you migrate resources to new subnets. - Shared VPC and subnet sharing: Questions test your understanding of the host project (which contains the VPC and subnets) and the service project (which uses those subnets). You must know that the IAM permissions in a shared VPC are 'compute.subnetworks.use' and 'compute.subnetworks.useExternalIp'. - Reserved IP addresses in a subnet: The exam loves to ask which IP addresses in a subnet are reserved and cannot be assigned to a resource. The exact reserved IPs are: the network address (first), the default gateway (second), the second-to-last reserved for future use, the DNS server (third), and the broadcast address (last). For a /24, the reserved IPs are .0, .1, .2, .3, and .255. - Cloud NAT and private IPs: When instances in a private subnet need to access the internet (but not receive inbound connections), Cloud NAT provides outbound connectivity. The exam tests that Cloud NAT translates private IPs to a pool of public IPs. A question may ask which subnet type requires a Cloud NAT — answer: private subnets without external IP addresses. - Expansion of subnet ranges: In Google Cloud, you can expand a subnet's CIDR range after creation (you can increase the prefix length, e.g., from /24 to /23), but you cannot shrink it. The exam might test this by presenting a scenario and asking whether the range can be expanded. To prepare, you should practise subnetting calculations until they become automatic. Use online subnet calculators during study, but learn to do it manually for the exam (since calculators are not allowed). Understand the difference between /16, /17, /24, /25, /26, /27, /28 sizes in terms of total IPs and usable IPs. Be able to quickly identify which CIDR ranges overlap. ## Step by step 1. **Plan IP Address Space** — Decide which private IP range you will use (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16). Consider existing on-premises networks and other VPCs to avoid overlapping CIDRs. Document the chosen ranges and create a subnet allocation table. 2. **Create a Custom-Mode VPC** — In the Google Cloud Console, navigate to VPC Networks and create a new VPC. Choose 'Custom' mode so you have full control over subnet creation and CIDR ranges. Name the VPC descriptively, e.g., 'prod-vpc-us-central1'. 3. **Define Subnets Per Region** — For each region where you will deploy resources, create one or more subnets. Assign each subnet a non-overlapping CIDR block, e.g., 10.0.1.0/24 for public resources in us-central1, and 10.0.2.0/24 for private resources in the same region. Ensure subnet ranges fit within your overall IP plan. 4. **Reserve Static IP Addresses** — If any resource (like a load balancer or a VM that hosts DNS) needs a fixed IP, reserve a static internal or external IP address before deploying. Static IPs are not released when the resource stops, providing stability for DNS records and firewall rules. 5. **Configure Firewall Rules and Routes** — Apply ingress and egress firewall rules that reference the subnet CIDR blocks. For example, allow HTTP traffic from 0.0.0.0/0 to the public subnet's CIDR, and deny all inbound traffic to the private subnet's CIDR except from other subnets. Create custom routes if you need traffic to flow through a specific gateway (e.g., a VPN tunnel). ## Comparisons ### Auto-mode VPC vs Custom-mode VPC **Auto-mode VPC:** - Creates subnets automatically in every region - Uses a fixed IP range (10.128.0.0/9) - Simpler to set up for small deployments **Custom-mode VPC:** - Requires manual subnet creation per region - Allows any RFC 1918 CIDR range - Required for non-overlapping IP designs and large enterprises ### Ephemeral External IP Address vs Static External IP Address **Ephemeral External IP Address:** - Released when the associated resource is stopped - Attached to the resource by default - Free for resources that are running **Static External IP Address:** - Remains assigned even when the resource is stopped - Must be explicitly reserved - Incurs a small cost even when not in use ### VPC Peering vs Shared VPC **VPC Peering:** - Connects two separate VPCs across projects - Each VPC retains independent management - No transitivity: peered VPCs cannot route through each other to a third VPC **Shared VPC:** - Allows multiple projects to use the same VPC and subnets - Centralised management of IP ranges and firewalls - Support transitive routing via the shared VPC's routing table ### Primary IP Range (Subnet) vs Secondary IP Range (Alias Range) **Primary IP Range (Subnet):** - Defined when creating the subnet - Useful for most resource allocations - Can be expanded after creation **Secondary IP Range (Alias Range):** - Added to an existing subnet without changing the primary range - Confiured per VM using alias IPs - Used for services that need multiple IPs on the same interface ## Diagram _This diagram shows how a VPC in a single region contains multiple subnets, each in different availability zones, with different resource types placed into public and private subnets._ ```mermaid flowchart TD A[Region: us-central1] --> B[VPC: my-custom-vpc] B --> C[Subnet: public-web /24] B --> D[Subnet: private-app /24] B --> E[Subnet: private-db /24] C --> F[Availability Zone A] C --> G[Availability Zone B] D --> H[Availability Zone A] D --> I[Availability Zone B] E --> J[Availability Zone A] E --> K[Availability Zone B] F --> L[VM with external IP] H --> M[VM with internal IP only] J --> N[Cloud SQL database] ``` ## Common misconceptions - **Misconception:** Subnets in a VPC can be any size, including /8, because the cloud provider gives you unlimited IP addresses. **Reality:** Subnets in Google Cloud have a minimum size of /29 (8 IPs, 3 usable) and a maximum size of /8 (16 million IPs, but you cannot create subnets larger than /8). The provider does not give unlimited IPs; you only get what you allocate from the RFC 1918 private address space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or your own publicly routable IPs. (Beginners assume the cloud is infinite, but IP address space within a VPC is finite and carefully managed. The exam tests understanding of these constraints.) - **Misconception:** All IP addresses in a subnet range are usable by your VMs and resources. **Reality:** The first four IP addresses and the last IP address in every subnet are reserved by Google Cloud for internal networking (network address, gateway, DNS, reserved, and broadcast). This reduces the number of usable IPs by 5. (This misconception comes from general networking training that states only the first and last IPs are reserved. Google Cloud reserves three additional IPs (for the default gateway, DNS, and future use), which exam questions exploit.) - **Misconception:** You can create subnets in any CIDR range you want, including public IP ranges like 8.8.8.0/24, as long as you don't use them for internet-facing resources. **Reality:** Google Cloud VPCs only support private IP addresses from the RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and certain publicly routable ranges if you bring your own IP (BYOIP). Using a public IP range like 8.8.8.0/24 inside a VPC will cause routing conflicts with the internet and is not allowed. (Novices think any arbitrary range is fine because they have only used small home networks with 192.168.x.x. The exam tests awareness of RFC 1918 and BYOIP policies.) - **Misconception:** Once a subnet is created, you can change its CIDR range later if you need more IP addresses. **Reality:** In Google Cloud, you can only expand a subnet's CIDR range (make it larger, e.g., from /24 to /23). You cannot shrink it. Changing the range completely (e.g., from 10.0.1.0/24 to 10.0.2.0/24) is not possible — you would need to create a new subnet and migrate resources. (This misunderstanding leads to poor initial planning. Beginners hope they can fix mistakes later, but the exam tests the immutability of subnet design choices.) ## Key takeaways - A subnet is a logical subdivision of a VPC defined by a CIDR block of IP addresses, and each subnet resides in a single region within a single availability zone. - Five IP addresses in every subnet are reserved by Google Cloud (network address, gateway, DNS, reserved, and broadcast) and cannot be assigned to resources. - When designing subnets, always plan for future growth by choosing a CIDR range that is at least double the expected number of instances. - Auto-mode VPCs create subnets automatically in every region using the 10.128.0.0/9 range, but custom-mode VPCs give you full control over IP allocation. - VPC peering requires that the CIDR ranges of the two VPCs do not overlap; overlapping ranges break private IP routing. - Shared VPCs allow multiple projects to use the same set of subnets, enabling centralised IP management and consistent firewall rules. ## FAQ **How many IP addresses are usable in a /28 subnet in Google Cloud?** A /28 subnet has 16 total IP addresses (2^(32-28) = 16). Google reserves 5 IPs (the first four and the last), so 11 IP addresses are usable by your resources. **Can I change the CIDR range of an existing subnet in Google Cloud?** You can expand the CIDR range (make it larger, e.g., from /24 to /23), but you cannot shrink it or change it to a completely different range. To change the range, you must create a new subnet and migrate your resources. **What is the difference between auto-mode and custom-mode VPC networks?** Auto-mode VPC networks automatically create subnets in every region using the 10.128.0.0/9 IP range. Custom-mode VPCs give you full control to define your own subnets and CIDR ranges, which is necessary for non-overlapping designs with on-premises or peered networks. **Why do I need multiple subnets if I can put everything in one large subnet?** Multiple subnets allow you to separate resources by function, security requirements, and availability zone. For example, placing web servers in a public subnet and databases in a private subnet lets you apply different firewall rules and reduce the attack surface. **Can I peer two VPCs if their subnets use overlapping IP ranges?** No. VPC peering relies on private IP routing, which requires unique IP addresses. If the peer VPCs have overlapping CIDR ranges, routing conflicts arise and peering cannot be established. You must redesign one VPC's subnets to eliminate overlaps. **What are reserved IP addresses in a Google Cloud subnet?** For any subnet, the first IP (network address), second IP (default gateway), third IP (DNS server), fourth IP (reserved for future use), and the last IP (broadcast) are reserved and cannot be assigned to any resource. ## Check your understanding 1. **How many usable IP addresses does a /26 subnet in Google Cloud provide?** Answer: A /26 subnet has 64 total addresses (2^(32-26) = 64). After subtracting the 5 reserved IPs, 59 addresses are usable. 2. **What are the reserved IP addresses in a 10.0.0.0/24 subnet?** Answer: The reserved IPs are 10.0.0.0 (network), 10.0.0.1 (gateway), 10.0.0.2 (DNS), 10.0.0.3 (reserved), and 10.0.0.255 (broadcast). 3. **A solution requires connecting two VPCs that have overlapping CIDR ranges. Can VPC peering be used?** Answer: No, VPC peering requires non-overlapping CIDR ranges to avoid routing conflicts. The overlapping subnets must be re-IPed to different ranges before peering. 4. **What is the difference between a public subnet and a private subnet in a VPC?** Answer: A public subnet has a route to the internet via an internet gateway and typically contains resources with external IP addresses. A private subnet has no direct internet route and often uses Cloud NAT for outbound traffic. 5. **Can you shrink a subnet's CIDR range in Google Cloud after creation?** Answer: No. You can only expand a subnet's range to a larger prefix (e.g., from /24 to /23). Shrinking or changing the range requires creating a new subnet and migrating resources. --- Interactive version with quiz and diagrams: https://courseiva.com/learn/google-pcne/vpc-subnets-and-ip-addressing