3.1 Virtual Private Clouds & Subnetting Architecture

Virtual Private Clouds & Subnetting Architecture

In modern enterprise cloud architecture, the Virtual Private Cloud (VPC)—termed a Virtual Network (VNet) in Microsoft Azure—forms the fundamental software-defined networking (SDN) boundary. Cloud SDN decouples network control from physical hardware, encapsulating Layer 2 and Layer 3 traffic within overlay protocols such as VXLAN (Virtual Extensible LAN) or Geneve running over the cloud service provider's (CSP) physical hypervisor fabric.

For the CompTIA Cloud+ (CV0-004) exam, cloud engineers must possess an exhaustive understanding of IPv4 CIDR allocation, public and private subnet topologies, cloud IP reservation rules, default routing mechanics, NAT gateways, VPC peering constraints, and Maximum Transmission Unit (MTU) tuning.

---

1. CIDR Block Allocation & RFC 1918 Addressing

When provisioning a VPC, the cloud architect assigns an IPv4 Classless Inter-Domain Routing (CIDR) block. Because VPCs represent isolated private networks, addresses must be drawn from the private IP ranges defined in RFC 1918.

+-----------------------------------------------------------------------------------------+
|                           RFC 1918 PRIVATE IPv4 ADDRESS SPACE                          |
|                                                                                         |
|   Class A:  10.0.0.0/8       (10.0.0.0    - 10.255.255.255)  -> 16,777,216 Addresses   |
|   Class B:  172.16.0.0/12    (172.16.0.0  - 172.31.255.255)  -> 1,048,576 Addresses    |
|   Class C:  192.168.0.0/16   (192.168.0.0 - 192.168.255.255) -> 65,536 Addresses       |
+-----------------------------------------------------------------------------------------+

Architectural Sizing Best Practices

1. Root VPC Sizing (/16):
   • A /16 CIDR block (e.g., 10.100.0.0/16) yields 65,536 total addresses. This is the industry-standard root size for enterprise VPCs, providing sufficient address space to carve out dozens of multi-tier, multi-Availability Zone (AZ) subnets.
2. Standard Subnet Tiering (/24):
   • A /24 block (e.g., 10.100.1.0/24) yields 256 total IP addresses (251 usable in AWS). This size is optimal for general application, database, and container workload tiers across distinct AZs.
3. Micro-Tiering and Management (/28):
   • A /28 block yields 16 total IP addresses (11 usable in AWS). Used for dedicated management endpoints, bastion hosts, or specialized firewall appliances.
4. Non-Overlapping IP Planning:
   • In multi-VPC, hybrid-cloud, and multi-cloud designs, CIDR blocks must never overlap. Overlapping IP blocks prevent the establishment of VPC Peering, Transit Gateway attachments, Direct Connect routing, and Site-to-Site IPSec VPN tunnels without complex Source/Destination NAT workarounds.

---

2. Cloud Service Provider Reserved IP Addresses

On physical on-premises networks, a subnet reserves only 2 addresses: the Network Address (first IP) and the Broadcast Address (last IP). In public cloud environments, however, broadcast and multicast traffic are disabled at the hypervisor layer, and CSPs allocate specific internal infrastructure services directly inside every provisioned subnet.

AWS Subnet IP Reservations (5 Reserved IPs per Subnet)

In AWS, 5 IP addresses are reserved in every CIDR block and cannot be assigned to user workloads. For example, in a 10.0.1.0/24 subnet:

Formula for Usable IP Addresses:
$\text{Usable IPs} = 2^{(32 - \text{Prefix})} - 5$

• For a /24 subnet: $2^{(32 - 24)} - 5 = 256 - 5 = \mathbf{251\text{ usable IPs}}$
• For a /28 subnet: $2^{(32 - 28)} - 5 = 16 - 5 = \mathbf{11\text{ usable IPs}}$
• For a /16 VPC: $2^{(32 - 16)} - 5 = 65,536 - 5 = \mathbf{65,531\text{ usable IPs}}$

(Note: Microsoft Azure similarly reserves 5 IP addresses per subnet: network address, default gateway, two DNS/management addresses, and broadcast. Google Cloud Platform (GCP) allocates subnets across entire regions and does not reserve a broadcast address, but reserves the gateway and base identifiers.)

---

3. Public vs. Private Subnets & Egress Architecture

A subnet's classification as public or private is determined strictly by its associated Route Table configuration.

+-------------------------------------------------------------------------------------------------------+
|                                PUBLIC VS. PRIVATE SUBNET TRAFFIC FLOW                                 |
|                                                                                                       |
|   [ INTERNET ]                                                                                        |
|        |                                                                                              |
|   +----+------------------------------------------------------------------------------------------+   |
|   |    | (Direct Inbound/Outbound via IGW)                                                        |   |
|   |    v                                                                                          |   |
|   | +-------------------------------------------------------------------------------------------+ |   |
|   | | PUBLIC SUBNET (10.0.1.0/24)                                                               | |   |
|   | | Route Table: 0.0.0.0/0 -> igw-0a1b2c3d                                                    | |   |
|   | |                                                                                           | |   |
|   | |  +--------------------------+                 +-----------------------------------------+ | |   |
|   | |  | Public Load Balancer /  |                 | Managed NAT Gateway                     | | |   |
|   | |  | Web Ingress Appliance    |                 | Elastic IP: 54.210.10.25                | | |   |
|   | |  | Elastic IP: 54.210.10.10 |                 | Private IP: 10.0.1.50                   | | |   |
|   | |  +--------------------------+                 +-----------------------------------------+ | |   |
|   | +------------------------------------------------------------^------------------------------+ |   |
|   |                                                              | (Outbound Egress Only)         |   |
|   |                                                              | (SNAT to 54.210.10.25)         |   |
|   | +------------------------------------------------------------+------------------------------+ |   |
|   | | PRIVATE SUBNET (10.0.2.0/24)                                                              | |   |
|   | | Route Table: 0.0.0.0/0 -> nat-09876543                                                    | |   |
|   | |                                                                                           | |   |
|   | |  +-------------------------------------+      +-----------------------------------------+ | |   |
|   | |  | Application Server (10.0.2.14)      |      | Database Cluster (10.0.2.88)            | | |   |
|   | |  | (No Public IP; Egress via NAT GW)   |      | (Isolated; No External Access)          | | |   |
|   | |  +-------------------------------------+      +-----------------------------------------+ | |   |
|   | +-------------------------------------------------------------------------------------------+ |   |
|   +-----------------------------------------------------------------------------------------------+   |
+-------------------------------------------------------------------------------------------------------+

1. Public Subnets & Internet Gateways (IGW)

• Definition: A public subnet is a subnet whose route table contains an explicit default route pointing to an Internet Gateway (IGW): $\texttt{0.0.0.0/0} \longrightarrow \texttt{igw-xxxx}$
• Internet Gateway Characteristics: An IGW is a horizontally scaled, redundant, highly available VPC component that performs 1:1 Static Network Address Translation (1:1 NAT) between private instance IP addresses and public Elastic IPs. It does not introduce bandwidth bottlenecks.
• Prerequisites for Internet Access: For an instance in a public subnet to reach the internet, it requires: (1) a route to an IGW, (2) a publicly routable IPv4 address (Public IP or Elastic IP), and (3) permissive Security Group / NACL rules.

2. Private Subnets & NAT Gateways

• Definition: A private subnet does not have a route to an IGW. Its route table sends external traffic to a Network Address Translation (NAT) Gateway: $\texttt{0.0.0.0/0} \longrightarrow \texttt{nat-xxxx}$
• Architecture of Managed NAT Gateways:
  • A NAT Gateway must reside inside a Public Subnet and have an allocated Elastic Public IP.
  • Instances in the private subnet send outbound traffic (e.g., OS patches, package updates, API calls) through the NAT Gateway. The NAT Gateway performs Source NAT (SNAT), replacing the private source IP with its public Elastic IP.
  • Inbound connections initiated from the public internet are completely blocked by the NAT Gateway, safeguarding internal backends from external scans.

Comparison: Managed NAT Gateway vs. Self-Managed NAT Instance

---

4. Route Tables & Longest Prefix Match Rule

Every VPC contains a Main Route Table, and subnets can be explicitly associated with Custom Route Tables.

Route Table Mechanics

