This finally puts real pressure on software and services to work on IPv6 only. I wouldn't be surprised if within 1-2 release cycles lots of distributions suddenly update just fine with just IPv6, package mangers can download packages over IPv6, lots of APIs gain solid and well-tested IPv6 support, etc.
AWS to begin charging for public IPv4 addresses
51–60 of 377 posts
Re: AWS to begin charging for public IPv4 addresses
#52Earlier quoted context omitted.
There is where people usually start chiming in about how they can run a VPS at Whatever Hosting and Waffles Inc. for $4/mo.
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.
[deleted]
Re: AWS to begin charging for public IPv4 addresses
#53> 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.
I completely agree. It’s odd they would announce charging for dedicated IPv4 while not having a free shared egress solution (unless I’m misunderstanding). I would expect them to reduce NAT pricing in the long run, but who knows.
[deleted]
Re: AWS to begin charging for public IPv4 addresses
#54> 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.
NAT is pretty computationally intensive, this is why e.g. ISPs & mobile carriers are pushing IPv6 over CGNAT.
Re: AWS to begin charging for public IPv4 addresses
#55Earlier quoted context omitted.
Totally disagree! :) My monthly costs are minuscule with a reserved with a t4g instance, Lambda, S3 and Cloudfront as my primary usage. Honestly, it beats out the “budget” VPS providers I was previously using, and is a heck of a lot more powerful/reliable.
I knew I’d get the counter points here on HN, but I’d argue we’re probably the exception here. AWS can be really cheap, but it is easy for things to go wrong. Bandwidth, commonly unmetered at places like OVH or Hetzner, can cost a fortune at AWS if you get attacked. And while AWS will refund you once or twice, after that you’re either left scared or on the hook eventually.
Absolutely! It just happens to be a good fit for me :)
I use very little bandwidth and processing with the vast majority of my projects. In the even that I do need heavy lifting for a couple hours, it still tends to be a pretty minimal cost.
Now for sustained heavy loads/bandwidth… I definitely would look elsewhere for hobby projects.
Edit: and I agree with your point about attacks. I have pretty aggressive monitoring set up around billing.
Re: AWS to begin charging for public IPv4 addresses
#56Earlier quoted context omitted.
$40/mo is outrageous? We spend thousands a month on AWS and drive most traffic thru a single NAT gateway. It's rock solid and it "just works" without any fuss. Totally worth it.
Plus $0.045 per gigabyte of data that passes through it. AWS has notoriously high egress fees.
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.
Re: AWS to begin charging for public IPv4 addresses
#57> 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.
I completely agree. It’s odd they would announce charging for dedicated IPv4 while not having a free shared egress solution (unless I’m misunderstanding). I would expect them to reduce NAT pricing in the long run, but who knows.
I'm shocked this isn't a feature of a VPC out of the box (shared internet bound traffic). You should only need a NAT gateway if you want the traffic to come out of a single set of external IPs that you control.
Almost all of my use cases I could easily ride out to the internet through a shared pipe (apt updates and such) and don't care whatsoever what IP that exits the AWS network from, since I'm not applying firewall rules or anything.
Re: AWS to begin charging for public IPv4 addresses
#58> 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.
$40/mo is outrageous? We spend thousands a month on AWS and drive most traffic thru a single NAT gateway. It's rock solid and it "just works" without any fuss. Totally worth it.
Most users are below 10Mbps average, so yes $480 per year is a huge price for a fraction of a percent share of a router (plus redundancy).
Re: AWS to begin charging for public IPv4 addresses
#59> 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.
$40/mo is outrageous? We spend thousands a month on AWS and drive most traffic thru a single NAT gateway. It's rock solid and it "just works" without any fuss. Totally worth it.
The expensive part of NAT Gateway is the $0.045/GB.
Re: AWS to begin charging for public IPv4 addresses
#60This finally puts real pressure on software and services to work on IPv6 only. I wouldn't be surprised if within 1-2 release cycles lots of distributions suddenly update just fine with just IPv6, package mangers can download packages over IPv6, lots of APIs gain solid and well-tested IPv6 support, etc.
Apple has been demanding apps support IPv6 only for years now. They reject your app if it fails under NAT64. The end user side is mostly a solved problem.