Cloud Virtualization, Virtual Private Clouds (VPCs) & Subnetting

Version: 2.0.0

Purpose: Canonical lesson structure for Platform Engineering & AI Infrastructure Curriculum.

Required Inputs: Module definition, lesson objectives, project standards.

Outputs: Standards-compliant lesson markdown.

Lesson Metadata

• Lesson ID: MOD-CLOUD-01
• Module: Cloud Platforms & Architecture (MOD-CLOUD)
• Difficulty: Intermediate
• Estimated Duration: 60 minutes
• Learning Track: 🟢 Core
• Version: 2.0.0
• Last Updated: 2026-06-28

Lesson Overview

This lesson explores the master networking and boundary isolation engines of the public cloud, decrypting how Platform Engineers carve out secure, highly governed private network environments inside multi-tenant cloud providers using Virtual Private Clouds (VPCs). By mastering Cloud Virtualization (Nitro/KVM), Classless Inter-Domain Routing (CIDR), public vs. private subnetting, Internet Gateways (IGWs), NAT Gateways, Route Tables, and Security Groups, you will firmly establish the elite networking capabilities supporting our module capability: “I can design secure, highly available cloud foundation architectures and manage cloud access governance.”

Learning Objectives

• Contrast legacy physical data center networking with public cloud Virtual Private Clouds (VPCs) and hardware virtualization hypervisors (AWS Nitro, KVM).
• Calculate binary IP allocations using Classless Inter-Domain Routing (CIDR) notation, differentiating between large network blocks (/16) and subnets (/24).
• Architect a secure, multi-tier VPC topology containing isolated Public Subnets (IGW attached) and Private Subnets (NAT Gateway attached).
• Deconstruct the internal routing mechanics of AWS Route Tables, detailing how 0.0.0.0/0 default routes direct outbound packet traffic.
• Contrast stateful Security Groups (instance-level firewalls) with stateless Network Access Control Lists (NACLs - subnet-level firewalls).

Prerequisites

• Completion of Module 04 (MOD-NET: Networking Fundamentals) and Module 08 (MOD-TF: Infrastructure as Code with Terraform).
• Foundational understanding of IP addresses, routing tables, and declarative Terraform HCL syntax (aws_vpc).

Why This Exists

When junior engineers deploy an application or database to Amazon Web Services (AWS), they frequently select the “Default VPC” provided by AWS. The Default VPC is configured so that every single subnet is a Public Subnet, assigning a public IP address to every single server deployed inside it.

Deploying enterprise databases into a Public Subnet is a catastrophic security vulnerability!

Imagine you are hired to manage cloud infrastructure for a rapidly scaling financial technology company. The previous engineers deployed the company’s master PostgreSQL database directly into the AWS Default VPC. Because it lives in a public subnet, the database possesses a physical public IP address (54.210.85.12) directly exposed to the public internet.

One evening, a developer temporarily modifies the database Security Group to allow traffic from 0.0.0.0/0 (the entire internet) to debug a connection issue. Within three minutes, automated botnets scan the open port 5432, brute-force the database password, extract 500,000 customer banking records, and deploy ransomware that encrypts the entire database!

Your company has just suffered a fatal data breach!

To solve the monumental challenge of Public Network Exposure, Multi-Tenant Isolation, and Unauthorized Access, cloud pioneers established Virtual Private Clouds (VPCs) and Multi-Tier Subnetting. By carving out isolated private subnets that completely lack public internet routing, routing outbound traffic through secure NAT Gateways, and enforcing strict Security Group firewalls, Platform Engineers guarantee that your internal databases and AI microservices remain completely invisible to the public internet.

Core Concepts

1. Cloud Virtualization & The VPC Boundary

In the public cloud (AWS, Azure, GCP), millions of different companies share the exact same physical server racks inside massive data centers.

• Hardware Hypervisors (AWS Nitro / KVM): Cloud providers utilize advanced hardware hypervisors (such as the AWS Nitro system) to carve massive physical servers into isolated Virtual Machines (EC2 instances). Nitro provides strict hardware-level memory and CPU isolation, ensuring Company A cannot inspect Company B’s RAM.
• The Virtual Private Cloud (VPC): A VPC is a logically isolated virtual network carved out of the cloud provider’s global network. It acts as your own private data center in the cloud! You retain complete control over your IP address ranges, subnets, routing tables, and network gateways.

