This is silly and will further harm GCP's viability as alternative to AWS or Azure. Firstly, I can't find any official announcement regarding the rationale and suggested solutions for their customers to reduce their cost. Just adding a banner to docs pages is plain lazy and is not customer friendly.
Ideally IPv6 support should have been added or at least scheduled to be available at instance level [1] before enforcing such charges. This indicates a lack of engineering capability (more likely resource commitment) to implement such a critical feature on its platform in a timely manner, particularly given that its rivals already have the support in place. To me, that is more worrying than an increase in bill. What is the pace of innovation one can expect from GCP platform? How committed are its leaders as a public cloud service provider?
I think this nets to a < 0.01% delta to our bill. Is this really that big an issue in practice? For hobbyist projects, maybe? But for larger customers, this is a drop in the ocean.
I actually think this is a (somewhat) smart move. It incentivizes you to use a NAT gateway to egress traffic to your instances. You can either run your own fleet (it's very easy - but you gotta fix it if it breaks), or use their managed NAT solution (more expensive, but with less worry hopefully) - and not just tack on a public IP to every instance that needs internet connectivity. We did this from the get-go (running our own NATs) - and only have a few public IPs relative to the # of instances we run.
If it’s 0.01% then why should google bother with it? All it does is cost goodwill for a negligible amount of money.
We have vm external ips turned off at the org level. It feels like every day we have to explain to a new person that no, that google written tutorial doesn’t work because it assumes public ips are available. Entire services don’t work with this flag on.
The other shitty thing is it feels like at least once a month we get some email of a price increase or deprecation that causes some fire drill, and then we ask our tam to tell us the actual cost and he can’t because he has no idea it’s happening so the burden falls on us
my experince with GCP support during the free trial (with the advertising explictly saying that they provide "Technical Support for free trials") was:
1. create ticket
2. immediately receive email telling me I'm barred from free technical support and told I need to purchase a "Silver, Gold or Platinum Cloud Platform Support package"
Hah, the best part is I legitimately had to deal with GCP actually being broken (resource refused to delete) that could only be fixed by Google internally (both portal and cli returned http 500). Imagine the joy I had not having "technical support" as a benefit.
AWS support is indeed pretty crappy. $500 is not a fixed price. You pay 10% for the first 10K/month, 7% of $10K-$80K and so on. The Developer plan is 3%, but is pretty worthless - it should be renamed to rookie-plan or similar - you can get the same answers on SO for free within minutes instead of waiting days. Getting past first-level support on the Dev plan with harder technical issues takes weeks in my experience.
Setting up an inbound proxy VM that NATs all your other machines is not "difficult".
There are plenty of tutorials online for doing this with nginx or Apache, and even a junior dev ops person should be able to do this in a few hours' work.
I highly doubt this requires hiring another engineer.
It's not about the cost. Every Internet connected system(at least in cloud. Ideally every system) should be publicly accessible but instead of providing it by default they are providing it as feature. If you don't want to show VM to the world then you use NAT but they have got this backward.
This is slippery slope. One day they might charge you to open a port to external world.
"Every Internet-connected system should be publicly accessible"
That sounds like a security or data leak nightmare waiting to happen. I would prefer not entrust my data with a company that feels there's value in having all of their instances publicly addressable.
Actually, Google professes in their "BeyondCorp" security model a zero-trust architecture. You shouldn't be assuming that just because your instance isn't publicly accessible that it is secure. (See: https://cloud.google.com/beyondcorp/)
Which makes this move even more surprising, because GCP reference architectures have traditionally been focused around public facing Internet access. Unless, it is a sign that GCP is getting more traction and Google is running out of public IPs to be handing out like candy. This could be an economic incentive to encourage people to conserve these IPs.
This is not what BeyondCorp means. It doesn't mean everything is publicly accessible. It means you don't make trust decisions based on "approved networks", but instead at the device level. It DOES NOT mean that you don't segment services, restrict access to systems that don't need public access, or follow any of the other appropriate security guidelines.
> You shouldn't be assuming that just because your instance isn't publicly accessible that it is secure
No one thinks this, and no one said anything of the sort. But likewise, making everything public because Google has a site called BeyondCorp, doesn't make it secure. There is a lot of effort to adopt a BeyondCorp model. None of which includes "make everything publicly routable".
Zero-trust architecture seem nice idea, and one you can implement when you’re Google and probably spend more on security than the gross revenue of most other companies reading your whitepaper.
I think the notion most infrastructure is not publicly addressed is prevalent, even in Google, i.e. you can’t SSH to the hypervisor hosting customer instances in GCP directly, it doesn’t have SSH sat on the public internet.
Public addresses are readily available on the secondary market but a /12 probably runs somewhere around $20MM.
Charging for IPv4 seems like a move designed to make all the smallest customers who care about $3/mo leave, GCP ends up with less customers and ARPU goes up probably significantly.
If you use IAP (Google's BeyondCorp secure proxy product) then your instances don't have a public IP; they are behind a firewall rule.
Also there is a big difference between BeyondCorp's "all internal services are on the public internet" and "all instances are on the internet". You don't want to put your DB server on the internet, for example.
NAT has messed up Internet so much that people can't even ensure security without it. You have firewall for security. If we had not relied on NAT for security we would have actually configured them.
Anyways, we are gonna have to configure firewalls for IPv6 because there is no NAT.
Plus, this is chump change, but it reminded us that we really should migrate behind their NATs for outgoing traffic. I do think that they are doing this to motivate customers to reduce the IP usage as the IPv4 space is finite.
Not to detract from what you're saying about IPv6: support there is key. Azure and AWS both support IPv6.
That said, Azure charges for IPv4 external IPs. AWS does not, but I'd be surprised if the cost wasn't internally associated with ELB/ALB, EC2 instances, or other products. That is, you're still paying for it.
While elastic IPs are free for an active instance, AWS does charge for unused EIPs[1]. (You can also set a public IP on an instance, but it can change when the instance is restarted.) So if you need to hold on to an IPv4 address, it's going to cost you.
That seems like it's exactly the same model as GCP.
And I gave up on Step Functions... Probably announced at the next summit but we needed it 18 months ago... our move to AWS was beneficial with just that
Cloud NAT would be fine except it costs 4.5¢ per GB (in both directions) which could hurt some use cases. If your backend VMs pull in more than 64.8 GB per month from the Internet it's cheaper to just pay for the public IP. (Only applies to outbound connections initiated by the VM, inbound connections through load balancers don't go through the NAT.)
I'll echo what others have said - it sucks that they're doing this before adding IPv6 support. A good portion of traffic could bypass the NAT entirely considering how many services support IPv6 these days.
They don't start charging until April, so maybe they'll surprise us with an IPv6 announcement before then, but I'm not betting on it. :(
Lot of external services need whitelisted IP. And in the world of k8s and on-demand instances, NAT is pretty much the only way one can guarantee static outbound IP.
Well, it wasn't before now, since it's always been more expensive. But they're trying to sell it that way. OP's link doesn't mention it, but the email I got also announced a Cloud NAT price drop.
There's currently a $32.85 flat fee per region to use Cloud NAT (on top of the per-GB fee). They're lowering this to $1.022 per VM per month, capped at $32.12 total. (They're also capping the per-GB fee to 4.5 cents per GB worldwide, it's currently higher in some regions.)
Of course, the flat fee is peanuts for any substantial cloud project, but the fact that they announced them side-by-side means they consider Cloud NAT a way to save on this new IP charge.
Slightly off topic: how does cloud NAT scale. The defaults are way too low for request heavy projects and the regarding docs were kinda hard to understand for a non ops guy.
What defaults are you referring to? Cloud NAT is part of the GCP network fabric and all implemented as software so there's no single point of failure or bottlenecks.
This definitely limits the usefulness of Google's "always free" tier. This will x2 some bills I have for small personal projects, though will still be a bit cheaper than an AWS alternative after the 12 month free tier.
Sigh.. I suppose it was a matter of time before they figured out the pricing loophole. Back to creating new Google accounts every year to get the year of credits...
They've since updated the language to keep free tier IPs free:
> Note: Starting January 1st, 2020, GCP will introduce an additional charge for publicly addressed VM instances that don't fall under the Free Tier. You will not be charged for other publicly addressed resources, such as forwarding rules.
What's weird to me is that Google itself has excellent IPv6 support. Every Google web site, API, or other service I've come across fully supports IPv6. Compute Engine VMs are the outlier.
They actually utilize this for their "private Google access" system, which allows you to access Google services from a compute engine VM without a public v4 address. The VM's private v4 address gets mapped into an IPv6 address, along with some extra bytes identifying the customer's network. (You can see this by setting up such a VM and accessing an AppSpot app that echos your source IP.)
IPv6 is not yet that useful for external facing sites (what do people use IPv6 for on external sites?), but AWS does let you get a /56 for a VPC which should be enough for most VPC need (you can't specify your own CIDR however).
> IPv6 is not yet that useful for external facing sites
Google's NAT pricing only affects connections initiated by the VM (external load balancer traffic doesn't use the NAT). So most of this traffic is going to be your servers talking to 3rd party APIs, update servers, etc. A lot of these services support IPv6 now, meaning your NAT costs would be lower if GCE supported IPv6.
Why not? IPv6 usage is increasing every year and offers faster, simpler routing which results in better performance. Almost all mobile networks (which is about half the traffic today) use IPv6.
I recommend DO for stuff like this, they are also great a cross cloud mechanism for health checks and dashboards. Never put all your eggs in one basket.
I've still got a LowEndTalk forums special kicking around somewhere.
15 Eur per year for a 2 CPU/1GB/ipv4/1TB traffic KVM. edit...its one from alpha vps. So far so good - feel snappier than a google free vm. But that was on a deep discount special.
It's not that hard to find cheap stuff on specials if you're ok with taking a calculated risk on the providers.
If I go the cloud route I'll probably jump on a Azure of AWS intro credit plan.
Looks like the Always Free page was updated to include a free IP too, so you'll still be able to use it for free cloud hosting of small loads.
"Each month, eligible use of all of your f1-micro instances and associated external IP addresses are free until you have used a number of hours equal to the total hours in the current month" - https://cloud.google.com/free/docs/gcp-free-tier
Wasn't there last time archive.org crawled the page, so it is a new addition.
Darn. The tiny VM I have hosting my Quassel server for always-on IRC will go from approx 20 Australian cents per month to approx $4.30 per month. That's a rather large jump.
I've said this elsewhere in the thread, but Cloud NAT is kind of expensive. 4.5¢ per GB increases egress costs by 37.5% (normally 12¢ per GB) plus it applies to ingress as well, which is usually free.
Sure it doesn't apply to inbound traffic through load balancers, but if you transfer a lot of data to/from external APIs (i.e. connections by the instance) that could seriously add up.
Based on my company's usage, it will almost certainly be cheaper for us to just pay the $2.92/instance/month to keep using public V4 addresses on our GKE nodes.
This is false, no it will not. AWS charges for unassigned elastic IPs. Elastic IP can be assigned to a stopped EC2 instance and you will not incur any charges.
I thought Minecraft did support IPv6? Leastwise, I don't recall having any issues recently, although I'm still running v1.13 and atop Spigot.
I do recall some issues somewhere around 1.11-ish that required passing in the option -Djava.net.preferIPv4Stack=false. The server-ip property also needs to have any ":" escaped, e.g. "\:\:"
My question was directed to the OP's last statement of "Plus these games don't really support IPv6," because that doesn't match my experience.
My argument is that IF Google's cloud offerings supported IPv6, why would that not matter with a game like Minecraft? I'm pretty sure it supports IPv6.
EIPs are free and there is no plan to change that as far as we know today. You're thinking of the unused EIP penalty fee, which GCP and everyone else has long had an equivalent to.
Ah well except it is literally called the "always free" tier so you would think that something as core as being connected to the internet would be, you know... free?
Did they promise you'd have a static IP? 99% or more of the internet for free is behind CGN or home NAT and has little or no persisting address binding for incoming, hence ddns services. Did google distinguish as saying in the 'forever free' bucket they'd do that?
being "on" the net is not the same as being "always reachable at a stable IP endpoint"
Correct me if I'm wrong, but it sounds like they are going to charge for ephemeral IP addresses as well, not just static ones. This means any VM which accesses an external service via IPV4, i.e. making a request to a transactional mail service, will now have to pay for this privilege even if ingress is via a load balancer.
You are incorrect. They are going to begin charging a small fee for public IPs (i.e. IPs that can talk to the internet), not static IPs. They do support NAT as an alternative, but they charge for it (and are slightly lowering that cost as a part of this change).
To be clear, none of this is going to have any measurable impact on me, I'm just pointing out the fact that they didn't really hold true to the promise of the free tier.
Source: the email that they sent out to customers about this
Here's kinda the problem though: you can buy a /24 on the open market for 6.5k. If you rented out all 256 of those for 1 dollar each per month, you'd break even in a little over 2 years. Instead they sell for 2 bucks per month.
Now, either there is some huge risk that ipv6 undermines the value of ipv4 address space in that time span, or I need to start buying up /24s and renting them out.
It feels like GCP figured out a way to charge for ingress. I can get behind using NAT instead of our instances having external IP's but a 4.5¢/GB hit on egress AND ingress traffic is hard to swallow.
On another note: $7/mo for an unused static IP...???
The public instance fee feels like the plastic bag fee at the grocery store - ipv4 space is indeed finite. It is reasonable to assume it costs more to run a VM with public access than without, but to charge for it?
Previously, Windows instances required a public IP address in order to connect to and retrieve a license from Googles KMS server. Looks like that has changed recently, and this news had me worried we'd have to pay extra for our Windows instances. So at least now I can save a few pennies and IP addresses.
I find this doc confusing. In the blue box it appears that all external IPv4 addresses will be charged, but in the paragraph immediately below, it says:
> If you reserve a static external IP address but do not use it, you will be charged […]. If you reserve a static external IP address and use it […] you will not be charged for it.
This seems like two very different kinds of charges. So is Google changing its policy with just one blue box? Or is the documentation in error? I suppose it's the former but it's not clear.
Currently you're charged only for unused external IPv4 addresses.
Starting January 1st, 2020, you'll receive a bill showing how much you would pay under the new scheme that charges for all external IPs, but won't actually pay yet.
This is definition question. As example Scaleway offers free public IPv4 address, but if you don't want it, then you'll get discount. - Are they charging for it?
As cloud becomes the default for small to mid scale computing, storage and networking, the patience for hiccups due to roll your own solutions falls as well.
At times I think Google should move some of their core teams over to GCP. It seems like they dont know what they are doing. The hiring bar also appears much lower at GCP.
Makes you wonder how important Google sees GCP, or they think the train has already left...
Annoyingly expensive part of all cloud providers...
I think thats deliberate - for most businesses, the cost of networking is directly proportional to how many customers you have, whereas the cost of compute isn't so tightly coupled. Startups really care about costs to get started, and aren't so worried about costs when they have a billion customers.
I don't understand this move, over 2$ month extra for any ipv4 address?
Are we actually running out of addresses or is this a money grab kinda thing? Most of the competitors I know of offer one free ipv4, often a block of ipv6, and extra ipv4 addresses are normally only a dollar or two at most a month extra
Like many others said, this can double the cost of small projects.
> Are we actually running out of addresses or is this a money grab kinda thing?
We "ran out" some time ago. Of course, IP addresses don't get used up, so this can be defined different ways. It's no longer possible to get brand new (i.e. never used) IP addresses from the regional registries, so the only way to get a block is to buy it from another company.
Cloud companies have been buying up IPv4 space like crazy since the registries ran out. A couple years ago Amazon bought half of MIT's /8 block, and just a few weeks ago they bought a quarter of the /8 that was originally set aside for HAM radio.
So we'll never exactly "run out" per se. It's like real estate. They're not making more, but you can still buy it. It just gets more expensive. (And hopefully we eventually move to IPv6 which isn't so maddeningly restricted.)
This is cheaper than AWS EIP for instances that are using an EIP. It is free for GCP VMs to have a resevered IP and use it vs $3.60/mo for AWS EIP whether its used or not. With GCP, unused reserved IP is $7.20/mo. I can't think of a lot of scenarios where you need to hold on to an IP you're not using for an extended period of time, but I could be wrong.
EIPs are free when attached. And public addressable instances in AWS do not need an attached EIP, that's only if you want the public IP to be static and to be able to replace the instance without updating DNS records. So both are free compared to GCP's paid.
Ideally IPv6 support should have been added or at least scheduled to be available at instance level [1] before enforcing such charges. This indicates a lack of engineering capability (more likely resource commitment) to implement such a critical feature on its platform in a timely manner, particularly given that its rivals already have the support in place. To me, that is more worrying than an increase in bill. What is the pace of innovation one can expect from GCP platform? How committed are its leaders as a public cloud service provider?
1. https://googlecloudplatform.uservoice.com/forums/302595-comp...