12.1 VPC Core Architecture, Subnetting & High Availability NAT
Key Takeaways
- Amazon VPC supports IPv4 CIDR blocks between /16 and /28, permanently reserving exactly five IP addresses per subnet: the first four addresses (network, VPC router, Amazon DNS, and one held for future AWS use) plus the last address in the block (broadcast).
- Subnet tiering separates workloads into Public (route to Internet Gateway), Private (route to NAT Gateway), and Isolated (local route only, no internet egress).
- NAT Gateway is an Availability Zone-scoped managed resource; deploying one NAT Gateway per AZ in multi-AZ public subnets eliminates cross-AZ single points of failure and prevents inter-AZ data transfer fees ($0.01/GB).
- Dual-stack VPCs support IPv6 with an AWS-allocated /56 CIDR and /64 subnets, utilizing stateful Egress-Only Internet Gateways (EIGW) to permit outbound internet access while blocking inbound internet connections.
- Route tables evaluate rules using longest prefix match; the default local route is immutable, and routes to Virtual Private Gateways support dynamic BGP route propagation.
12.1 VPC Core Architecture, Subnetting & High Availability NAT
CloudOps Blueprint Focus: The AWS Certified CloudOps Engineer – Associate (SOA-C03) exam tests core VPC networking skills. You must master CIDR sizing, the five reserved IP addresses per subnet, subnet tiering, route table propagation, resilient multi-AZ NAT Gateway design, and IPv6 egress architectures.
Amazon VPC Foundations: CIDR Allocation & Reserved IP Addresses
An Amazon Virtual Private Cloud (VPC) provides a logically isolated virtual network for your AWS workloads. When creating a VPC, you specify an IPv4 Classless Inter-Domain Routing (CIDR) block within defined sizing limits:
- The smallest permitted IPv4 CIDR block is /28 (16 total IP addresses).
- The largest permitted IPv4 CIDR block is /16 (65,536 total IP addresses).
VPCs commonly utilize private address spaces defined in RFC 1918 (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16). When an active VPC exhausts its address space, you can associate Secondary CIDR Blocks from RFC 1918, Carrier-Grade NAT (CGNAT) space (100.64.0.0/10), or customer-owned public ranges. Secondary CIDRs cannot overlap with any existing CIDR blocks in the VPC or peered VPCs.
The Five Mandatory AWS Reserved IP Addresses
In on-premises networks, only two addresses per subnet are unusable: the network wire address and the broadcast address. In Amazon VPC, AWS reserves exactly five IP addresses in every subnet across all CIDR block sizes:
| Subnet Offset | Example (10.0.1.0/24) | Reserved Purpose |
|---|---|---|
First (.0) | 10.0.1.0 | Network Address: Defines the network boundary. |
Second (.1) | 10.0.1.1 | VPC Router (Default Gateway): Internal router interface. |
Third (.2) | 10.0.1.2 | AmazonProvidedDNS: Route 53 Resolver (VPC CIDR base + 2). |
Fourth (.3) | 10.0.1.3 | Reserved by AWS: Allocated for future AWS infrastructure use. |
Last (.255) | 10.0.1.255 | Network Broadcast Address: Reserved; broadcast is unsupported in VPC. |
Usable host capacity is determined by:
A /24 subnet ($2^8 = 256$ total) yields $256 - 5 = 251$ usable IP addresses. A /28 subnet ($2^4 = 16$ total) yields only $16 - 5 = 11$ usable addresses.
Subnet Architecture & Routing Tiering
A subnet spans a single Availability Zone (AZ). Multi-AZ resilience requires deploying subnets across at least two AZs. CloudOps architectures enforce a three-tier subnet model:
- Public Subnets: The associated route table includes a default route (
0.0.0.0/0) targeting an Internet Gateway (IGW) (igw-xxxx). Instances require public IPv4 addresses (via auto-assign public IPv4 or Elastic IPs) to communicate with the internet. - Private Subnets: The route table directs
0.0.0.0/0to a NAT Gateway (nat-xxxx) residing in a public subnet. Private instances initiate outbound requests (e.g., software patches) while blocking inbound internet traffic. - Isolated (Database) Subnets: The route table contains no route to
0.0.0.0/0. Only the defaultlocalroute and internal routes (VPC endpoints, peering) exist, completely walling off backend databases from internet egress.
Route Table Mechanics & Route Propagation
Every route table contains a default local route for the VPC CIDR (e.g., 10.0.0.0/16 $\rightarrow$ local). This local route is immutable: it cannot be deleted or overridden. Routing decisions always follow the longest prefix match rule.
When connecting a VPC to an on-premises network via AWS Site-to-Site VPN or AWS Direct Connect using a Virtual Private Gateway (VGW), enabling Route Propagation automatically populates the route table with Border Gateway Protocol (BGP) advertised prefixes, avoiding manual static route maintenance.
High Availability NAT Gateway Design
An AWS NAT Gateway is an AZ-scoped managed service scaling automatically up to 45 Gbps. While highly available within an AZ, it does not span across zones.
Single NAT Gateway vs. Multi-AZ Pattern
Deploying a single NAT Gateway in one AZ (e.g., us-east-1a) for the entire VPC introduces severe risks:
- Single Point of Failure (SPOF): If
us-east-1afails, private subnets in all other AZs lose internet egress immediately. - Cross-AZ Data Transfer Costs: Traffic from private subnets in
us-east-1brouting throughus-east-1aincurs inter-AZ data transfer fees ($0.01/GB each direction = $0.02/GB round-trip) in addition to NAT data processing fees ($0.045/GB).
| Architecture | Failure Resilience | Cost Profile | Operational Suitability |
|---|---|---|---|
| Single NAT Gateway | Vulnerable; AZ outage severs all VPC internet egress. | Incurs inter-AZ data transfer fees ($0.01/GB). | Development / non-critical environments. |
| Multi-AZ NAT (1 per AZ) | Resilient; AZ failure isolated to affected zone. | Zero inter-AZ transfer; hourly charge per NAT GW. | Production standard (Well-Architected). |
The production standard requires deploying one NAT Gateway per AZ in public subnets with an Elastic IP, and configuring dedicated private route tables in each AZ routing 0.0.0.0/0 to the local zone's NAT Gateway.
IPv6 Architecture & Egress-Only Internet Gateways
To resolve IPv4 address constraints, AWS supports dual-stack VPCs:
- IPv6 CIDR Allocation: AWS assigns a fixed, globally unique /56 IPv6 CIDR block.
- Subnet Allocation: Subnets receive a fixed /64 CIDR block ($2^{64}$ addresses).
- Public Routability: All assigned IPv6 addresses are globally unique and publicly routable. AWS does not support or use NAT for IPv6.
Egress-Only Internet Gateway (EIGW)
To protect private IPv6 workloads, AWS provides the Egress-Only Internet Gateway (EIGW):
- Enables instances in private subnets to initiate outbound IPv6 traffic to the internet.
- Prevents external internet hosts from initiating inbound IPv6 connections.
- Stateful: automatically allows return traffic for established outbound flows.
- Private subnet route tables direct default IPv6 traffic (
::/0) to the EIGW (eigw-xxxx).
A production workload runs across three Availability Zones (us-east-1a, us-east-1b, us-east-1c) within a Virtual Private Cloud (VPC). The workload consists of web servers in public subnets and backend worker nodes in private subnets that require internet access to pull third-party software updates. A single NAT Gateway is currently deployed in us-east-1a, and all private subnet route tables direct default traffic (0.0.0.0/0) to this NAT Gateway. During a regional availability event affecting us-east-1a, worker nodes in us-east-1b and us-east-1c lose all internet connectivity. Additionally, the monthly billing report shows high inter-AZ data transfer charges for NAT traffic. How should the CloudOps engineer re-architect the NAT topology to eliminate the single point of failure and minimize cross-AZ network costs?
A CloudOps team is provisioning a new multi-tier VPC to host microservices deployed on Amazon Elastic Kubernetes Service (EKS). The network engineer allocates a /24 IPv4 CIDR block (10.0.5.0/24) to a dedicated worker node subnet. The container orchestration team calculates that their application pods and node interfaces will require exactly 254 usable private IP addresses in this subnet. When attempting to launch the requested number of pods, several pods fail to initialize due to IP address exhaustion. How many IP addresses are actually available for host assignment in this subnet, and what accounts for the discrepancy?
A compliance-mandated microservice architecture requires all backend instances to communicate exclusively using IPv6 addresses. The instances reside in private subnets within a dual-stack VPC and must download operating system security patches from public repositories on the internet. However, compliance standards strictly forbid external hosts on the public internet from initiating inbound network connections to these private instances. Which VPC configuration fulfills these requirements without introducing network address translation?