28
votes
AWS eIP price change. What's your plan?
Link information
This data is scraped automatically and may be incorrect.
- Title
- New - AWS Public IPv4 Address Charge + Public IP Insights | Amazon Web Services
- Published
- Jul 28 2023
- Word count
- 678 words
AWS is planning to start charging for eIPs that are in-use, and if my understanding is correct this will increase monthly bill quite a bit for most AWS users, especially for organizations that have multiple accounts with multiple availability zones and NAT gateways.
Curious, what's your plan to deal with this, if you are an AWS user?
Out of curiosity, anyone here that has trouble connecting to a ipv6 only site? I think https://ipv6.google.com/ is ipv6 only (please correct me if I'm wrong!). I'd imagine most ISPs nowadays should have sorted out connections to IPv6 domains. Would be nice to hear if someone has had issues with this. Otherwise a simple solution would be to use IPv6 for your public facing domain...
This didn’t work for me with Bell Canada Home Wireless.
I know my ISP (CenturyLink/Quantum Fiber in the US), despite being the largest Tier 1 backbone provider on the damn planet, and said backbone supporting v6 natively, still only has 6rd as an option to get v6 connectivity as a home or non-enterprise business customer, and it's not enabled by default on their equipment either.
IIRC Verizon FiOS is also only just rolling out v6 to their customers as of the past year, even though both their backbone and wireless sides have supported v6 for years now.
That url didn’t work for me (novus in Canada).
Worked for me in Canada on Telus Fiber. Testing now on Telus Mobility.
Apparently I can't edit my own post, so confirmed it worked on Telus Mobility as well!
Probably just going to pay more. If I cared, I guess I would put more stuff behind an ELB and use vhost routing rules — you can put a lot of websites behind a single IP on a single ELB if you want to.
Not much to be done about public facing non-HTTP services.
In my experience, IPv6 is nowhere near usable.
I'm just hoping thiis will speed up IPv6 adoption - getting a static IP for self-hosting is expensive, and IPv6 would completely remove that cost. If all ISPs support IPv6 by default, then home servers will become easier for the average newbie to set up.
I just use ddns, syncs from my router to dns provider. Enough for my hobby home lab.
This is all cost being forwarded to the consumer today.
Besides more address space, IPv6 also benefits from other design choices, since it was designed based on a decade of experience with IPv4, such as: having a fixed header length (for faster processing), no checksum in the IP header to be calculated (faster processing) because both the Ethernet layer above and the TCP/UDP layers below already have one, no fragmentation where routers need to break up and reassemble packets based on the MTU (again leading to faster processing), and better multicast support (more efficient than broadcasting, for example when looking for a router instead of just querying every device on a LAN). I am personally also a fan of
::1(localhost) and::(bind to any interface) compared to having to type out 127.0.0.1 and 0.0.0.0 in many applications.We can also get rid of NAT (in favor of stateful firewalls), which greatly simplifies applications where people want to talk to each other. Think of calls or games, where the data needs to get to another person as quickly as possible and you don't need or want a relay server. Avoiding needing relay servers as fallback also benefits open source projects who don't have a budget for that sort of thing.
I am quite curious where you got the "literally no advantage" idea from
I, too, would like to convince the US DoD they don't need all that dead space, as well as wondered out loud why we don't just use those >224.0.0.0 addresses as a stop-gap solution, but until either of those things happen, IPv6 is here and available to implement
The charge is going to be ~$4/mo/IP, hardly some dastardly money-making scheme.
This has been a long time coming and needs to happen to push IPv6 adoption further. Having tons of public IPs assigned to EC2 instances and the like isn’t good architecture either, and hasn’t been best practice since AWS inception.
It's not uncommon for medium sized companies to have a dozen accounts. Let's say you go with two AZs, with 2 NAT gateways each account that's 24 eIPs just for NAT alone. You add on top of any other services you might be hosting that might be using public facing ALBs, that's two eIPs each. It can quickly add up.
I am not saying they are trying to grab more money (I mean I don't think I need to say that), just wondering what other people's general strategy towards this, because I know I will probably have to change our architecture quite a bit.
It’s a drop in the bucket comparatively speaking to the prices for NAT Gateways and ELBs.
An immediate solution that comes to mind is to only have EIPs on your front-facing ELBs, which your services behind it operate in a private IPv6 subnet, and has an egress-only internet gateway. Now your 2 AZ solution has 2 EIPs only, and ELBs handle v4/v6 translation natively.
It’s going to be $240/month for me, or $2880/year which isn’t nothing.
https://toonk.io/aws-and-their-billions-in-ipv4-addresses/index.html
AWS seems to have over 100m IPs (100,750,168 in 2020) This could theoretically amount to close to half a billion per month in fees? I assume most of those IPs are allocated since they are charging for them to reduce use.
ISPs routinely charge $20/mo or more for static allocations, so $4/mo is still hardly a gouge. Just because they have economy of scale doesn’t mean it’s specifically for money; I’d wager if it was about drumming up more money, they could easily charge $10/mo or more and really clean house.
The low price to me seems to suggest they’re trying to encourage smarter use of a finite resource, and increase adoption of IPv6.
The price is never going to be nothing, and it’s unfortunate you have to experience that impact, but at the same time it’s amazing they’ve kept them free when assigned for as long as they have, and also it’s the nature of the game in general - systems constantly change and evolve.
My points and thoughts are more that this is about the unfortunate circumstances of change needing to happen, and much less about it being something nefarious or even egregious on the part of Amazon.
Let's say I want to host ipv6 only servers (not necessarily at AWS) what would be a good solution to redirect ipv4 traffic? I am curious how some of you are solving this. When looking on the internet the most common answer I find is to just use dual stack.
Very true, this is a problem for us as well. Any web services we host has to be dual stack, otherwise you just risk losing traffic.
We already spend an ungodly amount every month. Whats another papercut compared to the deep wounds?
You can buy and own ip blocks? I saw something about bringing your own ips, I didn't know that is a thing
You can, but the prices illustrate the scarcity that is driving moves like these. Prices are around $40 per address and above now, and the smallest block has 256 addresses.
Get ready for the return to on-prem again!
I love watching this cycle. Companies get greedy, they increase their prices claiming costs as the factor, shareholders get massive payouts as profits are y-o-y bigger, customers start to leave, so they increase prices again to cover that dip in profit.
Personally, I kept everything on-prem at work as storing petabytes in cloud is stupid expensive compared to local, let alone speed of access when you need access to a 30GB file. This doesn't affect me so I'm just going to grab my popcorn.
This isn’t greed. It’s an incentive to get people to waste less IPs. I wish they’d done this five years ago honestly.
Mind-blowing how you can just allocate eIP for free currently.
Eh, it's both really. AWS rarely increases their prices directly and this is certainly a way of making more money from existing customers. A quick back-of-the-envelope calculation based on their published ip-ranges.json file (and I hope I did the math right on that) tells me they have around 136014718 (136M) usable IPv4 addresses. Hard to say how much of those are unallocated, in use by them internally or effectively billed at a lower rate via enterprise agreements, but given one IP costs $43.8/year under this new pricing, an extra billion or two a year is almost guaranteed.
You'd still have to acquire a static ipv4 address if you do on-prem - that cost money now, hence the charge.
That's not how any of it works. If a company sees demand lowering, they will lower prices. Not to be benevolent, to make the most money. Not to mention that tech companies famously have shareholders over a barrel, with most of them not making a profit and having share classes that mean the founder has full voting power despite having a minority of shares.
I get 5 for free from VM, or BT or any other UK vendor with a business fibre account, which costs about £1300 a quarter these days. To get more in a block it's still like £20 a year each.
Getting IPv4 isn't that much of an issue. I get that when a massive org like AWS has 136m IPv4s and people waste them by not ever provisioning what they've asked for, but they could do a return to bucket if not used system if it truly was a case of waste. Instead, they're monetising them and that is because they hope people just don't bother to return the unused ones still, lining their pockets.
Let's be honest, pushing IPv6 is the true way to go, but they're not going to do that.
You say it's not about money? It's always about money when there are shareholders. Hopefully I'm just a cynical old IT guy but let's wait for profits to be posted once implemented and we can continue this conversation.
I’m not saying it’s not about the money, I’m saying it’s not because they’re seeing demand drop. If demand is dropping and you raise prices, you make LESS profit. Raising prices all other things held constant is a sign of strength for the company, that you think your demand curve is strong enough to sustain higher prices.
Of course, all things aren’t equal. Interest rates are higher. Money is no longer free, so prices that were below their actual optimal point for market share reasons are being reigned in.
I like cloud for PaaS stuff. AWS and similar levels of complexity aren't worth the effort for the stuff I do professionally and personally.
It’s funny, from my perspective using AWS is the exact opposite of complexity. I used to run a private data center and dealing with hardware and routers is way harder than just clicking some buttons to provision servers.
But even better is when you don’t have any “server”. Having an actual stateful filesystem is horrifying to me. I want to go from a git repository to a load balanced multi availability zone service/database/redis/CDN in a click.
You mean like CloudFormation?
I'm not familiar with it. A cursory look at the docs tell me that it's similar to what I'm thinking of. But it's actually still too low level for my work (web apps):
This is just the most basic sample template available. But it still includes details I don't want to think about:
Also it looks like it's built to operate on AWS's own image system and not Docker.
Compare that to Render.com's Blueprint files.
Here's an excerpt:
It's only what you care about and nothing more. And everything in your blueprint is automatically in a VPN.
Render can also host non-web services (something not possible with the biggest PaaS incumbent, Heroku). Although I believe you can only expose web services to the open internet.
You make some good points about things like IOPs and mount points not things you want to think about.
You're wrong in comparing CloudFormation to Docker though - CloudFormation is for deploying services in AWS like servers, load balancers, and many other things - like Terraform, where with Docker you still need a server to run the docker files on to begin with.
Render.com looks like it just abstracts the infrastructure layer away from Docker.
I was referring to this line:
Aren't EC2 images similar in functionality to Docker images? The rest of the file is doing non-Docker things. I was just complaining about the proprietary image format.
EC2 images are full operating systems, like a customised ISO file - really a vm image for installing the OS. Docker containers run on top of the OS using its components in a sandboxed environment
Yeah, that's a sample config for starting a standalone instance. You'd probably use ECS on Fargate if you want to deploy containerized apps -- AWS has a docker registry where you can store the images, or you can have AWS build them for you using CodeBuild. The config is similar, eg.
That looks nice.