Study guide
3.1 Virtual Private Clouds & Subnetting Architecture
CompTIA Cloud+ Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Cloud Architecture Fundamentals
1.1 Cloud Service Models & Shared Responsibility 1.2 Cloud Deployment Models & Multi-Cloud Strategies 1.3 High Availability, Resiliency & Redundancy 1.4 Disaster Recovery & Business Continuity 1.5 Evolving Cloud Technologies: AI/ML Services, IoT & Edge Computing
2 Chapter 2: Cloud Compute & Storage Architecture
2.1 Virtualization & Hypervisor Architectures 2.2 Containerization & Microservices Architecture 2.3 Container Orchestration & Kubernetes Architecture 2.4 Cloud Storage Architectures & Performance
3 Chapter 3: Cloud Networking Architecture
3.1 Virtual Private Clouds & Subnetting Architecture 3.2 Hybrid & Multi-Cloud Connectivity 3.3 DNS, Load Balancing & Traffic Routing 3.4 Cloud Network Security Architecture
4 Chapter 4: Workload Assessment & Migration Planning
4.1 Cloud Migration Strategies (The 6/7 Rs) 4.2 Pre-Migration Workload Assessment & Sizing 4.3 Data & Database Migration Methods 4.4 Migration Execution, Cutover & Post-Migration Validation
5 Chapter 5: Infrastructure as Code & Provisioning
5.1 Infrastructure as Code Fundamentals & State Management 5.2 IaC Tooling & Template Authoring 5.3 Provisioning Automation & Image Management 5.4 Deployment Strategies & Release Patterns
6 Chapter 6: Cloud Operations & Lifecycle Management
6.1 Resource Lifecycle & Patch Management 6.2 Cloud Scaling Strategies & Elasticity 6.3 Cloud Cost Management & Optimization (FinOps) 6.4 Capacity Planning & Service Quotas
7 Chapter 7: Cloud Backup, Recovery & Business Continuity Operations
7.1 Backup Strategies, Storage Media & Retention Policies 7.2 Immutable Backups, Vault Locking & Ransomware Defense 7.3 Point-in-Time Recovery & Data Integrity Validation 7.4 High Availability Failover Drills & Chaos Engineering
8 Chapter 8: Cloud Security Controls & Identity and Access Management
8.1 Identity & Access Management, RBAC & ABAC 8.2 Identity Federation, SSO & Directory Integration 8.3 Multi-Factor Authentication, PAM & Machine Identities 8.4 Secrets Management & Cryptographic Credential Hygiene
9 Chapter 9: Data Protection, Vulnerability & Compliance
9.1 Data Encryption, Key Management & Confidential Computing 9.2 Vulnerability Management, Posture Assessment & CWPP 9.3 Container, Workload & Runtime Security 9.4 Cloud Compliance Frameworks & Governance Auditing
10 Chapter 10: DevOps Fundamentals & CI/CD Pipelines
10.1 Version Control Systems & Branching Strategies 10.2 Continuous Integration & Automated Testing Pipelines 10.3 Continuous Delivery, Deployment Automation & GitOps 10.4 Configuration Management & Systems Integration
11 Chapter 11: Cloud Observability & Monitoring
11.1 The Three Pillars of Observability: Metrics, Logs & Traces 11.2 Cloud Monitoring Architecture, Alerting & SLOs 11.3 Centralized Log Aggregation, SIEM & Log Analytics
12 Chapter 12: Troubleshooting Cloud Architecture & Deployments
12.1 Structured Cloud Troubleshooting Methodology 12.2 Troubleshooting Compute, Container & Storage Failures 12.3 Troubleshooting Provisioning, IaC & Automation Failures
13 Chapter 13: Troubleshooting Cloud Networking & Security
13.1 Troubleshooting Cloud Network Connectivity & Routing 13.2 Troubleshooting IAM, Permissions & Encryption 13.3 Troubleshooting Disaster Recovery & Performance Degradation
3.1 Virtual Private Clouds & Subnetting Architecture
Key Takeaways Explain This Topic AI
A Virtual Private Cloud (VPC) provides an isolated software-defined overlay network using RFC 1918 private IPv4 address allocations, with /16 being the standard root block and /24 or /28 used for subnet tiering.
Public subnets route 0.0.0.0/0 traffic directly to an Internet Gateway (IGW), whereas private subnets route outbound egress traffic through a managed NAT Gateway located within a public subnet.
Major cloud service providers reserve foundational IP addresses within every subnet (e.g., AWS reserves 5 IPs: network, VPC router gateway, DNS resolver, future provider use, and broadcast).
VPC Peering enables direct, non-transitive Layer 3 communication between non-overlapping CIDR blocks without traversing the public internet.
Intra-VPC and specialized HPC workloads can leverage Jumbo Frames (up to 9001 bytes MTU), while internet and inter-region traffic enforces the standard 1500-byte Ethernet MTU.
Last updated: August 2026
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
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.
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.
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.
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:
IP Address Allocated Entity Purpose
10.0.1.0 Network Address Binary base identifier of the subnet.
10.0.1.1 VPC Router / Default Gateway Reserved for the virtual router interface serving as the subnet's local gateway.
10.0.1.2 VPC DNS Server (AmazonProvidedDNS) Reserved for the base VPC DNS resolver (Route 53 Resolver / AmazonProvidedDNS).
10.0.1.3 Future Use Reserved by AWS for future internal platform capabilities.
10.0.1.255 Network Broadcast Reserved as the broadcast address (cloud overlay networks do not support broadcast).
Formula for Usable IP Addresses:
Usable IPs = 2 ( 32 − Prefix ) − 5 \text{Usable IPs} = 2^{(32 - \text{Prefix})} - 5 Usable IPs = 2 ( 32 − Prefix ) − 5
For a /24 subnet: 2 ( 32 − 24 ) − 5 = 256 − 5 = 251 usable IPs 2^{(32 - 24)} - 5 = 256 - 5 = \mathbf{251\text{ usable IPs}} 2 ( 32 − 24 ) − 5 = 256 − 5 = 251 usable IPs
For a /28 subnet: 2 ( 32 − 28 ) − 5 = 16 − 5 = 11 usable IPs 2^{(32 - 28)} - 5 = 16 - 5 = \mathbf{11\text{ usable IPs}} 2 ( 32 − 28 ) − 5 = 16 − 5 = 11 usable IPs
For a /16 VPC: 2 ( 32 − 16 ) − 5 = 65 , 536 − 5 = 65 , 531 usable IPs 2^{(32 - 16)} - 5 = 65,536 - 5 = \mathbf{65,531\text{ usable IPs}} 2 ( 32 − 16 ) − 5 = 65 , 536 − 5 = 65 , 531 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) : 0.0.0.0/0 ⟶ igw-xxxx \texttt{0.0.0.0/0} \longrightarrow \texttt{igw-xxxx} 0.0.0.0/0 ⟶ 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 : 0.0.0.0/0 ⟶ nat-xxxx \texttt{0.0.0.0/0} \longrightarrow \texttt{nat-xxxx} 0.0.0.0/0 ⟶ 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
Architectural Attribute Managed NAT Gateway Self-Managed NAT Instance
High Availability Built-in redundancy within the AZ; managed by CSP. Manual configuration required (must script auto-failover/ASG).
Bandwidth Scaling Automatically scales up to 45 Gbps per gateway. Limited by the EC2 instance type's network bandwidth.
Maintenance & Patching Fully managed by CSP; zero OS maintenance. Administrator must patch OS, configure iptables, and manage security.
Source/Dest Check Handled natively by cloud SDN fabric. Administrator must explicitly disable Source/Destination Check .
Port Forwarding (DNAT) Not supported (outbound SNAT only). Supported via custom Linux iptables / nftables rules.
Security Group Support Cannot attach a Security Group (governed by NACLs). Managed via standard Security Groups and NACLs.
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
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.
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 N(N-1)/2 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.