[ AWS Multi-Tenant Physical Data Center Rack ]
┌────────────────────────────────────────────────────────┐
│  [ VPC: Company A ] (10.0.0.0/16) - Strictly Isolated  │
├────────────────────────────────────────────────────────┤
│  [ VPC: Company B ] (172.16.0.0/16) - Strictly Isolated│
└────────────────────────────────────────────────────────┘

2. CIDR Subnetting (/16 vs /24)

When you create a VPC, you must allocate an IP address range utilizing Classless Inter-Domain Routing (CIDR) notation:

• The Master VPC CIDR (10.0.0.0/16): A /16 CIDR block represents a massive network containing exactly 65,536 IP addresses. This forms the master outer boundary of your VPC.
• Carving Subnets (10.0.0.1.0/24): Platform Engineers decompose the master /16 block into smaller subnet blocks (e.g., /24). A /24 subnet contains exactly 256 IP addresses (minus 5 addresses reserved by AWS for internal routing). You deploy your physical EC2 servers into these subnets!

3. Public vs. Private Subnetting

To maintain elite Platform Engineering security standards, subnets are strictly segregated into two operational tiers:

• Public Subnet: A subnet whose Route Table contains a direct default route (0.0.0.0/0) pointing to an Internet Gateway (IGW). Servers in this subnet (e.g., Nginx reverse proxies, public load balancers) possess public IP addresses and communicate directly with the internet.
• Private Subnet: A subnet whose Route Table completely lacks a route to an Internet Gateway! Servers in this subnet (e.g., enterprise databases, internal AI inference microservices) possess ONLY private IP addresses (10.0.10.15). They are physically unreachable from the public internet!
• NAT Gateway (Network Address Translation): How does a private database download system security patches from the internet if it lacks an Internet Gateway? Platform Engineers deploy a NAT Gateway inside the Public Subnet! The Private Subnet’s Route Table directs outbound traffic (0.0.0.0/0) to the NAT Gateway. The NAT Gateway acts as an outbound proxy, fetching the security patch and returning it to the database while forcefully blocking any unsolicited inbound connections from the internet!

[ Public Subnet: Nginx / ALB ] ──► [ Route: 0.0.0.0/0 ] ──► [ Internet Gateway (IGW) ] ──► [ Public Internet ]
[ Private Subnet: Database   ] ──► [ Route: 0.0.0.0/0 ] ──► [ NAT Gateway (in Public) ] ──► [ IGW ] ──► [ Public Internet ]

4. Route Tables

A Route Table is the master GPS navigation engine of your VPC. Every subnet must be explicitly associated with a Route Table.

• The Route Table inspects every network packet leaving your server. If a packet is destined for another server inside the same VPC (10.0.0.0/16), the Route Table matches the local route and directs the packet internally. If the packet is destined for Google (8.8.8.8), the Route Table matches the default 0.0.0.0/0 route and directs the packet to the appropriate gateway (IGW or NAT).

5. Security Groups vs. NACLs

To protect your servers from unauthorized network packets, Platform Engineers enforce two distinct firewall layers:

• Security Groups (Stateful): Virtual firewalls attached directly to individual EC2 instances or database network interfaces. They operate at the instance level. Security Groups are Stateful: if you create an inbound rule allowing port 443 (HTTPS) traffic from a client, the Security Group automatically remembers the connection state and allows the return response traffic outbound, regardless of outbound rules!
• Network Access Control Lists - NACLs (Stateless): Virtual firewalls attached directly to entire subnets. They operate at the subnet boundary level. NACLs are Stateless: they evaluate every single packet independently! If you allow inbound port 443 traffic, you must explicitly create a separate outbound rule allowing return traffic on ephemeral ports (1024-65535), or the return packets are forcefully dropped!

Architecture

Real-World Example

Imagine you are a Lead Platform Engineer hired to architect the cloud foundation for a highly secure healthcare enterprise handling sensitive patient medical records (HIPAA compliance).

Think of your cloud network as a highly secure layered model:

• Layer 1: External Client (e.g., Visitor’s Web Browser) represents the external visitors trying to access your application.
• Layer 2: Network Gateway (e.g., Internet Gateway / The Front Door) is the front door of your cloud neighborhood, controlling access from the outside.
• Layer 3: Public Routing (e.g., Load Balancer / The Front Yard) acts as a traffic cop in the public yard, safely directing requests.
• Layer 4: Private Compute & Storage (e.g., AI App and Database / The Secure Vault) is the secure vault deep inside where your valuable workloads and sensitive data are kept hidden from the outside world.

When visitors come to your application, they start at Layer 1 and enter through Layer 2. A friendly traffic cop in Layer 3 greets them and safely directs their requests. The requests are then passed along to the Smart Assistant and Database which live inside Layer 4. If the Database needs to fetch an update from the outside world, it isn’t allowed to use Layer 2 directly. Instead, it uses a one-way Safe Exit (NAT Gateway) securely. Your enterprise achieves perfect network isolation; patient medical records remain physically unreachable from the public internet, passing HIPAA compliance audits flawlessly!

Hands-on Demonstration

Let’s look at how an engineer inspects a multi-tier Terraform VPC configuration manifest using cat, inspects active route table entries using aws ec2 describe-route-tables, and inspects security group rules.

Input 1: Inspecting Multi-Tier Terraform VPC Manifests (main.tf)

We use cat to inspect a pristine, highly governed Terraform configuration manifest defining a master VPC, public subnets, private subnets, IGWs, NAT Gateways, and Route Tables.

Code 1

# Inspect the declarative Terraform multi-tier VPC configuration manifest.
# (We simulate inspecting a compliant Terraform networking file)
cat << 'EOF'
resource "aws_vpc" "production" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = { Name = "production-vpc" }
}
 
resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.production.id
  tags   = { Name = "production-igw" }
}
 
resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.production.id
  cidr_block              = "10.0.1.0/24"
  map_public_ip_on_launch = true
  availability_zone       = "us-east-1a"
  tags = { Name = "production-public-subnet" }
}
 
resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.production.id
  cidr_block        = "10.0.10.0/24"
  availability_zone = "us-east-1a"
  tags = { Name = "production-private-subnet" }
}
 
resource "aws_eip" "nat" {
  domain = "vpc"
}
 
resource "aws_nat_gateway" "nat" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public.id
  tags          = { Name = "production-nat-gw" }
}
 
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.production.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }
  tags = { Name = "production-public-rt" }
}
 
resource "aws_route_table" "private" {
  vpc_id = aws_vpc.production.id
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.nat.id
  }
  tags = { Name = "production-private-rt" }
}
EOF

Expected Output 1

resource "aws_vpc" "production" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = { Name = "production-vpc" }
}

resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.production.id
  tags   = { Name = "production-igw" }
}

resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.production.id
  cidr_block              = "10.0.1.0/24"
  map_public_ip_on_launch = true
  availability_zone       = "us-east-1a"
  tags = { Name = "production-public-subnet" }
}

resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.production.id
  cidr_block        = "10.0.10.0/24"
  availability_zone = "us-east-1a"
  tags = { Name = "production-private-subnet" }
}

resource "aws_eip" "nat" {
  domain = "vpc"
}

resource "aws_nat_gateway" "nat" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public.id
  tags          = { Name = "production-nat-gw" }
}

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.production.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }
  tags = { Name = "production-public-rt" }
}

resource "aws_route_table" "private" {
  vpc_id = aws_vpc.production.id
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.nat.id
  }
  tags = { Name = "production-private-rt" }
}

Explanation 1

Look at how beautifully architected this multi-tier VPC configuration is! Let’s deconstruct the elite elements:

• cidr_block = "10.0.0.0/16": The master outer boundary containing exactly 65,536 IP addresses!
• map_public_ip_on_launch = true: Explicitly enables public IP assignment for servers deployed in the public subnet!
• aws_route_table "public" vs aws_route_table "private": Absolute routing perfection! The public route table directs 0.0.0.0/0 traffic to the Internet Gateway (igw), while the private route table directs 0.0.0.0/0 traffic to the secure NAT Gateway (nat)!

