I run a small Terraform-managed setup in us-west-2 with one t4g.small EC2 instance hosting several web apps behind Caddy. The VPC and instance are dual-stack, the instance is in a public subnet, DNS has both A and AAAA records, and ports 80/443 accept IPv4 and IPv6. SSH and Git access already use IPv6, but the instance still has one paid public IPv4 address.
I'm considering removing that public IPv4 entirely and possibly making the subnet and instance IPv6-only. I understand the VPC would still have an IPv4 CIDR and private IPv4 addresses, which are not the main cost concern.
For inbound traffic, I could remove the A records and put CloudFront in front of the instance. IPv4 and IPv6 clients would connect to CloudFront, which would then reach the origin over IPv6. This would also help with Stripe webhooks, since Stripe currently publishes IPv4-only webhook source addresses. CloudFront-to-EC2 seems reasonable for dynamic sites, but I'd like to know about practical limitations.
Outbound traffic is more difficult. The applications call the Stripe API, whose hostname currently has no AAAA record, and some GitHub downloads are also IPv4-only. I could move GitHub access into CI, but Stripe still needs a solution. AWS offers DNS64/NAT64 through a NAT Gateway, although that appears much more expensive than keeping one public IPv4 address. A small Lambda or proxy outside the VPC might be another option.
Email could be handled by removing email login in favor of Google OIDC or switching to Amazon SES's dual-stack SMTP endpoint.
For a small workload like this, what would you actually build? Is CloudFront in front of an IPv6-only EC2 origin a sound design? What is the simplest way for the instance to reach IPv4-only services such as Stripe? Are there shared IPv4 egress options that avoid both a public IPv4 on the instance and a NAT Gateway? What other dependencies commonly break during an IPv6-only migration?
4 Answers
A small NAT instance or purpose-built lightweight NAT appliance can be cheaper than a managed NAT Gateway, and it can provide IPv4 egress for private workloads. That does introduce patching, failover, scaling, and security responsibilities, so it’s mainly worthwhile when you already have several instances or need more control. For one small server, the operational complexity can easily outweigh the address charge.
CloudFront in front of an IPv6-only origin is a workable setup, including for dynamic applications and webhook endpoints. It gives IPv4-only clients an edge entry point while the origin can stay IPv6-only. For outbound access to IPv4-only services, though, you need a translator or an intermediary proxy—there isn’t a magic AWS shared-egress option that avoids someone operating the IPv4 side. A Lambda proxy can work at low volume if the API and security model fit, but check whether the service requires stable source IPs and whether invocation, timeout, or throughput limits matter. At higher volume, a persistent proxy becomes more practical.
Before changing anything, inventory every outbound connection made by the applications, libraries, package managers, monitoring agents, and operating-system update process. Some AWS endpoints and common developer services still have incomplete IPv6 support.
The native AWS design is subnet DNS64 plus NAT64 through a NAT Gateway. IPv6-only clients receive synthesized AAAA records for IPv4-only destinations, and the gateway translates the traffic. Technically it solves the Stripe problem cleanly, but the economics are difficult here: a NAT Gateway’s hourly and data-processing charges can be many times the monthly cost of one public IPv4 address. If Stripe is the only important IPv4-only dependency, a NAT Gateway is probably overkill.
CloudFront may also make financial sense independently if you have significant internet egress: traffic from the EC2 origin to CloudFront is generally treated favorably, and CloudFront includes a free usage tier. But for a small application, the data volume may not justify it. I’d compare the actual monthly transfer costs rather than assuming the IPv4 savings will cover the edge service.
For a tiny deployment, I’d probably keep the public IPv4, use CloudFront for inbound traffic and webhook compatibility, and revisit IPv6-only once the remaining external services support IPv6.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures