IPv6 addresses assigned inside an AWS VPC are globally routable. How do you give IPv6 instances outbound internet access while keeping them unreachable from the internet, and why is a NAT gateway not the answer?

## The premise candidates get wrong In a VPC, the IPv6 addresses AWS assigns are from a globally routable range. There is no private-versus-public split the way there is for IPv4 with RFC 1918 space. So an instance with an IPv6 address and a route to an internet gateway is genuinely reachable from the internet — subject to its own firewalling, but reachable at the routing layer, with no address translation standing in between. That changes what "private subnet" means for IPv6. For IPv4 the address itself was part of the protection; for IPv6 the protection has to come from routing and from explicit rules. ## The device: egress-only internet gateway An **egress-only internet gateway** is a VPC-attached, horizontally scaled, highly available component — architecturally much closer to an internet gateway than to a NAT gateway. It differs from the internet gateway in exactly one respect: it is **stateful and one-way**. Connections established from inside the VPC are allowed out and their replies come back; packets from the internet that do not correspond to an existing outbound flow are dropped. You create one per VPC and reference it as a route target for `::/0`: ``` aws ec2 create-egress-only-internet-gateway --vpc-id vpc-0123456789abcdef0 aws ec2 create-route \ --route-table-id rtb-0123456789abcdef0 \ --destination-ipv6-cidr-block ::/0 \ --egress-only-internet-gateway-id eigw-0123456789abcdef0 ``` A subnet can perfectly well have a `0.0.0.0/0` route to a NAT gateway for IPv4 and a `::/0` route to an egress-only internet gateway for IPv6 at the same time — that dual-stack arrangement is the normal shape of a private subnet that speaks both protocols. ## Why not just use NAT Because NAT is a workaround for IPv4 address exhaustion. Its purpose is to let many hosts share one scarce public address, and the outbound-only property everyone values is a *side effect* of the translation state, not its goal. With IPv6 there is no scarcity, so translating would mean paying an hourly charge and a per-GB data-processing charge, adding a stateful translator to the path, and losing per-instance address visibility — all to obtain a property you can have for free. The egress-only internet gateway gives you that property directly. The gateway itself carries no hourly or data-processing charge, so its cost profile is that of the plain internet gateway rather than the NAT gateway. And because there is no translation, logs and remote-side records still show which instance made a call, which is a genuine operational and forensic advantage. ## Where a NAT gateway does meet IPv6: NAT64 One exception is worth knowing. A NAT gateway supports **NAT64**, used with **DNS64** on the Route 53 Resolver, so instances in **IPv6-only** subnets can reach **IPv4-only** destinations. DNS64 synthesises an IPv6 address inside the well-known `64:ff9b::/96` prefix for a name that only has an `A` record, the subnet routes that prefix to the NAT gateway, and the gateway translates the flow onto IPv4 on the far side. Notice this is the opposite problem. It is not "how do I keep IPv6 hosts unreachable" but "how does an IPv6-only host talk to a service that never got an IPv6 address". Muddling the two is the classic confusion here, and a candidate who can separate them cleanly is demonstrating a real grip on dual-stack design. ## What still has to be configured The egress-only internet gateway is a routing device, not a policy device. Instance-level and subnet-level rules still have to permit the IPv6 traffic explicitly — and this is a frequent operational surprise, because rules written years ago for IPv4 ranges say nothing about IPv6, so a newly dual-stacked workload can end up with an unintentionally open or unintentionally closed IPv6 path while the IPv4 path behaves as expected. Adding IPv6 to a VPC is therefore a review of every existing rule set, not just a routing change. ## How to answer Name the device, give the route (`::/0` to the egress-only internet gateway), and explain the *reason* NAT does not belong: IPv6 has no address scarcity, so translation buys nothing and costs money. If you have room, add the NAT64 exception to show you know where the two worlds do meet, and note that the rule sets still need explicit IPv6 entries.