VPC Architecture and CIDR Blocks

An Amazon Virtual Private Cloud (VPC) is a logically isolated private network within an AWS Region that you define and control. Every AWS account comes with a default VPC (CIDR 172.31.0.0/16) in each Region, but production architectures always use custom VPCs. A VPC spans all Availability Zones in its Region and gives you full control over IP addressing, subnets, route tables, internet gateways, and security. Resources inside a VPC are isolated from other VPCs and from the internet unless you explicitly configure connectivity.

A CIDR (Classless Inter-Domain Routing) block defines the IP address range of a VPC or subnet using the format x.x.x.x/prefix. The prefix length determines how many IP addresses are in the range: /16 = 65,536 addresses, /24 = 256 addresses, /28 = 16 addresses (minimum subnet size on AWS). For VPCs, AWS allows CIDR blocks from /16 (largest) to /28 (smallest). Choose a VPC CIDR that: (1) does not overlap with on-premises networks (for future VPN/Direct Connect), (2) is large enough for your planned subnets, and (3) uses private RFC 1918 address space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

A subnet is a segment of a VPC's IP address range that lives in a single Availability Zone. Subnets are classified as public (has a route to an internet gateway) or private (no direct internet route). Best practice for a typical 3-tier architecture: create at least three subnet tiers—public (load balancers, bastion hosts), private-app (EC2 instances, ECS tasks), and private-data (RDS, ElastiCache)—and replicate each tier across at least two AZs for high availability.

A common CIDR design for a VPC with CIDR 10.0.0.0/16 across two AZs and three tiers: Public AZ-a: 10.0.1.0/24; Public AZ-b: 10.0.2.0/24; Private-App AZ-a: 10.0.10.0/24; Private-App AZ-b: 10.0.11.0/24; Private-Data AZ-a: 10.0.20.0/24; Private-Data AZ-b: 10.0.21.0/24. This layout leaves room to add AZ-c subnets (10.0.3.0/24, 10.0.12.0/24, 10.0.22.0/24) without re-planning the entire CIDR scheme. Always design with growth in mind.

AWS reserves the first four and last IP address in every subnet. For a 10.0.1.0/24 subnet: 10.0.1.0 (network), 10.0.1.1 (VPC router), 10.0.1.2 (DNS/DHCP), 10.0.1.3 (future use), and 10.0.1.255 (broadcast). A /24 subnet has 256 total IPs minus 5 reserved = 251 usable. A /28 subnet (the minimum) has 16 IPs minus 5 = 11 usable. This matters when sizing subnets for the number of resources (EC2 instances, Lambda functions with VPC, etc.) you plan to deploy.

You can add up to four secondary CIDR blocks to an existing VPC without re-creating it. This is useful when your primary CIDR is exhausted (all subnets full) or when you need to add address space from a different RFC 1918 range for a specific use case like Kubernetes pod networking. The secondary CIDRs are subject to certain restrictions—for example, you cannot add an overlapping CIDR, and certain non-RFC-1918 public ranges cannot be used. Plan VPC CIDR sizing carefully upfront to minimise the need for secondary CIDRs.

VPC Peering establishes a private network connection between two VPCs so their resources can communicate using private IP addresses. Peered VPCs can be in the same account, different accounts, or even different Regions (inter-region peering). Requirements: the CIDRs of the two VPCs must not overlap. Limitations: peering is non-transitive—if VPC-A peers with VPC-B and VPC-B peers with VPC-C, VPC-A cannot communicate with VPC-C through VPC-B. For full mesh connectivity across many VPCs, use AWS Transit Gateway instead.

AWS Transit Gateway (TGW) acts as a central network hub—a cloud router—that connects multiple VPCs, VPNs, and Direct Connect connections. Instead of creating N*(N-1)/2 VPC peering connections for a full mesh of N VPCs, you attach each VPC and connection to the Transit Gateway, which routes traffic between them. TGW supports route tables that let you control which attachments can communicate with each other, enabling network segmentation (e.g., isolate production VPCs from dev VPCs on the same TGW).

Two DNS settings control name resolution in a VPC. enableDnsSupport: when true (default), the VPC uses the AWS-provided DNS resolver at 169.254.169.253 or the second IP of the VPC CIDR (e.g., 10.0.0.2 for 10.0.0.0/16). enableDnsHostnames: when true (must be enabled for custom VPCs, default on for the default VPC), EC2 instances in the VPC receive DNS hostnames like ip-10-0-1-15.ec2.internal. Both must be enabled for Route 53 Private Hosted Zones to work within the VPC.

VPC Flow Logs capture metadata about network traffic flowing through your VPC—source and destination IP, port, protocol, bytes transferred, and whether the traffic was accepted or rejected. Flow logs can be published to CloudWatch Logs (for querying with Logs Insights) or S3 (for analysis with Athena). They are invaluable for security forensics (who connected to what), traffic analysis (identify high-bandwidth flows), and troubleshooting (why was a connection rejected?). Flow logs operate at the VPC, subnet, or individual ENI level.

Before creating a VPC, plan for all future connectivity needs: On-premises connectivity (VPN or Direct Connect)—ensure VPC CIDR does not overlap with on-premises subnets; Cross-VPC connectivity (peering or Transit Gateway)—plan non-overlapping CIDRs across all VPCs in your organisation; AWS service access (VPC endpoints for S3, DynamoDB, SSM to avoid traffic going through the internet); and subnet sizing—leave headroom in each subnet for IP address consumption from EKS pods, Lambda functions, and Elastic Network Interfaces.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: a VPC is a logically isolated network in a Region, defined by a CIDR block that you divide into public and private subnets across AZs, AWS reserves 5 IPs in every subnet so always size subnets with this reduction in mind, and VPC Peering and Transit Gateway connect VPCs privately, but CIDR ranges must not overlap. Next up we explore Internet Gateways and Route Tables.