I have a dual-stack EC2 instance hosting web apps, with DNS pointing directly to it. SSH and Git access already work over IPv6, but some clients, webhooks, APIs and SMTP services still need IPv4.
Could CloudFront handle inbound traffic while a NAT gateway handles outbound IPv4 access? I would like to remove the instance's paid public IPv4, ideally without adding a lot of cost or complexity.
For one small instance, keeping the public IPv4 is probably the simplest and cheapest option. Removing it does not eliminate the need for IPv4 connectivity if your apps still depend on IPv4-only services and clients.
A public NAT gateway also needs a public IPv4 address, and its hourly and data processing charges can exceed the cost of the address on the instance. Price out the whole setup before changing it.
CloudFront can be the inbound edge for IPv4 and IPv6 clients, with an IPv6 connection to a custom origin. That makes the general design plausible for dynamic sites and webhooks, but check the behavior of each route rather than treating everything like a cacheable web page.
Configure dynamic and webhook paths to forward the requests and headers the applications require, and avoid caching responses that should not be cached. Also make sure the origin's network rules allow the intended traffic and that webhook signature verification still works with the forwarded request.
For outbound connections from an IPv6-only subnet, the AWS-native option is DNS64 plus NAT64 through a NAT gateway. DNS64 synthesizes an IPv6 address for a hostname that only resolves to IPv4, and the gateway translates the connection to the IPv4 destination. You also need the appropriate subnet routing for the synthesized addresses.
That avoids writing a proxy for each API, but it does not meet a goal of eliminating public IPv4 from the whole setup. A public NAT gateway uses one, and you pay for the gateway and its data processing. Check current regional pricing against simply retaining the instance address.
A proxy is another way to reach an IPv4-only API from an IPv6-only application. A small serverless function could act as a purpose-built proxy, though that adds deployment, security and failure-handling work. Compare that with NAT64 costs rather than assuming either is simpler.
You do not have to switch everything at once. Check each dependency for IPv6 support, move the ones you can, and test the remaining IPv4 paths before removing the instance address. For mail, a dual-stack SMTP provider or a different login flow could remove one dependency, but it would not solve the IPv4-only API calls.
Answers are reviewed before publication.
Vexlin.6r:
Removing the A records without an IPv4-capable edge would cut off IPv4-only visitors, so test the edge paths before changing DNS.