ALB uses 2-4 IPv4 addresses. It supports dualstack, but not IPv6-only.
CloudFront does not support IPv6 origins.
All APIs except for a handful are IPv4-only, so you either need a VPC endpoint (priced per month per AZ per API) or an IPv4 address to communicate with them.
It frustrates me that I'll be paying for a bunch of IPv4 addresses that I don't need for any business reason, I only have them because they're necessary within the AWS ecosystem.
yeah, that's a sad table. AWS has gazillion services and handful have even basic dual-stack support and even fewer have ipv6-only support :(
The prices for IPv4 addresses finally got so high that they had to break it out into a separate charge because otherwise it would be too much to bake into the cost of everything. I also completely believe them when they say they are doing it to force people to be more intentional about their use of public IPv4.
And of course it's a great way to get people to move to IPv6, since those are still "free" (in quotes because those prices are still baked into the things that support them).
They are basically free because there is no shortage of them.
dig github.com AAAA
Also, I'm just saying:
$ dig gitlab.com. AAAA
2606:4700:90:0:f22e:fbec:5bed:a9b9
Interestingly, it seems AWS is the outlier in the "IPv6 control plane is a fad" stance
$ dig admin.googleapis.com. AAAA # as one might expect
2607:f8b0:4005:810::200a
$ dig management.azure.com. AAAA # which surprised me
2603:1030:a0b::10
$ dig ec2.amazonaws.com. AAAA # :trollface:
$ dig ec2.amazonaws.com. A
209.54.181.135> AWS will likely make anywhere between $400 Million and $1 Billion dollars a year with this new IPv4 charge!
In other words, it's not clear AWS is "making" anything at all. It might take them over 10 years to pay back the cost of what it would take to acquire them today.
Now I assume Amazon is making some level of profit on them, but the article seems to confuse income with profit. "Making" money is generally understood to mean profit, not income.
You are of course correct that this gives them revenue, my point is that the article is falsely framing this entirely as profit.
Like if you already owned a piece of land and let people rent houses on the land, and now you're charging them extra rent per square foot of land. You already own the land, so it's pure profit, because before you were including the cost of land in the houses. But of course the metaphor breaks down because at AWS you can move to IPv6 to avoid the cost, but you can't move the house off the land.
IP addresses are intangible property and, at this scale, their cost would probably be amortized over a period of e.g. 20 years.
For accounting (and tax purposes), it's not one big up-front cost where everything that follows is pure profit.
Just because costs happen before income, it doesn't follow that all the income is profit. You have to look at things over the expected useful time frame of property.
Common clickbait tactic, hence avoiding the use of falsifiable terms like net income or profit.
So in the end, they take a public good that is basically free, a lot lot lot of it, and like a hold up they make a lot of money racketeering you monthly because you are too insignificant to be allowed to own your own ips...
* Aside from a very minimal amount of space allocated for v6 transition technologies[1] and from the waitlist[2], organizations do have to pay market rates for IP addresses.
* Organizations do need to pay a yearly fee to keep them, which scales with the amount of address space held.[3]
* You are not too insignificant to be allowed to own your own IPs - anyone can establish at least 2 peering relationships, ask ARIN for an ASN, and acquire some IPs.
[1]: https://www.arin.net/participate/policy/nrpm/#6-5-3-1-subseq...
[2]: https://www.arin.net/participate/policy/nrpm/#4-1-8-arin-wai...
AWS to begin charging for public IPv4 addresses
https://news.ycombinator.com/item?id=39199841
I wouldn't be surprised if AWS are holding back on implementing this financial change for a future raining day quarter ... because it'd have a bigger impact than IPv4 billing.
I mean if I were doing it, I'd probably make it more like 1,028 times bigger but maybe it would present as hubris. Addresses would be so plentiful they'd basically be free.
And since I am using magic to do all of this, I'd invent it over 20 years ago, so that it'd have been decades since we were still talking about it.
There was no way to change IPv4 to have more address space while maintaining compatibility with existing routers. Routers are hardware-accelerated so can't just support new protocols with a software update.
If you need a new protocol, why just lengthen the address without fixing other weaknesses, since you'll never be able to change it again? This is IPv6, and while you can argue some changes weren't necessary, it is simply not true say that IPv4 with extra bits would have been easy.
It took over a decade to get feature parity from the non-network-operators that overtook the IETF, and that seriously delayed IPv6 adoption.
IPv6 involved too many other changes to make it a straightforward upgrade. I agree that it's ridiculous that we still don't have universal v6 support, but let's not pretend the protocol designers made it easy.
The biggest shock is for people who have gotten the NAT stockhold syndrome (which always went against IPv4 internet architecture, there's a reason it's outlawed in the standard track IP RFCs).
I wish IPng had taken a totally different approach to addressing and routing:
- for addressing, yes, very large (or even variable-length, like CNLP, see below) addresses fields in the IPng header
- for routing, the IPng header should have had a source and destination ASN fields, with the source being filled in by the sender's router(s) (either immediately in the interior, or at the edge), and the destination ASN fields to be filled in by the sender by querying something like the DNS (but optimized for, essentially, CIDR-style IP->ASN lookups, though DNS can do it). This would have made routing much simpler and faster, since routing protocols would only have to exchange information about ASNs and not about any address prefixes, thus yielding much smaller routing tables. The address->ASN lookup service would have needed very little churn since its contents would change only when sites change Internet service providers.
I wasn't there then, so don't blame me, but also honestly I probably wouldn't have thought of this either.
In practice we ended up with something just like this but... without address number portability, which is a shame.
Response was to make a wholly new protocol when they could have just updated the standard and forced suppliers to patch updates?
USB backwards compatability that shiz. The fact I can take a modern usb device and plug it in a 1.1 gen port and it still just works. Why the hell isn't ipv4 like that for upgrades?
Seriously is there any real technical hurdle why we didn't do it this way?
Just make sure you make it as user-friendly & functional as its predecessor and don't stuff a whole bunch of nonsensical half-baked features into it. Otherwise, people may have no choice but to keep using the older solution.