Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS to begin charging for public IPv4 addresses

aws.amazon.com

Post reply on HN
Print view View original

191–200 of 377 posts

Re: AWS to begin charging for public IPv4 addresses

#191

Post by colmmacc »

tedunangst wrote: post #182
colmmacc wrote: post #143

Earlier quoted context omitted.

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…

But TCP fragments in the same way?

TCP does not use IP fragmentation, and the IP packets are marked "Don't fragment". TCP performs its own fragmentation and every packet gets a TCP header in its leading section. A NAT, Firewall, or end-host can L4 route the TCP packet as-is and does not need to correlate with other packets.

Edited to extend: this is why TCP has a "Maximum Segment Size", and why Path MTU Discovery information has to be passed into the TCP state machine. It is TCP that takes responsibility for carving up the data into the packets, not IP.

One of the goals of UDP was to avoid needing this kind of state, which is why the IP layer handles fragmentation for it instead. This is allowed on a hop-by-hop basis, unless the DF bit is set; so when a "too big" packet gets to a node with a smaller MTU, it can just split it and send on the fragments. No PMTUD needed.

The design could have been for the fragmenting node to also add a UDP header as part of that process, but was not. It would have been a simple change at the time. It's had a lot of consequences since and is responsible for a decent amount of complexity in hardware and software packet pipelines.

Re: AWS to begin charging for public IPv4 addresses

#192

Post by Saris »

decasia wrote: post #103

So I have a tiny personal website hosted on ec2. Right now the DNS points to the server's public IPv4 address. But I don't really want to pay $40+/year for an IPv4 for my personal project. Does anyone have experience switching a small personal site to IPv6 only in 2023? I'm guessing the vast majority of my (North American/European-based) friends and visitors can probably connect just fine to an IPv6 address. I wish I…

Why not switch to a different provider? AWS is really pricey for what you get

Re: AWS to begin charging for public IPv4 addresses

#193

Post by dilyevsky »

cebert wrote: post #188
CSSer wrote: post #56

Earlier quoted context omitted.

I ran into a SaaS company recently that had a guide for how to setup a white-label domain using route 53 and Cloudfront for one of their services. The SaaS company charges for service bandwidth usage, and they host their infrastructure on AWS, so if you opt to follow their guide they get a fat margin bump in the form of avoiding an egress charge and you get to be double-charged for bandwidth. You've gotta love it.

How are the avoiding egress costs? I am not completely following.

Egress to cloudfront is free on aws

Re: AWS to begin charging for public IPv4 addresses

#194

Post by theamk »

otabdeveloper4 wrote: post #83
whalesalad wrote: post #37

Earlier quoted context omitted.

yep, and they should. aws has never really been suited to the hobbyist. does it work for that? of course. is it most cost effective? absolutely not. is it cost effective for people who need the resources? yes.

> is it cost effective for people who need the resources? yes. There is no possible use case in no possible universe where AWS is cost effective. Renting the same compute resources wholesale will cost you 20 times less. (Not a typo.)

so I have an HTTP endpoint which gets maybe 10 hits per day, and does some lightweight computations and records small amount of data.

Right now, this is done on AWS, with lambda + S3, and costs under $0.02/month.

Can you point me to something more cost effective that that? Don't forget I also need backup for data, automatic failover in case of machine failure or crash, amd no maintenance (like OS upgrades) for 5+ years.

Re: AWS to begin charging for public IPv4 addresses

#195

Post by mr_toad »

capableweb wrote: post #107
decasia wrote: post #103

So I have a tiny personal website hosted on ec2. Right now the DNS points to the server's public IPv4 address. But I don't really want to pay $40+/year for an IPv4 for my personal project. Does anyone have experience switching a small personal site to IPv6 only in 2023? I'm guessing the vast majority of my (North American/European-based) friends and visitors can probably connect just fine to an IPv6 address. I wish I…

According to Google ( https://www.google.com/intl/en/ipv6/statistics.html ), 60% of word-wide users wouldn't be able to visit your website. In the US, it would be about ~50% of users, while in Europe it's ranging from 30% (France) to 98% (Spain) who wouldn't be able to visit the website. But yeah, I'd do what you say in the bottom of your comment. Add AAAA records and then see how many people uses ipv6 compared to ip…

So if a domain only has a AAAA record, and for whatever reason a user can’t use IPv6, what sort of error message would the user see?

Re: AWS to begin charging for public IPv4 addresses

#196

Post by zgluck »

profmonocle wrote: post #189
zgluck wrote: post #175

For ECS users who depend on public IPs to avoid insane NAT GW fees when doing CI/CD.. I guess we have two options: a) build something that automatically scales broken services to 0 b) use that AWS service that let's you pull ECR images without internet access; I forgot the name of it...

c) nudge all the services your CI system interacts with to enable IPv6 to save their AWS users money. ;-)

Why would AWS charge less for IPv6 traffic through their stupid gateway than for IPv4 traffic? It's just an artificial money making machine anyway.

Re: AWS to begin charging for public IPv4 addresses

#197

Post by acdha »

brickteacup wrote: post #139
amluto wrote: 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)

Yeah, the endpoints bother me. I get charging for IPv4 space but they shouldn’t charge you for calling their APIs, especially since it’s one ENI per endpoint so I have a few VPCs which have half the allocated addresses used by endpoints (the old trade off between multi AZ reliability and the cost of allocating redundancy).

Re: AWS to begin charging for public IPv4 addresses

#198

Post by chungy »

Aeolun wrote: post #131
candiddevmike wrote: post #77

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…

I must be in my wrong mind then. :)

Just because it's a 128-bit number doesn't mean it should be difficult to remember, the standard notation goes a long way toward that. 2001:db8::cafe:f00d and fc00:bad:beef::1 aren't what I'd call the epitome of "can't remember"

Mind that real-world global addresses often have four groups of almost-random at the beginning, but it's usually not terrible to commit to memory.

Re: AWS to begin charging for public IPv4 addresses

#199

Post by formercoder »

profmonocle wrote: post #185
brickteacup wrote: post #139

Earlier quoted context omitted.

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)

This is one thing Google Cloud does well - traffic to Google services bypasses NAT gateway, even over IPv4. I was curious how they do this, so I set up a service on Google Cloud Run that just echo'd the user's public IP address. When curl'd over IPv4, it said I was coming from a unique local (i.e. private) IPv6 address. The private IPv4 address of my server was embedded in the address, along with some other random-lo…

Our network is completely software defined, so we just fake it to the VM and make it look like it's talking right to the service, and do all the routing via magic.

Re: AWS to begin charging for public IPv4 addresses

#200

Post by endgame »

ttt3ts wrote: post #137
amluto wrote: 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…

Bit confused. Couldn't you just run a Linux VM to do your NAT and only pay normal egress?

Yes. And AWS do (sorta) offer a NAT AMI (amazon machine image) if you want to do more management yourself and not get extorted for bandwidth.

https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Ins...

I say sorta because it's built on an old version of Amazon Linux and is headed towards EOL with no replacement except "go build your own" as you suggest.

https://www.lastweekinaws.com/blog/an-alternat-future-we-now...

AlterNAT uses managed NAT Gateways as a fallback when the NAT Instance is out of service, but again you will have to make your own NAT AMI.

This is not to excuse AWS' frankly absurd NATGW pricing, but to point out other ways around it.

Post reply on HN