Ideally IPv6 support should have been added or at least scheduled to be available at instance level  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 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.
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
For an example, 5 cents isn't much, but charge that per plastic bag and suddenly people are using a lot fewer disposable bags.
Why do you continue to do business with GCP if their customer service is that bad?
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"
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.
This is slippery slope. One day they might charge you to open a port to external world.
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.
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.
> 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".
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.
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.
Anyways, we are gonna have to configure firewalls for IPv6 because there is no NAT.
The container network ecosystem is crap because of NAT and what seems to be a lack of understanding around networking
We will be affected by the change (our prices will drop) and we received a proactive email about them this morning.
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.
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.
That seems like it's exactly the same model as GCP.
"Static and ephemeral IP addresses in use on standard VM instances
*Starting January 1st, 2020, you will be charged $0.004 per hour."
Which makes perfect sense imo.
No, that is what they currently do. Starting January 1, 2020, they will charge you for addresses on active instances.
Static IP address (assigned but unused) $0.010/hr
Starting January 1, they add:
Static and ephemeral IP addresses in use on standard VM instances $0.004/hr
Static and ephemeral IP addresses in use on preemptible VM instances $0.002/hr
How committed are its leaders as a public cloud service provider?
Has a customer GCP for the last 3 years I am concerned about the pace of innovation.
For example, CloudFunctions still can't be put behind a VPC.
I also run another product that's built on AWS and extensively uses lambdas, and the depth and breath of the solution continues to amaze me.
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.
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...
I'd be careful doing this. You wouldn't want their automated systems to ban all your accounts + personal one by association.
That seems really dangerous (read: good way to get all your accounts banned)
> 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.
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.)
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.
>8760 hours in year so 35 USD
So much for free tier to host low traffic websites.
Good bye and thanks for all the fish! The free VM & ip was appreciated while it lasted :)
Fortunately I built everything on a Ubuntu VM...so damn near any provider works for me.
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.
"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.
My guess is they have further announcements planned, and perhaps this documentation change was inadvertantly pushed out early...
I'd be hoping to see one or more of:
* 1 free IP per account
* free shared HTTP loadbalancing
* IPv6 support
I hope so
(I work in Google Cloud Networking -- though not this particular area.)
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.
There's no situation where I won't be paying more. Plus these games don't really support IPv6.
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.
Disclosure: ex-Googler, hold no shares in the company, GCP user.
This just amplifies the truth a bit: being 24/7 on somebody else's hardware incurs costs, even if you are surprised when the bill of fare is presented
(disclaimer: I work in the internet number ecosystem so I am not un-involved)
being "on" the net is not the same as being "always reachable at a stable IP endpoint"
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
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 was supposed to be targeting 1.16, but looks like it will be in 1.17 according to https://github.com/kubernetes/enhancements/issues/508#issuec...
Alpha level cluster in GKE gets wiped every 30 days, nothing you want to run any production workload on.
Of course you have the option of self-hosting..
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?
> 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.
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.
Actual billing starts April 1st, 2020.
Makes you wonder how important Google sees GCP, or they think the train has already left...
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.
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.
We ran out a long time ago:
IANA Unallocated Address Pool Exhaustion:
Projected RIR Address Pool Exhaustion Dates:
RIR Projected Exhaustion Date Remaining Addr in RIR Pool (/8s)
APNIC: 19-Apr-2011 (actual) 0.1946
RIPE NCC: 14-Sep-2012 (actual) 0.1289
LACNIC: 10-Jun-2014 (actual) 0.0351
ARIN: 24 Sep-2015 (actual) 0.0002
AFRINIC: 08-Feb-2020 0.2940
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.)
That seems like poor planning for a big cloud provider if true. IPV4 will unfortunately be around for a while