On October 15, AWS made it possible to run IPv6 to private origins behind CloudFront, and the people who benefit most are not the network engineers. They are the CISO, the compliance lead, and whoever signs off on the quarterly public IPv4 line item. If your answer to “why is that load balancer public?” is a shrug, this one is for you.
Why IPv6 to private origins matters now
Until now, CloudFront’s VPC origins feature let you hide an application load balancer, network load balancer, or EC2 instance in a private subnet, with CloudFront as the only way in. It was a good security story with one asterisk: the edge-to-origin leg was IPv4 only. Teams with IPv6 mandates, or who simply wanted to stop burning scarce IPv4 addresses, had to pick one. Private, or modern.
Per the AWS announcement, dual-stack support is available in every commercial Region where VPC origins are supported, at no additional cost. No new line item, no new contract, no new service to approve. That combination is rare enough to be worth a meeting on its own.
Three reasons leadership should care
1. Smaller attack surface, fewer exceptions
Every public endpoint is something your security team has to defend, monitor, and explain to auditors. Private origins mean CloudFront is the single public entry point, so your WAF, rate limits, and logging sit at one door. The old workaround for IPv6, a public load balancer plus controls to keep people off it, created exactly the exceptions auditors love to circle. Removing the need for that workaround removes the finding before it is written.
2. IPv4 address exposure
AWS has charged for public IPv4 addresses for a while now (see the VPC pricing page for current rates), and the internet is not getting any more of them. An IPv6-capable private path is one more piece of a plan that shrinks your dependence on that scarce resource. Be realistic about scale: this feature alone will not make your bill fall off a cliff. But it removes an excuse, and the longer you stay IPv4-only, the more expensive and political the eventual move gets.
3. Compliance and customer pressure
Public sector buyers, large telecoms, and some regulated industries increasingly ask vendors for IPv6 readiness. “Our edge supports it, our origins do not” is a weak answer in a procurement questionnaire. End-to-end is a better one, and now it is available without reopening your network security model. Check the CloudFront IPv6 guidance with your team so you can answer those questions accurately.
What it actually costs you
The feature is free. The work is not. Plan for effort in four places:
- Network readiness: your VPC and private subnets need IPv6 ranges, with spare addresses for the managed interfaces CloudFront places in them.
- Security rules: firewalls and security groups must allow both address families from CloudFront. Allow one and you get intermittent failures that are miserable to diagnose.
- Application assumptions: anything that parses, stores, or allow-lists client IPs may have IPv4 baked in. Logging pipelines and fraud tools are the usual suspects.
- Known limits: per the VPC origins documentation, gRPC, certain Lambda@Edge triggers, Gateway Load Balancers, and NLBs with TLS listeners are not supported. If your architecture depends on any of them, stop here and plan around it.
The risk side of the ledger
Nothing changes by itself. Existing origins stay on IPv4 until someone changes them, which means this is a controlled change, not a surprise. The real risk is a rushed one: a team flips the setting on a production distribution on a Friday, forgets the second prefix list, and spends the weekend explaining intermittent errors to customers.
There is also a perception risk worth naming. The documentation requires an internet gateway attached to the VPC, even though nothing routes to it. A security reviewer who sees that attachment may raise an alarm. Pre-empt it: document that the gateway is a prerequisite of the feature, that no route points to it, and that subnets stay private. That is a five-minute conversation if you start it, and a two-week argument if you do not.
A sane rollout plan
- Inventory. List every public load balancer that sits behind CloudFront. Those are your candidates, and probably a few surprises.
- Pick one low-stakes service. Internal tools or a marketing site, not checkout. Prove the pattern once.
- Use staged deployment. CloudFront supports continuous deployment, so a fraction of real traffic can validate the change before everyone gets it.
- Measure. Watch error rates and IPv6 request counts at the load balancer, and confirm with logs that traffic is arriving over both families.
- Standardize. Bake the pattern into your landing zone templates so the next team inherits it instead of rediscovering it.
One budgeting note. The direct cost is zero, so the number to track is engineering time. For a handful of distributions, expect days, not quarters. For a sprawling estate with hundreds of origins and per-team security groups, the cost is mostly coordination, and that is where a platform team earns its keep by shipping a vetted template instead of a wiki page. Tie the work to something you already planned, such as an audit remediation or a landing zone refresh, so it does not compete for its own slot on the roadmap.
The decision
This is not a feature you must adopt this quarter. It is a feature that removes an objection. If you were holding off on private origins because of IPv6, that reason is gone. If you were running public load balancers for IPv6 reachability, you now have a path to retire them. And if neither applies, file it, because the question will come up in your next audit or customer review.
For the architecture standard itself, the Security Pillar of the Well-Architected Framework and the networking blog on IPv6 origins give you language your reviewers already recognize. Ask the owning team for a one-page summary: which distributions, which origins, what the rollback is, and who answers the page if it goes sideways. If they cannot produce it in a week, you have learned something useful about the team, not the feature. Our take: AWS did the unglamorous thing here, which is to make the secure option also the modern option. Those releases age well. Treat it as a small, cheap, low-drama upgrade to your architecture standard, give it an owner and a date, and move on to bigger fights.
ENKOMPASS IS HERE TO HELP
At Enkompass (enkompass.net), this is our home turf. We run origin inventories, security reviews, and staged CloudFront and IPv6 migrations so your auditors see fewer public endpoints and your customers see no downtime. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.
Leave a Reply