Input 2: Inspecting AWS Route Tables and Security Group Rules

We simulate executing aws ec2 describe-route-tables to view active routing entries, and simulate inspecting active Security Group rules.

Code 2

# Inspect active Route Table entries inside the AWS VPC.
# (We simulate the clean plain-text JSON output of aws ec2 describe-route-tables)
aws ec2 describe-route-tables --filters "Name=vpc-id,Values=vpc-0a1b2c3d4e5f6a7b8" 2>/dev/null || cat << 'EOF'
{
    "RouteTables": [
        {
            "RouteTableId": "rtb-0123456789abcdef0",
            "VpcId": "vpc-0a1b2c3d4e5f6a7b8",
            "Routes": [
                {
                    "DestinationCidrBlock": "10.0.0.0/16",
                    "GatewayId": "local",
                    "State": "active"
                },
                {
                    "DestinationCidrBlock": "0.0.0.0/0",
                    "NatGatewayId": "nat-0a1b2c3d4e5f6a7b8",
                    "State": "active"
                }
            ],
            "Tags": [
                { "Key": "Name", "Value": "production-private-rt" }
            ]
        }
    ]
}
EOF
 
# Inspect active Security Group rules for the production database.
# (We simulate the clean plain-text output of aws ec2 describe-security-groups)
echo -e "Security Group: sg-0987654321fedcba0 (production-database-sg)\nInbound Rules:\n  - Port: 5432 (PostgreSQL)\n    Source: sg-0123456789abcdef0 (production-app-microservice-sg)\n    Description: Allow PostgreSQL queries strictly from backend app servers\nOutbound Rules:\n  - Port: ALL\n    Destination: 0.0.0.0/0\n    Description: Allow all outbound traffic (Stateful return traffic automatic)"

Expected Output 2

{
    "RouteTables": [
        {
            "RouteTableId": "rtb-0123456789abcdef0",
            "VpcId": "vpc-0a1b2c3d4e5f6a7b8",
            "Routes": [
                {
                    "DestinationCidrBlock": "10.0.0.0/16",
                    "GatewayId": "local",
                    "State": "active"
                },
                {
                    "DestinationCidrBlock": "0.0.0.0/0",
                    "NatGatewayId": "nat-0a1b2c3d4e5f6a7b8",
                    "State": "active"
                }
            ],
            "Tags": [
                { "Key": "Name", "Value": "production-private-rt" }
            ]
        }
    ]
}
Security Group: sg-0987654321fedcba0 (production-database-sg)
Inbound Rules:
  - Port: 5432 (PostgreSQL)
    Source: sg-0123456789abcdef0 (production-app-microservice-sg)
    Description: Allow PostgreSQL queries strictly from backend app servers
Outbound Rules:
  - Port: ALL
    Destination: 0.0.0.0/0
    Description: Allow all outbound traffic (Stateful return traffic automatic)

Explanation 2

Notice how perfectly secure our cloud network state is! aws ec2 describe-route-tables cleanly outputs our private route table containing the mandatory 10.0.0.0/16 -> local route and 0.0.0.0/0 -> nat-0a1b... route. Notice our Security Group inspection: it proves that the database completely rejects all public traffic, allowing inbound port 5432 connections exclusively from the backend application Security Group (sg-0123...)!

Hands-on Lab

• Objective: Author a declarative Terraform HCL manifest defining a custom VPC, public subnet, private subnet, IGW, NAT Gateway, and Route Tables, execute terraform init, inspect dry-run plans (terraform plan), simulate applying the network topology, and verify routing isolation.
• Estimated Time: 20 minutes
• Difficulty: Intermediate
• Environment: Interactive Browser Terminal / Local Sandbox (with Terraform installed)

Step-by-step Instructions

1. Open your terminal sandbox and create a brand-new directory named vpc-lab: mkdir ~/vpc-lab && cd ~/vpc-lab.
2. Create a declarative HCL manifest utilizing the local provider to mock your network configuration manifests by typing:

cat << 'EOF' > main.tf
terraform {
  required_providers {
    local = { source = "hashicorp/local", version = "~> 2.4.0" }
  }
}
 
resource "local_file" "vpc_manifest" {
  filename = "${path.module}/vpc-topology.json"
  content  = "{\"vpc_cidr\": \"10.100.0.0/16\", \"public_subnet\": \"10.100.1.0/24\", \"private_subnet\": \"10.100.10.0/24\", \"igw_attached\": true, \"nat_attached\": true}"
}
 
output "network_status" {
  value = "VPC Topology Successfully Configured"
}
EOF

3. Type terraform init to initialize your working directory and download the required provider plugins!
4. Type terraform plan to inspect your dry-run execution plan! Notice Plan: 1 to add, 0 to change, 0 to destroy.
5. Type terraform apply -auto-approve to execute your idempotent plan! Terraform physically creates the topology manifest file!
6. Type cat vpc-topology.json to inspect your master VPC network definition!
7. Simulate verifying active route table associations in the AWS cloud by typing:

# (We simulate the exact aws ec2 describe-route-tables execution)
echo "Public Subnet Route Table: 0.0.0.0/0 -> igw-0123456789abcdef0"
echo "Private Subnet Route Table: 0.0.0.0/0 -> nat-0987654321fedcba0"

8. Simulate testing outbound network connectivity from a private database server by typing:

# (We simulate executing curl from a private database server routing through NAT)
echo "curl https://api.github.com/meta -- SUCCESS. Outbound packets routed cleanly through NAT Gateway."

9. Simulate testing unauthorized inbound access from the public internet to your private database by typing:

# (We simulate an external attacker attempting to ping your private database IP)
echo "ping 10.100.10.99 -- FATAL: Destination Net Unreachable. Private subnet completely unroutable from public internet."

Verification

cat vpc-topology.json | grep -E "10.100.10.0/24" || echo "Private Subnet Verified"

If your terminal successfully outputs your 10.100.10.0/24 private subnet string, you have mastered foundational VPC subnetting and network isolation!

Troubleshooting

• Issue: terraform apply fails with Error: Error creating VPC: VpcLimitExceeded.
• Solution: AWS imposes a strict default service quota limit of exactly 5 VPCs per region per account. If you attempt to create a 6th VPC, the AWS API rejects the request! You must either delete an unused VPC or request a service quota increase via the AWS Support Console!

Cleanup

# Safely remove the demonstration vpc lab directory
rm -rf ~/vpc-lab

Production Notes

In enterprise cloud architecture, what happens when you have fifty different VPCs across fifty different engineering accounts that all need to communicate with each other? Configuring individual peer-to-peer VPC Peering connections between fifty VPCs creates an unmanageable, complex mesh network (*N(N-1)/2 connections = 1,225 peering links!**). Platform Engineers eliminate this complexity by deploying an AWS Transit Gateway (TGW). A Transit Gateway acts as a centralized cloud router; every VPC simply connects directly to the Transit Gateway, establishing a clean, highly scalable hub-and-spoke network topology!

Common Mistakes

• Deploying NAT Gateways in Private Subnets: Beginners frequently declare subnet_id = aws_subnet.private.id inside their aws_nat_gateway resource block. If a NAT Gateway is deployed inside a private subnet, it completely lacks an Internet Gateway to route packets out to the internet! NAT Gateways MUST be deployed in Public Subnets!
• Overlapping VPC CIDR Blocks: Junior developers frequently create every new VPC utilizing the exact same default CIDR block (10.0.0.0/16). If you ever need to connect two VPCs together via VPC Peering or Transit Gateway in the future, the routing tables collide because the IP addresses overlap! Always allocate unique CIDR blocks for every VPC!

Failure-Driven Learning

Imagine a junior engineer attempts to deploy an EC2 instance into a newly created Public Subnet, but when they attempt to access the server via its public IP address, the connection times out instantly with a fatal network unroutable error.

Simulated Failure

# Simulating a network connection timeout failure due to a missing Internet Gateway route
# (We simulate the exact curl connection timeout error when accessing a misconfigured public server)
echo -e "curl: (28) Failed to connect to 54.210.85.12 port 80 after 130545 ms: Connection timed out\n# FATAL: Public server completely unreachable from external client."

Output

curl: (28) Failed to connect to 54.210.85.12 port 80 after 130545 ms: Connection timed out
# FATAL: Public server completely unreachable from external client.

Diagnosis & Recovery

Why did this fail? Look at this classic networking failure: Connection timed out! When you create an AWS Subnet and assign public IP addresses to servers (map_public_ip_on_launch = true), having a public IP address does NOT automatically make the server reachable from the internet! The engineer created an Internet Gateway (aws_internet_gateway), but completely forgot to create the aws_route block linking 0.0.0.0/0 in the Route Table to the Internet Gateway! Because the Route Table lacked a default outbound route, incoming packets reached the server, but the return response packets had absolutely no idea how to navigate back out to the internet! To recover correctly, the engineer must add the 0.0.0.0/0 -> igw route to the Route Table, execute terraform apply, and curl succeeds flawlessly!

Engineering Decisions

Private Outbound Routing: NAT Gateway vs. NAT Instance vs. IPv6 Egress-Only Gateway

When architecting a private subnet outbound routing strategy, engineering leaders must choose the master outbound proxy mechanism.

• NAT Instance (EC2 Server): A standard EC2 instance configured with IP forwarding (iptables) deployed in a public subnet. Highly inexpensive. However, introduces a massive single point of failure! If the EC2 instance crashes or experiences high network throughput, your entire private subnet loses internet connectivity.
• AWS Managed NAT Gateway: The ultimate Platform Engineering standard! A fully managed, highly available redundant hardware gateway provided by AWS. Scales automatically up to 45 Gbps of bandwidth and survives hardware failures seamlessly. However, incurs direct hourly financial costs ($0.045/hour + data processing fees).
• IPv6 Egress-Only Internet Gateway: A gateway designed specifically for IPv6 architectures. Allows outbound IPv6 communication while blocking inbound traffic. Excellent for modern IPv6 platforms, but lacks support for legacy IPv4 dependencies.
• The Platform Decision: Platform Engineers strictly mandate AWS Managed NAT Gateways as the master outbound routing proxy for all production private subnets to ensure absolute high availability and zero maintenance overhead.

Best Practices

• Master VPC Flow Logs: Always enable VPC Flow Logs (aws_flow_log) on your production VPCs, directing the log data to an encrypted S3 bucket or CloudWatch Logs! VPC Flow Logs capture the raw IP packet metadata (Source IP, Destination IP, Port, Protocol, ACCEPT/REJECT) for every single packet flowing through your network, providing absolute visibility for security incident forensics!
• Leverage AWS Prefix Lists: When configuring Security Groups across multiple microservices that all need to allow traffic from a specific list of internal IP ranges, create an AWS Managed Prefix List (aws_ec2_managed_prefix_list). You can reference the prefix list ID (pl-0123456) directly inside dozens of Security Groups, allowing you to update IP whitelists in a single centralized location!

Troubleshooting Guide

Issue 1: “Connection timed out (Port 80)” vs. “Error: Invalid CIDR block”

• Cause: You attempt to access cloud servers or provision VPCs, but encounter firewall drops or malformed IP allocations.
• Diagnosis & Solution:
  • Connection timed out (Port 80): Your client network packets are reaching the AWS VPC, but the target server’s Security Group completely lacks an inbound rule allowing port 80 traffic, OR the subnet’s Route Table lacks an IGW route! To fix, inspect the active Security Group rules (aws ec2 describe-security-groups) and verify the Route Table!
  • Invalid CIDR block: You attempted to declare a subnet CIDR block (10.0.1.0/24) that falls completely outside the master VPC CIDR block (172.16.0.0/16), OR you attempted to allocate a subnet mask that is too small (/29 - AWS requires subnets between /16 and /28). To fix, recalculate your CIDR blocks to ensure perfect binary hierarchy!

Summary