1. The Local Route: Every VPC route table contains a default local route covering the entire VPC CIDR (e.g., 10.0.0.0/16 -> local). This route is immutable and enables direct Layer 3 routing between all subnets within the VPC regardless of AZ.
2. Longest Prefix Match (LPM): When evaluating multiple routing rules, cloud virtual routers always apply the most specific route (the route with the longest subnet mask prefix). For example:
   • Route A: 10.0.0.0/16 -> local
   • Route B: 10.0.2.0/24 -> pcx-11223344 (VPC Peering)
   • Route C: 0.0.0.0/0 -> nat-09876543
   • A packet destined for 10.0.2.55 matches all three rules, but the router selects Route B because /24 is more specific than /16 or /0.

---

5. VPC Peering Architecture & MTU Considerations

VPC Peering is a direct networking connection between two VPCs that enables routing using private IPv4/IPv6 addresses.

+-----------------------------------------------------------------------------------------+
|                         VPC PEERING & NON-TRANSITIVE ROUTING                            |
|                                                                                         |
|   +-------------------+        VPC Peering Connection         +-------------------+     |
|   |   VPC A           | <===================================> |   VPC B           |     |
|   |   (10.1.0.0/16)   |              (ACTIVE)                 |   (10.2.0.0/16)   |     |
|   +-------------------+                                       +-------------------+     |
|                                                                         ^               |
|             X (NO TRANSITIVE ROUTING)                                   | (ACTIVE)      |
|             | (Packets CANNOT route from A to C through B)              v               |
|   +-------------------+        VPC Peering Connection         +-------------------+     |
|   |   VPC C           | <===================================> |   VPC B           |     |
|   |   (10.3.0.0/16)   |              (ACTIVE)                 |   (10.2.0.0/16)   |     |
|   +-------------------+                                       +-------------------+     |
|                                                                                         |
|   RESOLUTION FOR FULL CONNECTIVITY:                                                     |
|   1. Direct Peering Mesh: Establish a direct peering connection between VPC A and VPC C |
|   2. Hub-and-Spoke Architecture: Deploy a Transit Gateway (TGW) connecting A, B, and C  |
+-----------------------------------------------------------------------------------------+

Non-Transitive Routing Constraint (Core Exam Concept)

• VPC Peering is strictly non-transitive.
• If VPC A is peered with VPC B, and VPC B is peered with VPC C, traffic from VPC A cannot reach VPC C through VPC B.
• Edge routing constraints also prevent transitive peering across external gateways: an on-premises data center connected to VPC B via Direct Connect or VPN cannot reach VPC A through VPC B's peering connection.
• Resolution: To achieve full connectivity across multiple VPCs, engineers must either build a full-mesh peering topology ($N(N-1)/2$ connections) or deploy a centralized Transit Gateway (TGW).

Maximum Transmission Unit (MTU) & Jumbo Frames

• Standard Ethernet MTU (1500 bytes): Mandatory for all traffic traversing the public internet, inter-region VPC peering connections, and VPN connections.
• Jumbo Frames (9001 bytes MTU): Supported for intra-VPC traffic, cluster placement groups, and direct connections within the same region. Jumbo frames significantly reduce CPU packet processing overhead and maximize throughput for storage replication (SAN/NAS), high-performance computing (HPC), and distributed database synchronization.
• Path MTU Discovery (PMTUD): Ensures endpoints negotiate the optimal packet size without fragmentation. Security groups and firewalls must permit ICMP Type 3, Code 4 (Destination Unreachable, Fragmentation Needed) to prevent black-hole packet drops caused by PMTUD failures.

---

6. CompTIA Cloud+ Exam Traps & Real-World Troubleshooting

[!CAUTION] Exam Trap 1: Private Subnet Instance with Public IP Cannot Connect to Internet
Assigning a Public IP to an instance in a private subnet does not grant internet connectivity. If the subnet's route table does not contain a route pointing 0.0.0.0/0 to an Internet Gateway (igw-xxxx), packets will be dropped by the virtual router.

[!WARNING] Exam Trap 2: NAT Gateway Located in a Private Subnet
A common architectural error on the exam involves placing a NAT Gateway inside a private subnet. Because the NAT Gateway itself requires direct access to an Internet Gateway to translate and forward traffic, placing it in a private subnet breaks all outbound egress for the entire VPC. The NAT Gateway must always be deployed in a public subnet.