VPC design, IPAM and IPv6 dual-stack: SAP-C03 study notes and practice questions
What to know about VPC design, IPAM and IPv6 dual-stack for the SAP-C03 exam, from the Architecture Design and Implementation Built for the Cloud domain (25% of the exam guide), then 1 free question to test it. Part of the SAP-C03 study guide.
SAP-C03 asks how to stop overlapping CIDRs across hundreds of accounts, how to lay out subnets for security and growth, and how to adopt IPv6 when IPv4 addresses run out or cost too much.
Subnet strategy and segmentation
Use tiers (public, private application, private data) across at least two or three AZs, sized for growth; you can add secondary CIDRs to a VPC later, but you can’t resize a subnet.
Keep only load balancers, NAT gateways and similar in public subnets.
Segment with security groups (stateful, reference other groups) and network ACLs (stateless, subnet level, allow and deny rules), and between VPCs with Transit Gateway route tables.
Use prefix lists to manage CIDR sets used in many route tables and security groups.
Plan for services that consume IPs heavily, such as EKS pods with the VPC CNI (prefix delegation or IPv6 helps).
Amazon VPC IPAM
Create a hierarchy of pools (top-level, Regional, then per environment or business unit) and allocate CIDRs to VPCs from them, so ranges never overlap.
Integrate with AWS Organizations and delegate IPAM to a networking account; share pools with AWS RAM.
IPAM monitors usage and flags non-compliant or overlapping CIDRs; allocation rules can require specific tags.
Manage public IPv4 and BYOIP ranges and Amazon-provided IPv6 ranges; public IPv4 addresses are charged hourly, which pushes IPv6 adoption.
IPv6 and dual-stack
Dual-stack: add an IPv6 CIDR (/56 per VPC, /64 per subnet) and run IPv4 and IPv6 side by side; update route tables, security groups and NACLs for IPv6 separately.
Egress-only internet gateway: outbound-only IPv6 internet access for private resources (IPv6 addresses are globally unique, so NAT isn’t used for IPv6).
IPv6-only subnets reach IPv4-only destinations through DNS64 (Resolver synthesizes AAAA records) plus NAT64 on a NAT gateway.
Load balancers, CloudFront and API Gateway can accept IPv6 clients in front of IPv4 backends, a common first step.
How to choose
Scenario wording
Choose
“Teams keep creating overlapping VPC CIDRs”
IPAM pools with Organizations integration
“Running out of private IPv4 for EKS pods”
IPv6 (or prefix delegation, secondary CIDRs)
“Private IPv6 instances need outbound internet only”
Egress-only internet gateway
“IPv6-only workloads must call an IPv4 API”
DNS64 with NAT64
“Reach IPv6 users without changing the backend”
Dual-stack load balancer or CloudFront
“Block one malicious IP range at the subnet”
Network ACL deny rule
Common traps
A NAT gateway for IPv6 egress instead of an egress-only internet gateway.
Security groups for explicit denies; they support allow rules only.
Forgetting IPv6 rules in security groups and NACLs after adding IPv6.
Spreadsheets for IP planning at organization scale.
Undersized subnets that can’t hold scaling, pods or endpoints.
A retailer runs its Amazon EKS clusters in three VPCs. Its IPv4 address space is nearly used up, and every new pod consumes an address, so the platform team cannot add capacity.
The pods call partner APIs on the internet, some reachable only over IPv4 and some only over IPv6. A legacy order service in one of the VPCs supports only IPv4 and will not change for at least a year.
No backend service may accept inbound connections from the internet, and the retailer wants to keep its NAT gateway spending to a minimum.
Which solution meets these requirements?
Choose one answer.
AA. Enable IPv6 on each VPC and send all outbound IPv6 traffic, including calls to the IPv6-only partner APIs, through the existing NAT gateways.
BB. Add a secondary IPv4 CIDR range to each VPC for new subnets, put the new pods in those public subnets with public IPv4 addresses, and route the subnets to an internet gateway for their outbound partner calls.
CC. Migrate the clusters to IPv6-only subnets, remove IPv4 from all three VPCs, and reach the IPv4 partner APIs through NAT64 and DNS64 on the NAT gateways.
DD. Create dual-stack subnets for the pods, route outbound IPv6 through an egress-only internet gateway, keep IPv4 outbound through the existing NAT gateways, and add no inbound internet routes.
Show the answer and explanation
Answer: D
A. Wrong: A NAT gateway translates IPv6 traffic only toward IPv4 destinations, through NAT64 with DNS64. It cannot carry traffic to IPv6-only partner APIs, and sending more traffic through NAT gateways raises the processing charges the retailer wants to keep down.
B. Wrong: Public addressing makes the pods reachable from the internet, which the backend services must not allow. A secondary range also adds only a fixed block of addresses, so the shortage returns as the clusters grow.
C. Wrong: IPv6-only subnets with NAT64 can reach IPv4 partners, but removing IPv4 from the VPCs breaks the legacy order service. That service supports only IPv4 and cannot change this year.
D. Right: Correct. Dual-stack subnets give the pods IPv6 addresses that do not run out, and an egress-only internet gateway allows outbound-only IPv6 traffic. IPv4 keeps working through the existing NAT gateways, and no inbound internet route is added.
Explanation
Dual-stack subnets give the pods IPv6 addresses with no shortage, an egress-only internet gateway keeps IPv6 traffic outbound-only without NAT processing charges, and IPv4 stays available for the legacy service. NAT gateways cannot reach IPv6-only destinations, public subnets allow inbound access, and IPv6-only VPCs break the legacy service.
Want more on VPC design, IPAM and IPv6 dual-stack? The 5 full-length practice sets have 5 more VPC design, IPAM and IPv6 dual-stack questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →