Live data from Hacker News

AWS to begin charging for public IPv4 addresses

aws.amazon.com

261–270 of 377 posts

Re: AWS to begin charging for public IPv4 addresses

#261
post #248
post #124

Earlier quoted context omitted.

AWS NAT gateway is $0.045 per hour plus $0.045 per GB. The hourly fee seems mostly okay - for largish users, one or two per region is fine. $0.045 per GB is nuts . That’s $20.25/hour or $14580/mo for 1 Gbps. One can buy a cheap gadget using very little power that can NAT 1 Gbps at line rate for maybe $200 (being generous). One can buy a perfectly nice low power server that can NAT 10Gbps line rate for $1k with some c…

Is that $0.045/GB for all data transferred through it, or just egress to the public internet? If it's the latter, that's half the price of normal EC2 instance egress to the public internet. If it's the former... oh sweet jesus, what? Probably way cheaper to just run an a1.large or something with Linux on it, plus a very short shell script to set up NAT. That's assuming well more than half of the traffic going through…

No, it’s so much worse than that. Look closely at https://aws.amazon.com/vpc/pricing/ and note this line:

> You also incur standard AWS data transfer charges for all data transferred via the NAT gateway.

Yes, the $0.045/GB “data processing” charge is in addition to the usual $0.09/GB egress charge. You are paying an effective $0.135/GB for all of your egress, in addition to the $0.045/hr just to keep the NAT gateway running.

And yes, your ingress and even internal-to-AWS traffic is also billed at the $0.045/GB rate. (An example given on the aforementioned page is traffic from an EC2 instance to a same-region S3 bucket, which they note doesn’t generate an egress charge but does generate a NAT processing charge.) As far as I can tell, the only traffic which isn’t billed is traffic routed with internal VPC private IP addresses, which don’t hit the NAT gateway and thus aren’t counted.

There are highly paid AWS consultants who shave literal millions of dollars off of many company’s AWS bills by just setting it up a cheap EC2 box to handle their NAT instead of using the built-in solution. Doing that instantly wipes out the ingress charges and effectively halves the egress charges, and it’s probably a lower hourly cost than they’re already paying: an a1.large is $0.051/hr on-demand but that immediately drops to just $0.032/hr with a 1 year no upfront reserved plan. If you’re willing to pay upfront and/or sign a longer contract, you can get it as low as $0.019/hr.

Re: AWS to begin charging for public IPv4 addresses

#262
post #258

Earlier quoted context omitted.

Most applications will be able to move to v6 eventually. Hopefully moves like this will push that development.

It's ISPs who are the main problem, not applications.

Not software applications, applications of network usage (though I see why it would be reasonable to misunderstand)

Re: AWS to begin charging for public IPv4 addresses

#263
post #131

Earlier quoted context omitted.

Hmm, I use IPv4 mostly because nobody in their right mind can remember a IPv6 address…

Who's out there remembering IPv4 addresses?

Not I. Any commonly accessed IP tends to be named in my SSH config.

Re: AWS to begin charging for public IPv4 addresses

#264
post #131

Earlier quoted context omitted.

Businesses and organizations are holding IPv6 back, not consumers. No one I talk to is prioritizing IPv6 migrations or spending money to upgrade gear that will support it. Maybe some net new stuff might get it, but for most businesses IPv4 is and will be the default, simply because they can't be bothered to do something different.

Hmm, I use IPv4 mostly because nobody in their right mind can remember a IPv6 address…

Is is really so hard to remember the addresses fd::1, fd::2 etc. for your local network?

Re: AWS to begin charging for public IPv4 addresses

#266

Earlier quoted context omitted.

> We need a guild of software engineering The threat of professional exclusion is one of the big levers provided by such a guild. Given the way tech companies behave, why do you believe that this lever will be left in the hands of good people, and not taken over (like the rest of the internet)?

I think there are more developers opposed to the recent web attestation shenanigans than those for it (even those who might be coerced into being for it by their employer). A majority guild vote could stop everyone working on it and keep the web open.

Who accredits someone to join this guild? Who holds the keys?

Re: AWS to begin charging for public IPv4 addresses

#267
post #16

> A new blog post shows you how to use Elastic Load Balancers and NAT Gateways for ingress and egress traffic, while avoiding the use of a public IPv4 address for each instance that you launch. It would be nice if this came with reasonably priced NAT gateways. The current pricing is outrageous.

Not to mention the absurd fact that accessing (IPv4) AWS APIs from a private subnet requires paying for either a NAT gateway or an interface endpoint (we got bitten by sending a ton of Kinesis traffic through a NAT gateway once)

Another dead simple solution would be if AWS would provide us a simple subdomain (such as myapp.xxxx.aws-hosting.com), no need to meddle with IPs at all in that case. Google Cloud already does this with xyz.appspot.com subdomains, same with Github Pages as they provide you xyz.github.io subdomain for your app.

Re: AWS to begin charging for public IPv4 addresses

#268

Earlier quoted context omitted.

UDP is connectionless precisely so you can build novel stateful protocols on it. There’s no promise in UDP that you’ll be able to statelessly monitor it.

UDP is actually more expensive to NAT than TCP is. The reason is UDP fragmentation, which is my vote for the worst, and least forgivable, design error of TCP/IP. Instead of putting the fragmentation in L4 (like QUIC now does) and including a UDP header on every fragmented packet in a datagram, UDP only includes the header on the first packet. With fragmentation happening; firewalls, NATs, and end-hosts have to buffer…

Even well-behaved unfragmented UDP should be more expensive to NAT because it doesn't have an end-of-stream "FIN" marker, meaning stateful middleboxes need to retain state for longer because they can only time out.

Re: AWS to begin charging for public IPv4 addresses

#269
post #257

Earlier quoted context omitted.

Businesses and organizations are holding IPv6 back, not consumers. No one I talk to is prioritizing IPv6 migrations or spending money to upgrade gear that will support it. Maybe some net new stuff might get it, but for most businesses IPv4 is and will be the default, simply because they can't be bothered to do something different.

IP addresses should never have had letters and double colons in them. What's Google's IPv4 DNS? 8.8.8.8. What SHOULD Google's IPv6 DNS be? 8.8.8.8.8.8. What SHOULD Google's IPv8 DNS be? 8.8.8.8.8.8.8.8. What IS Google's IPv6 DNS? 2001::some::shit::I::::can't::remember//::h0ff::affblah This is why I'm still stuck on IPv4. I'm a walking DNS server for all the instances I own, I can hammer out IPs when DNS fails me and…

If it is the use of colons instead of dots that prevents you from learning the adresses, then I'm not sure you can be helped.

But that discussion aside, if you adopt the IPv4 naming scheme to the 128-bit IPv6 adresses, Google's DNS would be 8.8.8.8.8.8.8.8.8.8.8.8.8.8.8.8.

I would never be confident that I put in the right number of 8's in that case. And I have a feeling that you being overwhelmed has more to do with the total increase of possibilities, than with hexadecimal notation.

I guess it shows that IPv6 was designed for computers, not humans. Because we need a vast number if IP adressses. And that is fine for me.

Re: AWS to begin charging for public IPv4 addresses

#270

Earlier quoted context omitted.

> We need a guild of software engineering The threat of professional exclusion is one of the big levers provided by such a guild. Given the way tech companies behave, why do you believe that this lever will be left in the hands of good people, and not taken over (like the rest of the internet)?

I think there are more developers opposed to the recent web attestation shenanigans than those for it (even those who might be coerced into being for it by their employer). A majority guild vote could stop everyone working on it and keep the web open.

Yes, and if you can hold and retain power over the guild then the power of professional exclusion exceeds the coercive power of any one employer. But when your threat model includes adversaries who are willing to subvert the entire open internet to get their way, how do you harden your guild against this attack?
Post reply on HN