There’s many ways to reduce cloud costs. Doing so has become something of a fine industry art – witness the rise of finops: “an operational framework and cultural practice to maximise the business value of cloud.”
Adjusting instance sizes, optimising data transfer routes, deploying a mix of reserved and spot instances, rethinking what services you use for storage; all these are either established practices or becoming them at most enterprise cloud customers, as is finessing Kubernetes auto-scaling.
Snapping up thin-on-the-ground IPv4 addresses is something of a blunt tool, but apparently one that some enterprises are also now deploying…
MongoDB buys up IPv4 addresses
MongoDB, for example, is splashing out $25 million this coming quarter to buy IPv4 addresses “which will allow us to further reduce our cloud infrastructure costs in the future” as CFO Michael Gordon recently put it.
The move comes after AWS, as of February 2024, started charging $0.005 per IP per hour for all public IPv4 addresses (think resources like NAT Gateway, EC2 Instance, Load balancer, VPN) at $0.005/IP/hour, following the other hyperscalers in charging for a shrinking pool of IPv4 addresses.
The move by MongoDB to buy its own IPv4 reserve pool effectively protects it from being forced to purchase these down the line in an ad hoc manner.
That will, someone close to the deal told The Stack, reduce exposure to pricing fluctuation or changes in Ts&Cs imposed by the hyperscalers. This also enables MongoDB to rapidly provide IPv4 addresses to customers on-demand, reducing any reliance or dependency on the cloud provider.
It also ensures MongoDB can continue to absorb such costs, preventing any cost to the customer, they added, at a time when cloud SaaS spending is under increased scrutiny. Very good of them and no doubt a savvy move, for those with access to cash they can throw at this problem at this scale.
Move to IPv6! It's not that easy...
But the deal emphasises what the pain that many major cloud users are facing when it comes to IPv4 prices, which can jack up costs significantly. AWS and the other cloud providers have sold this as a wonderful opportunity to adopt much more widely available and FREE IPv6 instead.
A simple win? Not quite...
As one IT infrastructure specialist has noted in a tidy breakdown published in late 2023, users can go dual-stack, which means configuring IPv4 and IPv6 addresses on all systems, or IPv6-only internally, with IPv4 connectivity only where facing the general public – for example on the CDN.
As the White House itself put it [pdf] back in 2020 "it has become clear that [running dual-stack] is overly complex to maintain and unnecessary. As a result, standards bodies and leading technology companies began migrating toward IPv6-only deployments, thereby eliminating complexity, operational cost, and threat vectors..."
As the IT specialist, who posts as @apparentorder noted: "The underlying [AWS] IPv6 support [for EC2] is excellent. It’s possible to configure IPv6-only EC2 instances in IPv6-only subnets and everything works fine, including local DNS, time service, host configuration, security and all the stuff to be expected in an IPv6-enabled network. Components like VPN, Transit Gateway, Direct Connect and Network Firewall also support IPv6.
"The problem is actually using all the (other) Amazon Web Services... It’s practically impossible to run IPv6-only. Trying to configure core services like API Gateway, Lambda, ECS or App Runner into IPv6-only subnets makes them either sternly refuse those subnets or throw comically sad error messages like Not enough IP space available (Elastic Load Balancer)" they added.
Their post was in late 2023 and AWS is grinding into action on a few fronts: In early August 2024, for example, it announced the general availability of private IPv6 addressing for VPCs and subnets.
But as cloud economist Corey Quinn put it earlier this year, the IPv4 charges would be "less galling if AWS didn’t have a sad, sad level of coverage for pure IPv6 stacks among their own services. In turn that makes it feel a lot less like [an] aspirational thing... and a lot more like a nakedly transparent cash grab. They had six months [now 12+] to shore up v6 coverage–and they failed to do so."
And those taking a look at its list of AWS services that support IPv6 will see that it remains very, very patchy.
Strong views on all of this, or tips? Pop us a line.
