IPv6 in Amazon VPC is not simply \u201cmore addresses.\u201d It changes how workloads are numbered, how internet egress is controlled, how IPv4-only dependencies are reached, how DNS answers influence path selection, and how security teams think about globally unique addresses. A VPC can be IPv4-only, dual-stack, or increasingly IPv6-oriented, but the design must account for the parts of the application and enterprise network that still depend on IPv4.<\/p>\n
The current AWS Certified Advanced Networking \u2013 Specialty (ANS-C01)<\/a> exam validates the ability to design and operate AWS and hybrid networks at scale. IPv6 addressing, routing, DNS, hybrid connectivity, and security all sit inside that skill set. Candidates should understand the operational differences between dual-stack and IPv6-only workloads, why egress-only internet gateways exist, and how DNS64\/NAT64 bridge IPv6 workloads to IPv4 services.<\/p>\n An IPv6-enabled VPC receives an IPv6 CIDR block that can be subdivided across subnets. Unlike private IPv4 addressing, IPv6 addresses are globally unique and do not require address translation merely to avoid overlap. That removes some pressure from RFC1918 planning, but it also means security cannot rely on the assumption that \u201cprivate\u201d addressing makes a host unreachable from the internet.<\/p>\n Dual-stack subnets allow resources to use both IPv4 and IPv6. This is often the least disruptive migration path because applications can reach legacy IPv4 systems while new traffic adopts IPv6 where supported. IPv6-only designs can reduce IPv4 dependence further, but they require a complete review of operating systems, load balancers, endpoints, DNS, monitoring agents, package repositories, and on-premises dependencies.<\/p>\n The migration concepts in IPv6 migration strategies<\/a> apply directly: the transition is an application and operations program, not a single network change. Inventory dependencies first, then choose where dual stack is necessary and where IPv6-only can be supported safely.<\/p>\n Address assignment strategy also matters for automation. Use IPAM or another governed allocation process so subnet prefixes are predictable and nonoverlapping across accounts and Regions. A well-structured IPv6 plan can encode environment or geography into allocation boundaries without embedding business meaning into individual host addresses. The objective is summarizable ownership, not manually memorable addresses.<\/p>\n IPv6 routes are distinct from IPv4 routes. A subnet can have an IPv4 default route to a NAT gateway and an IPv6 default route to an internet gateway or egress-only internet gateway. Engineers should verify the actual route table entries rather than assuming that enabling IPv6 on the subnet automatically creates the intended egress behavior.<\/p>\n Use route tables to express the application\u2019s trust model. Public IPv6 workloads that must receive inbound internet connections can route through an internet gateway when security groups and network ACLs permit it. Private outbound-only workloads can use an egress-only internet gateway. Hybrid IPv6 routes may point toward Transit Gateway, virtual private gateways, or other supported connectivity components depending on the architecture.<\/p>\n Route summarization and IP address management matter at scale. Allocate IPv6 ranges hierarchically so accounts, Regions, environments, and network domains can be summarized. Randomly assigning subnet prefixes may be easy initially but creates operational difficulty when route policies, logs, and security rules need to identify ownership later.<\/p>\n An egress-only internet gateway allows IPv6 resources to initiate outbound internet connections while preventing the internet from initiating new inbound IPv6 connections through that gateway. It provides a familiar \u201cprivate subnet egress\u201d behavior without translating IPv6 addresses. This is conceptually different from an IPv4 NAT gateway, which performs address translation as part of outbound access.<\/p>\n Do not treat an egress-only internet gateway as a firewall replacement. Security groups and network ACLs still govern allowed traffic, and application-layer controls still matter. The gateway controls initiation direction for internet connectivity; it does not inspect application payloads or decide whether the destination itself is trusted.<\/p>\n Because there is no translation, logs and downstream services can see the workload\u2019s IPv6 address. That can improve attribution but also requires log pipelines, SIEM systems, allowlists, and parsers to support IPv6 correctly. An architecture is not IPv6-ready if the network can carry IPv6 but operations tools silently truncate or misclassify the addresses.<\/p>\n NAT64 capacity should be tested like any other shared translation tier. Large outbound workloads can create connection or throughput patterns that are very different from a few test instances. Monitor NAT gateway metrics, failure signals, and data-processing cost so an IPv6 migration does not simply move an old IPv4 bottleneck into a translation service.<\/p>\n IPv6-only workloads eventually need to call an IPv4-only service. AWS supports NAT64 through NAT gateways and DNS64 through Route 53 Resolver. When DNS64 is enabled for a subnet and the queried destination has no IPv6 record, the resolver can synthesize an IPv6 address using the well-known 64:ff9b::\/96 prefix. Routing that synthesized prefix to a NAT gateway allows translation to the real IPv4 destination.<\/p>\n This design only works when DNS is part of the path. If an application uses a hard-coded IPv4 literal, DNS64 cannot synthesize a destination. Legacy configuration files, allowlists, license servers, or database connection strings may therefore block an IPv6-only migration even when the network infrastructure is configured correctly. Application dependency discovery is as important as route configuration.<\/p>\n Use the ideas in AAAA records and IPv6 DNS<\/a> to reason about native IPv6 versus synthesized answers. Prefer native IPv6 when the destination supports it; use NAT64 as a compatibility bridge rather than as a reason to postpone every downstream modernization decision indefinitely.<\/p>\n Dual-stack clients may receive both A and AAAA records. The operating system and application then choose which path to attempt according to their address-selection behavior. That means \u201cIPv6 is enabled\u201d does not guarantee that production traffic is actually using it. Measure the protocol used by clients rather than inferring adoption from DNS configuration.<\/p>\n When services expose both protocols, verify that health, firewall rules, and observability are equivalent. A broken IPv6 path can create delays if clients try IPv6 first and fall back to IPv4. Conversely, an IPv4-only monitoring probe can report a service healthy while IPv6 users fail. Test both address families explicitly during deployment.<\/p>\n The broader IPv4 and IPv6<\/a> comparison is important operationally: the protocols coexist, but they do not share every route, security rule, or failure mode. Treat dual stack as two active network paths that both require testing and monitoring.<\/p>\n Hybrid security devices must also understand IPv6 extension headers, neighbor discovery, ICMPv6, and the enterprise’s filtering expectations. Blocking ICMPv6 indiscriminately can break essential IPv6 functions. Security policy should distinguish required control traffic from unwanted exposure rather than copying IPv4 rules mechanically.<\/p>\n Multi-VPC and hybrid environments need an explicit IPv6 routing plan. Transit Gateway can carry IPv6 routes for supported attachments, and hybrid connections can advertise IPv6 prefixes where the service and virtual interface support them. The on-premises network must be prepared to route those prefixes and security devices must inspect IPv6 traffic with the same policy intent as IPv4.<\/p>\n Do not assume an IPv4 hybrid path automatically has an equivalent IPv6 path. BGP advertisements, prefix filters, firewalls, VPN configuration, Direct Connect virtual interfaces, and DNS forwarding may all need separate updates. A partially enabled design can create reachability that works only from some clients or only in one direction.<\/p>\n Address overlap is less likely with IPv6, but route ownership still matters. Use hierarchical prefixes and route-policy controls so a site cannot accidentally advertise a range that belongs to another account or Region. The absence of NAT makes route correctness and endpoint security more visible, not less important.<\/p>\n Load balancers and managed services should be reviewed one by one for dual-stack behavior. Some services can front IPv4 targets while exposing IPv6 to clients, which can simplify migration, while others require different endpoint or subnet settings. Use service documentation and test environments rather than assuming every AWS endpoint adopts IPv6 in the same way.<\/p>\n IPv6 addresses in a VPC are globally unique, but reachability still depends on route tables, gateways, security groups, and network ACLs. Security teams should stop using \u201cpublic IP\u201d as a synonym for \u201cinternet reachable\u201d and instead evaluate the full path. An instance can have a globally unique IPv6 address while remaining unreachable from the internet because there is no inbound route or security permission.<\/p>\n Audit every IPv4 security rule for an IPv6 equivalent where the policy should apply to both protocols. A service protected by restrictive IPv4 CIDRs can accidentally become broadly reachable over IPv6 if teams add ::\/0 without understanding the consequence. The reverse can also happen: security rules may be updated for IPv6 but monitoring or vulnerability scanners remain IPv4-only and miss the new path.<\/p>\nBegin with the address model, not the migration slogan<\/h3>\n
Plan IPv6 subnets and routing independently from IPv4<\/h3>\n
Use egress-only internet gateways for outbound-only IPv6<\/h3>\n
Use DNS64 and NAT64 for IPv4-only dependencies<\/h3>\n
Design DNS answers to control protocol preference<\/h3>\n
Extend IPv6 across Transit Gateway and hybrid networks carefully<\/h3>\n
Apply security controls to globally unique addresses<\/h3>\n