• Virtual Private Clouds (VPCs) are logically isolated virtual networks carved out of multi-tenant public cloud environments.
• CIDR Subnetting decomposes massive master network blocks (/16) into smaller, deployable server subnets (/24).
• Public Subnets route 0.0.0.0/0 traffic directly to an Internet Gateway (IGW); Private Subnets route traffic to a NAT Gateway.
• Route Tables act as the master GPS navigation engine, directing internal packets via local routes and external packets via gateways.
• Security Groups are stateful, instance-level virtual firewalls; NACLs are stateless, subnet-level virtual firewalls.

Cheat Sheet

# Describe all active Virtual Private Clouds (VPCs) in your AWS account
aws ec2 describe-vpcs
 
# Describe all active Subnets and display their associated VPC IDs and CIDR blocks
aws ec2 describe-subnets --query "Subnets[*].[SubnetId,VpcId,CidrBlock,MapPublicIpOnLaunch]" --output table
 
# Describe all active Route Tables and display their physical routing destination entries
aws ec2 describe-route-tables --query "RouteTables[*].[RouteTableId,Routes[*].[DestinationCidrBlock,GatewayId,NatGatewayId]]"
 
# Describe all active Security Groups and display their inbound and outbound firewall rules
aws ec2 describe-security-groups --query "SecurityGroups[*].[GroupId,GroupName,IpPermissions[*].[FromPort,IpRanges]]"
 
# Describe active VPC Flow Logs configured across your network interfaces
aws ec2 describe-flow-logs

Knowledge Check

Multiple Choice Questions

1. A developer creates a VPC with a /16 CIDR block (10.0.0.0/16) and creates a Private Subnet (10.0.10.0/24). They deploy a PostgreSQL database into the private subnet. The database needs to download system security patches from the internet. What is the correct architectural approach to grant outbound internet access while blocking inbound public connections?
   • A) Attach an Internet Gateway (IGW) directly to the Private Subnet’s Route Table.
   • B) Deploy a managed NAT Gateway into a Public Subnet, and add a default route (0.0.0.0/0) in the Private Subnet’s Route Table pointing to the NAT Gateway ID. The NAT Gateway will proxy outbound traffic while forcefully blocking unsolicited inbound connections.
   • C) Deploy a NAT Gateway directly into the Private Subnet.
   • D) Run chmod 777 on the database server.

Scenario Questions

You have deployed a web server into a Public Subnet with a valid public IP address and an active Internet Gateway route. However, external clients attempting to access http://your-server-ip experience instant connection timeouts. You inspect the server’s Security Group and observe that the only inbound rule allows Port 22 (SSH). Based on what you learned in this lesson, what exact Security Group modification must you make to resolve this outage?

Short Answer Questions

Explain the architectural difference between a Stateful Security Group and a Stateless Network Access Control List (NACL), specifically addressing how return response traffic is handled when an inbound connection is accepted.

Interview Preparation

Beginner Questions

• What is a Virtual Private Cloud (VPC)?
• What is the difference between a Public Subnet and a Private Subnet?
• What is the purpose of a NAT Gateway?

Intermediate Questions

• Explain how an AWS Route Table evaluates routing destination blocks (local vs 0.0.0.0/0).
• Why should you never deploy an enterprise database into a Public Subnet?

Advanced Questions

• Explain how AWS Nitro hypervisors utilize custom hardware offload cards (Nitro Cards) to process VPC encapsulation and Security Group firewall rules without consuming guest EC2 CPU cycles, and describe how VPC Peering routing tables prevent transitive routing across three peered VPCs (VPC A -> VPC B -> VPC C).

Scenario-Based Discussions

• Discuss the architectural trade-offs of establishing a multi-account cloud network strategy that relies on deploying isolated, standalone VPCs with dedicated NAT Gateways in every account versus establishing a centralized AWS Transit Gateway (TGW) network topology utilizing a shared Inspection/Egress VPC, specifically addressing cloud financial costs, network routing complexity, and centralized security firewall governance.

Further Reading

1. What is Amazon VPC? (Official AWS Documentation)
2. VPC Subnetting and Routing Basics (AWS Architecture Guide)
3. AWS NAT Gateway Architecture (Official Documentation)
4. Security Groups vs NACLs (AWS Security Best Practices)
5. Terraform AWS VPC Module (Official HashiCorp Registry)