Many years ago when I was a junior dev at Amazon, there was a massive project internally to split up every internal system into regional versions with limited gateways allowing calls between regions. The reason? We had run out of internal IPv4 addresses.<p>The Principal PM in charge of the "regionalization" effort was asked in a Q&A "why didn't we just switch to IPv6?".<p>Her answer was something along the lines of "The number of internal networking devices we currently have that cannot support IPv6 is so large that to replace them we would have needed to buy nearly the entire world's yearly output of those devices, and then install them all."[0]<p>It's easy to presume malicious intent on the IPv4 front from Amazon, but with so many AWS systems being on the scale they are at, I find it easy to believe that replacing all of the old network hardware may just be a project too large to do on a short timescale.<p>[0] - At least, that's my memory of it. I'm sure that's not an entirely accurate quotation.
It seems obviously against AWS incentives to offer working v6 - all their influencing tools ("well architected" criteria, certificates) strongly herd you towards building mazes of ambigously addressed 10.x RFC1918 networks, and not internet style architectures with end-to-end addressing.<p>In the world of their recommendations, even the concept of a "public ip address" is a red flag, and AWS even recommends (for an added cost of course) tooling to flag and "mitigate" them. These provide a strong lock-in effect when customers spend effort to build the complex infrastructure for them in the name of security, even though in reality they hurt security through unnecessary complexity, addressing ambiguity, etc.
As an AWS customer I want to escape IP entirely. It's a waste of time managing these complex networking systems with their archaic protocols (IP, BGP, DNS, etc)<p>Just let me strongly associate identities with my workloads and apply policy indicating which workloads should be able to send data with which other workloads.<p>How data gets from one workload to another should not even be my concern, just make it happen.
In my experience the biggest issue for being IPv6 only in AWS is that github still can't IPv6! Tons of software expects to be able to reach out to github for something.<p>One can use some public NAT64 services, but that's not very reliable for anything serious. <a href="https://nat64.xyz/" rel="nofollow noreferrer">https://nat64.xyz/</a> . AWS chargers arm and leg for NAT gateways traffic, and I don't think it's possible to configure them so that they only intercept traffic to ipv4-only hosts (please let me know if i'm wrong).<p>Other than this being IPv6-only in AWS works flawlessly and is cheaper (free egress gateways for private networks). As long as you don't care about IPv4 of course - that's given.
IMO services like Lambda and S3 not supporting IPv6 is the real issue, and AWS shouldn’t have made the pricing change without first making them dual-stacked, accessible over IPv6.<p>(Technically S3 does have a separate dual stack endpoint, however it doesn’t really help as I have to change application configuration anyway to deal with this change.)
Half the reason AWS has leading IPv6 support in the first place is due to mandates from the US government to start migrating. Author is correct that, from a cost perspective, the new costs are immaterial to large customers, but I wouldn't discount the power of policy mandates from the largest customers, where the threat of building an in-house alternative to comply with policy might be sufficient to force AWS to finally prioritize support.
Worst for me is CloudFront not supporting IPv6 for custom origins. If you happen to run a lot of separate Fargate containers as origins, you have to enable public IPv4 addresses for them, and that will soon double the price of small confainers. Amazon needs to make their infrastructure actually support IPv6 before starting to charge extra for legacy IPv4 usage.
It would really help if there were real ISP competition in the USA. There's only one actually broadband ISP provider where I rent, which is in the suburbs near Seattle. It's NOT a rural area by any definition, and yet Comcast is my only option. Their price and service reflect that reality...
The "cannot escape IPv4" is apt because while you can setup an IPv6 only VPC so many things break; from various AWS services to package repositories [0]. So then you're stuck either enabling IPv4 or running a NAT64 gateway (or trusting someone to run one for you [1]).<p>[0] <a href="https://blog.devopstom.com/ipv6-only-ec2/" rel="nofollow noreferrer">https://blog.devopstom.com/ipv6-only-ec2/</a>
[1] <a href="https://nat64.net" rel="nofollow noreferrer">https://nat64.net</a> and <a href="http://v4-frontend.netiter.com" rel="nofollow noreferrer">http://v4-frontend.netiter.com</a>
> There is no concept of private addresses in IPv6, which means farewell to the Managed NAT Gateway and its magnificent pricing.<p>Maybe not in AWS, but there are Unique Local IPv6 addresses in fc00::/7 and NAT66 if you really love NAT!
IPv6 is such a massive headache it’s kind of mind boggling. I used to be super enthused - but it is absolutely less useful and more annoying than it’s worth.
It's not that people dislike IPv6 or like IPv4, it's that network people are comfortable with IPv4 and all the extra tech surrounding it. They know it works, so there's no technological risk. There's nothing new to learn. It's cheap. There's nothing your average business wants to do that can't be done on IPv4 that can on IPv6. The ROI of just paying for IPv4 addresses and associated tech/services is undeniable.
AWS has a way to go with their IPV6 services, but IPV6-only is very doable right now in EC2.<p>I have a WireGuard server that was dual-stack. I turned off IPV4 to see what would happen, and it kept chugging along very nicely.
> The first pattern is having multiple Load Balancers (per VPC); this is often the result of using several readily available Cloudformation templates / Terraform modules, or somehow using Kubernetes ingress controllers that create a Load Balancer for every service. This is fixed by not doing that! A single Load Balancer can handle many URLs and services.<p>This is the definition of cloud bloat. The fact there are tons of systems abusing that kind of architecture probably justifies charging for IPv4.
I use DigitalOcean... almost all their products support IPv6. Only floating IPs are IPv4, but can work around that by not destroying droplets so the IPv6 address doesn't change.
Honestly IPv6 is a clusterfuck. From the horrible addresses (why are they impossible to memorize? Who thought that was a smart idea? At least I can wrap my brain around IPv4) to the need for specific support in literally every layer of the network stack.<p>If you are going to mention gateways or other methods make it work please just stop. No end-user is going to do that, or rather no appreciable amount of end users are going to do it. If your fix starts with “why don’t you just…” then please stop living in a fantasy world.<p>I was excited for IPv6 when it was announced, I was excited years later, I was excited a decade later, now I’m just tired of it. 2024, year of IPv6 and and the Linux desktop, ok sure. My ISP, literally the best available in my area and fairly cutting edge in every other aspect, has zero IPv6 support.<p>While the idea of every device having its own public IP address was attractive to a younger me, I look at it with a bit of horror now. The privacy/security aspects alone are staggering and you rarely want your device to be publicly available by default. I’m not going to exceed the 16M+ limit of 10.0.0.0/8 so I don’t see why I would ever want to use anything but IPv4 internally for my sanity. Are STUN/TURN servers fun? Is needing some central server ideal? No but the alternative (everyone can talk to everyone directly) makes my head hurt with the implications and footguns.<p>At the end of the day I’ve started disabling IPv6 as a matter of course. Leaving it on is a landmine I’m laying for my future self. I’ve dealt with too many issues directly myself or for clients/customers which end with “let’s try disabling IPv6, oh it’s working now?” (on my end or theirs) that I’m done. Something drastic would have the happen to get me to change that thinking and seeing how it’s been over 2 decades and major websites I use daily still don’t support IPv6 I’m not holding my breath.
I feel like there's now a perverse incentive here for Amazon to drag their feet at implementing full feature parity with IPv6. I wish these new charges only applied for IPv4 addresses used with services that already do have that.
There's one viable solution to be able to run IPv6 only subnets in AWS, their (or your own) NAT gateways support v6->v4 NAT. So it allows you to create large IPv6 only subnets for your compute services (ec2, ecs, k8s, elb, all supports that), allowing your containers to scale without worrying about IP addresses. Then you use dual stack subnets for other AWS services that may not support IPv6 and your compute services can access them through the NAT gateway.
> RDS (nine in ten customers have public IP on RDS by accident)<p>AWS <i>does</i> make it easy to fuck up with its default settings. Subnets that auto-assign EIPs for every instance attached to them <i>should not exist</i>, period. And neither should RDS instances or anything else be reachable from the public Internet by default.
There needs to be a body of law relating to technical matters like this (and interoperability etc) that is adjacent to competition law. Some things we just need everyone to be on the same page about. It is manifestly the case that ipv6 is never going to be that, because the incentives to invest simply don't exist for companies like AWS.<p>This distorts the market in eyeball networks and hosting - the former are under little pressure to offer v6, and new entrants to the latter can <i>only</i> offer v6. Competition law in the EU works (I think?) on the principles of consumer benefit and market fairness. On that basis, I'm left wondering why this has never been pursued by the EU's competition authorities.
One major weirdness with ipv6 is that it occasionally works with ipv4 and it's unclear why.<p>Example: we run a bunch of endpoints on ipv4, but get ipv6 IPs in our logs. How? Are there 6-to-4 translators out there at ISP edges?<p>Unknowns in networking are bad.
Sorry for the aside, but I hope the neveragain.de author will make a blog post about their site theme. I _really_ like it, and of course I would like to mostly copy it for my own personal site.<p>That said, until the cost of IPv4 becomes really huge, few organizations are going to suffer the effort-cost of embracing IPv6.<p>I would argue that the IPv6 sales story is unmemorable|unclear|weak. Also, it is arguable that most IPv4 addresses are wasted.
AWS Lambda doesn't support IPv6 in VPCs.<p>This means that everything else in your VPC has to be dual stack if the lambdas talk to them.<p>AWS Lambdas don't actually run in your VPC, there is an ENI that is exposed to your VPC that belongs to the VPC-equivalent in the Lambda space.<p>If you have to run dual-stack just to accomodate lambdas, then you may as well run IPv4 anyway.
The moment you have a customer with crappy legacy infrastructure who refuses to allowlist anything but static IPV4 addresses, you have to support IPV4.
My ISP, Fidium, does not have the word IPv6 on its entire website. And definitely has no support of it on my WAN. They should. I want to connect to IPv6 services using their connection.<p>I actually keep a cheap Comcast connection as a second WAN just to get IPv6 enabled on my home network. (And also because I live in the woods in New Hampshire and having two ISPs means I have fairly ok uptime)
Off topic: Does anyone know if this page is generated from a Static-Site generator starting from Markdown?<p>I currently use Hugo and my blog is in Markdown in git, but the theme is pretty heavy-weight, and I like this look of the page in OP; Looking at the source, it's so minimal!
><i>almost no AWS API can be used from a VPC without public IPv4 addresses</i><p>Virtually every single application at the company I work at deploys into VPCs without public IPv4 addresses - this seems like a ridiculous claim.
I migrate my proxy's IPv4 address from time to time to avoid blocks<p>This is not so easy to do with a IPv6 address, AWS tends to want to keep it the same