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.
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?
1. https://googlecloudplatform.uservoice.com/forums/302595-comp...
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
IP addresses are limited and even small costs are better at forcing people to conserve limited resources than "free".
For an example, 5 cents isn't much, but charge that per plastic bag and suddenly people are using a lot fewer disposable bags.
[our customer representative] has no idea it’s happening
Why do you continue to do business with GCP if their customer service is that bad?
my experince with GCP support during the free trial (with the advertising explictly saying that they provide "Technical Support for free trials") was:
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.
Because it's a lot cheaper than AWS, whose $500/month customer service is just as bad?
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.
see https://aws.amazon.com/premiumsupport/pricing/
It takes time and energy to migrate, which is in progress
For many startups, using this more difficult but technologically sounder solution could mean hiring another engineer they can't afford.
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.
GCP has had CloudNAT for some time now. It’s a checkbox in the GUI and just works.
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.
I understand that with IPv6 you don't need NAT to fix scarcity problems, but is IPv6 technically incompatible with NAT?
Heh,
The container network ecosystem is crap because of NAT and what seems to be a lack of understanding around networking
NAT is not a firewall. Whilst NAT does not necessarily hurt security, a system that becomes unsecure if not behind NAT is not properly secured.
Firewalls are a thing. Addressable has nothing to do with what's listening for who at the other end.
Which internet standard is the source for that claim?
> Just adding a banner to docs pages is plain lazy and is not customer friendly
We will be affected by the change (our prices will drop) and we received a proactive email about them this morning.
We will also be affected and also received a proactive email this morning.
+1
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.
[1]: https://aws.amazon.com/premiumsupport/knowledge-center/elast...
It won't be the same, right? Per the article, GCP will be charging on active instances.
Oh, derp, I must have skipped past the article to the GCP page.
Not sure if I'm just misunderstanding you -- by "article" I mean "GCP documentation page", which for completeness states:
"Static and ephemeral IP addresses in use on standard VM instances
*Starting January 1st, 2020, you will be charged $0.004 per hour."
No they will charge you for addresses you don't use.
Which makes perfect sense imo.
> No they will charge you for addresses you don't use.
No, that is what they currently do. Starting January 1, 2020, they will charge you for addresses on active instances.
Current:
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
Sure, you're paying for everything you use, but the difference is when you compare costs. The less "addons" you need, the more true is the cost.
>What is the pace of innovation one can expect from GCP platform?
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.
It works! https://stackoverflow.com/questions/57058395/when-will-googl...
That's progress! Though it's sill in beta - which might be OK for a side project but does make me nervous any critical aspect of a production application. https://cloud.google.com/vpc/docs/configure-serverless-vpc-a...
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. :(
The cloud NAT is not for avoiding ip costs.
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.
> The cloud NAT is not for avoiding ip costs.
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.
You can always add additional Static IPs to Cloud NAT. The mail they sent doesn't mention any IP cost for Cloud NAT so I assume that it's free.
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...
> 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.
https://www.reddit.com/r/Android/comments/b10c71/google_play... And apparently the company's developer account if you get associated with that account.
I don't know - seems like a really good opportunity to finally kick that Google habit like I've been meaning to do ;)
Google - Like nicotine.
I will second this wholeheartedly - please proceed Google.
In regards to the downvotes:
https://www.gnu.org/proprietary/malware-google.html
It's terrifying that this joke, like all good jokes, has a kernel of truth to it.
> Back to creating new Google accounts every year to get the year of credits...
That seems really dangerous (read: good way to get all your accounts banned)
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.
Shhhhhhhhut uuuuup
Al least provide proper IPv6 support before charging for IP addresses.
GCP has marketed their amazing network so its interesting this isn't supported.
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.)
Google doesn't use GCP for its major applications. Neither should you.
GCP is like this ghetto inside of Google. Worse talent, worse network, ...
Hilarious. How poor is the talent on the GCP team that is foremost of your grievances?
Uhh, that's sort of a relevant "grievance" in a thread on GCP issues.
GCP and Infra both have very smart engineers.
Unlike AWS which needs to be good to not go out of business.
Right, because AWS isn’t part of a $900 billion market cap retail behemoth that can weather loses and no profits.
And yet IPv6 connectivity is still not available for GCE instance VMs.
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.
But then they couldn't charge you for the bandwidth.
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.
>$0.004 per hour
>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.
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.
If you were previously entirely on the free tier, what provider are you moving to that's cost-competitive even against $35 a year?
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.
Notice very few Google employees commenting in this thread?
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
> 1 free IP per account
I hope so
I'll be moving my VMs to AWS, given this almost doubles the costs of the smallest instances
Have you looked into using Cloud NAT? Do you need all those ephemeral v4 IPs?
(I work in Google Cloud Networking -- though not this particular area.)
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 seriously hurts some of my use cases: 1. Running a website on GCE 24/7 2. Running a Minecraft/CS:GO server for 10hr/day
There's no situation where I won't be paying more. Plus these games don't really support IPv6.
AWS will charge for the static IP whilst the Minecraft server is down.
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.
Really? Sorry then I had misunderstood the bill.
Why not just use an ephemeral IP?
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. "\:\:"
GCP instances don't support IPv6, so you'd have to run a load balancer or something else in front of the instance and that would have a cost.
Right. I get that.
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.
AWS is a hard sell after GCP. It feels duct-taped together in comparison, IMO, and the UI is just bad across the board.
Disclosure: ex-Googler, hold no shares in the company, GCP user.
I feel the same, but with Azure instead of GCP - compared to the inconsistent mess of AWS' UI, the Azure UI is an absolute delight.
What UI? Terraform/Infrastructure as a Code it
EIP's are 0.01/hr I think on AWS. But if you can deal with an amazon ephemeral IP you can usually get those for free.
Thats only when the EIP is not attached to a running instance. If its associated with a running instance there is no charge.
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.
If you were in the always free tier, you weren't revenue neutral, you cost google money.
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)
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.
I understood it to be a fee for static IP binding, used or reserved. Sad to be corrected (I mean, happy to be corrected but the news won't be happy)
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
Well that's bad. Thanks for clarifying and you were right from the start.
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.
Too bad K8S doesn't support IPv6 at all.
sig-network is working hard to get dual stack support in.
https://github.com/kubernetes/enhancements/issues/563
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...
That is completely untrue. Kubernetes has full support for IPv6.
https://github.com/kubernetes/enhancements/issues/508
We still want it to be promoted to beta, so it is actually available in GKE and other cloud vendors.
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..
If you can't move your workloads to a new cluster within 30 days, you should reflect on how you're using Kubernetes.
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.
https://cloud.google.com/compute/docs/instances/windows/crea...
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.
Actual billing starts April 1st, 2020.
Thats a while 9 months for them to give a free allowance of IP's (say 5 per account), support IPv6, or backtrack on the plans entirely.
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?
How about also offering ipv6 public ip for free? Then we would get higher adoption rate for ipv6
Conveniently, SRV records were eschewed from http3 which would greatly diminish the need for this.
I really hope they add one free static external ip in the always free tier.
There’s a growing number of reasons to consider exiting the major clouds.
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...
The network continues to be an annoyingly expensive part of GCP.
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.
Not all of them. Linode has very cheap network, for example.
Not a big deal, the bucks are tiny.
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
We ran out a long time ago:
http://www.potaroo.net/tools/ipv4/index.html> 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.)
And Google hasn't been buying up big blocks like that, so are probably running out, so are having to introduce a charge for them...
>And Google hasn't been buying up big blocks like that, so are probably running out
That seems like poor planning for a big cloud provider if true. IPV4 will unfortunately be around for a while
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.
Amazon EIPs are free when attached to a running VM. (Unless you have more than one attached to the same VM.)
huh? aws eip is free if you're using it on an ec2 instance