VPC Advanced Networking — CIDR, ENI, Prefix Lists & IPv6
VPC advanced topics appear in 134 ANS-C01 questions. Beyond basic VPC setup, the exam tests secondary CIDRs, ENI management, managed prefix lists, IPv6 dual-stack, BYOIP, and VPC endpoint policies.
Non-overlapping requirement
RFC 1918 + public ranges
100.64.0.0/10 (shared)
Move between instances (failover)
Secondary private IPs
Different SGs per ENI
Reuse across SGs/routes
AWS-managed (CloudFront, S3)
Share via RAM
Egress-only IGW (outbound only)
NAT64 + DNS64
Dual-stack subnets
Secondary CIDRs
- Why: VPC runs out of IP addresses, need to expand without recreating
- Add: Up to 5 IPv4 CIDR blocks per VPC (original + 4 secondary)
- Rules: Cannot overlap with existing CIDRs or peered VPC CIDRs. Can be from different RFC 1918 ranges.
- 100.64.0.0/10: Shared address space — useful when RFC 1918 ranges exhausted across organization
- Exam pattern: “VPC running out of IPs” → add secondary CIDR + new subnets in that range
ENI — Advanced Patterns
| Pattern | How | Use Case |
|---|---|---|
| Dual-homed instance | ENI in public subnet + ENI in private subnet | Management interface separate from data interface |
| Failover | Detach ENI from failed instance → attach to standby | IP address moves with ENI (no DNS/client changes) |
| Multiple SGs | Different security groups per ENI on same instance | Different access rules for management vs application traffic |
| Secondary IPs | Multiple private IPs on one ENI | Hosting multiple SSL sites, container networking |
Managed Prefix Lists
- What: Named set of CIDR blocks that can be referenced in security groups and route tables
- AWS-managed: com.amazonaws.region.s3 (S3 IPs), com.amazonaws.global.cloudfront.origin-facing (CloudFront IPs)
- Customer-managed: Create your own (e.g., corporate office IPs, partner networks)
- Sharing: Share via RAM across accounts — update once, all accounts get updated rules
- SG reference: Instead of listing 50 IPs in a SG rule, reference a prefix list (single entry)
- Route table: Use prefix list as destination in route table entries
IPv6 in AWS
| Feature | IPv4 | IPv6 |
|---|---|---|
| Address type | Private (RFC 1918) + optional public (EIP) | All globally unique (public), no NAT needed |
| Outbound-only | NAT Gateway | Egress-Only Internet Gateway (outbound, blocks inbound) |
| Dual-stack | — | Subnets have both IPv4 + IPv6 CIDRs |
| IPv4-only services | — | NAT64 + DNS64 allows IPv6 instances to reach IPv4 endpoints |
- Egress-Only IGW: Like NAT for IPv6 — allows outbound connections, blocks unsolicited inbound. Free.
- NAT64: Translates IPv6 packets to IPv4 for reaching IPv4-only destinations. Configured on NAT Gateway.
- DNS64: Route 53 Resolver synthesizes AAAA records for IPv4-only domains (so IPv6 clients can reach them).
BYOIP (Bring Your Own IP)
- What: Use your own public IPv4/IPv6 address ranges in AWS (instead of AWS-provided)
- Why: IP reputation, allowlisting by partners, regulatory requirements
- Requirements: /24 minimum (IPv4), must own the range (RIR registration), create ROA (Route Origin Authorization)
- Use with: EIPs, EC2, NLB, Global Accelerator
Exam Tips
| Exam | Key Points |
|---|---|
| ANS-C01 | “VPC out of IPs” → secondary CIDR. “Move IP on failover” → ENI detach/attach. “Restrict SG to CloudFront only” → AWS-managed prefix list. “IPv6 outbound only” → Egress-Only IGW. “IPv6 instance reach IPv4 service” → NAT64 + DNS64. “Share IP list across accounts” → Prefix list + RAM. “Use own public IPs” → BYOIP. |
AWS Certification Exam Practice Questions
Question 1:
A VPC with CIDR 10.0.0.0/16 has exhausted all available IP addresses. The company needs more IPs without disrupting existing workloads or recreating the VPC. What should they do?
- Delete unused ENIs to free up IPs
- Add a secondary CIDR block (e.g., 10.1.0.0/16) to the VPC and create new subnets in that range
- Resize the VPC CIDR from /16 to /8
- Create a new VPC and peer it to the existing one
Show Answer
Answer: B — You can add up to 4 secondary CIDR blocks to an existing VPC. Create new subnets in the secondary range. Existing workloads continue using original CIDRs — no disruption. VPC CIDRs cannot be resized (C is wrong). New VPC with peering (D) works but adds complexity and doesn’t extend the existing network seamlessly.
Question 2:
A company needs their ALB security group to only allow traffic from CloudFront. CloudFront has hundreds of IP ranges that change frequently. How should this be maintained without manual updates?
- Create a Lambda function that updates the SG every hour from the AWS IP ranges JSON file
- Reference the AWS-managed prefix list for CloudFront (com.amazonaws.global.cloudfront.origin-facing) in the security group rule
- Use WAF on the ALB to validate CloudFront headers instead of IP restriction
- Open the SG to 0.0.0.0/0 and rely on CloudFront custom headers for security
Show Answer
Answer: B — AWS-managed prefix lists are automatically updated by AWS when IP ranges change. Reference it in your SG rule — one entry covers all CloudFront IPs, always current. Lambda (A) works but is unnecessary complexity when the managed prefix list exists. Custom headers (C, D) are defense-in-depth but should complement IP restriction, not replace it.
Question 3:
A company is transitioning to IPv6. Their instances need to initiate outbound connections to the internet (software updates) but must NOT be reachable from the internet on IPv6. No NAT is desired. Which gateway provides this for IPv6?
- NAT Gateway configured for IPv6
- Egress-Only Internet Gateway — allows outbound IPv6 traffic, blocks unsolicited inbound
- Internet Gateway with restrictive security groups
- VPN Gateway with IPv6 routing
Show Answer
Answer: B — Egress-Only Internet Gateway is the IPv6 equivalent of NAT Gateway (for outbound-only). It allows instances to initiate connections to the internet but blocks unsolicited inbound connections. No address translation (all IPv6 is public). Free to use. Regular Internet Gateway (C) allows both directions — SGs help but the gateway itself doesn’t block inbound at the network level.
Related Posts
- VPC Connectivity Decision Guide
- Network Performance (ENA, Jumbo Frames)
- Direct Connect Deep Dive
- Network Firewall & Inspection
References
Frequently Asked Questions
When should I use secondary CIDRs vs a new VPC?
Secondary CIDR: When you need more IPs in the same logical network (same route tables, same security groups apply). Simpler. New VPC: When you need network isolation (different security domain, different team ownership). Secondary CIDRs keep everything in one VPC. New VPC + peering/TGW creates separate networks that must be explicitly connected.
What are managed prefix lists useful for?
Prefix lists simplify rule management. Instead of maintaining 50+ IP rules in multiple security groups across accounts, create one prefix list → reference it everywhere. When IPs change, update the prefix list once — all referencing SGs update automatically. AWS-managed lists (CloudFront, S3) are maintained by AWS automatically. Share your own lists via RAM across accounts.