Google Cloud customer wakes up to $18,000 bill despite $7 budget
tomshardware.com
tomshardware.com
I (a hobbyist running a small side project for a dollar or two a month in normal usage, so my account is marked as "individual") got hit with a ~$17,000 bill from Google cloud because some combination of key got leaked or my homelab got compromised, and the attacker consumed tens of thousands in gemini usage in only a few hours. It wasn't even the same Google project as for my project, it was another that hasn't seen activity in a year+.
Google refuses to apply any adjustments, their billing specialist even mixed up my account with someone else, refuses to provide further information for why adjustments are being rejected, refuses any escalation, etc. I already filed a complaint with the FTC and NYS attorney General but the rep couldn't care any less.
My gripe is not that the key was potentially leaked or compromised or similar and then I have to pay as a very expensive "you messed up" mistake, it's that they let an api key rack up tens of thousands in maybe 4 hours or so with usage patterns (model selection, generating text vs image, volume of calls, likely different IP and user agent and whatnot). That's just predatory behavior on an account marked as individual/consumer (not a business).
This current cloud paradigm of charging indefinitely is insane for normal consumers and many businesses.
Right now there are about 4 concurrent threads on the googlecloud subreddit about people getting hosed with life changing bills. Some no doubt through stupid mistakes (happens), but still bewildering that Google is insisting individuals like students are subject to the same scale to infinity bills as huge corporations and are unwilling to provide any mechanism to protect hobbyists.
And then people tell you but there are quotas and then:
>Google automatically upgraded it to the next level when the account crossed the $1,000 threshold during the incident.
Predation, pure and simple.
Google doesn't care, no one is holding them responsible for predatory behavior. It's profitable to steal from your customers and there's no downside to doing so.
What idiot lawmaker would allow a system where you can sign up without a computer, phone or fax, but then need these media to cancel what you just signed up for?
This has changed since I had mine as I had the membership around 30 years ago, but they still in general do not allow cancellation at the physical location. You must write to them.
Edit: I just read that they all transitioned to LA Fitness now, and I'm not sure what their policies are but Bally's, while unethical and infamous, were not illegal as far as I know.
For every story about a mistake in the tens of thousands, I wonder how many there are in the single-thousands, hundreds and even tens where people just suck it up and pay the bill. When you provide such a limited billing support surface, employ a thousand lawyers in-house, and hold as many cards as Google does (losing my G account would ruin my year).
Multinational service providers need better regulation to ensure consumers' rights are protected. In the UK utilities and banks have to absorb (or insure) against some leaks, theft and external fraud. If Google (and others!) were subjected to similar regulation, problems like this would evaporate overnight.
I understand that $18k is probably a drop in the bucket, but surely there's a middle ground here.
Things like this are the exact reason that companies end up having to comply with all kinds of regulations. It's just easier to screw the customer first.
If they weren't turned off at the billing cap, but were given some leeway instead, either that becomes the new hard limit, or GCP will have to give away the difference.
And there's no "middle ground" you could implement that makes sense either - like a "frozen" state. Preventing new writes to a GCS bucket breaks the writer app. Freezing VMs serving web traffic takes the site down.
Even if the service was shut down once the billing limit is hit, how long would GCP wait for the user to add funds or raise the limit? GCP would need to either keep the services in a hidden/frozen state or not turn them off / freeze them at all (in which case GCP would be giving away resources for free).
Maybe GCP can give users a heads-up when they're about to hit the limit? GCP already does - billing alerts do exist. It's just possible to blow past them if your usage is a massive spike.
Moreover, getting the hundreds of GCP services to implement a "frozen" state is difficult. It's hard enough getting everyone to listen to the "billing account disabled" signal, and (soft-)delete the resources (based on the resource, after some time interval). Given these billing overruns happen for smaller customers, it's not really worth solving the problem - which I don't think has a great solution to begin with.
That's why you make it opt in with suitable disclaimers about data loss from deletions (a warning which btw GCP already shows you when you disable billing on an active project).
I'd say the average person is well positioned to determine whether they're a broke student that can't afford a $1000 surprise or a corporation that needs reliability above all.
Those customers that would rather get a surprise $18,000 bill than have their servers stopped or data nuked, can simply not enable the spending limit.
There is better option here, but google won't as it will hurt their incentive to take more money from customer.
And yet this is exactly what happens if you exceed a quota limit, which aren't always well signposted and sometimes require days to get the limit raised. I've experienced multiple hours-long outages due to hitting GCP quotas we didn't know existed.
With that said, when you go to set a budget it warns you "Setting a budget does not cap resource or API consumption. Learn more." with a hyperlink to https://docs.cloud.google.com/billing/docs/how-to/budgets?_g...
The service page should read “we can charge you an unlimited amount at any time if you make a technical mistake”
The fact that google redefine what budget means and put a warning doesn't make it ok.
I recently turned a couple things on in google cloud and I was under the impression that the budget was a hard limit, not an email notify system.
If this is true I must seriously rethink my plan for marketing, and throttle on my own website somehow.
* By clicking here you agree to kill it
And you're defending that?
The article, and the comment I was replying to, make it seem like an error in the Google Budget system. I'm simply trying to say this system is working as designed and documented.
You'll all keep using them either way.
Yes nuclear option, but I’ll take an hour down time over a $100k unexpected bill
As author of HashBackup, I know people are using it with GCS, and I'd like to be able to test against it, but not enough to swallow a large surprise Google bill.
EDIT: I guess that you'd still be responsible for the charges though.
If I, not having their budget or engineers, can have pretty much instant Prometheus event reacting to metrics, surely it wouldn't be too hard for them to have triggers like this -- somehow their AI can automatically ban people based on something, can't they do something for the customers?
They can, just don't want to.
And the system automatically upgraded them to higher spending limits when they crossed the $1000 in usage costs.
They could definitely make that an opt-in feature.
Also, if implementing a cap is a desired feature that justifies trade-offs to be made, then it is psosible to translate the budget cap (in terms of money) back into service-specific caps that are easier to keep consistent. Such as "autoscale this set of VMs" and "my budget cap is $1000/hour", with the VM type being priced at $10/hour, translated to "autoscale to at most 100 instances". That would need dev work (i.e. this feature being considered important) and would not respect the budget cap in a cross-service way automatically, but still it is another piece in the puzzle.
Also, doing this on a per-service basis doesn't seem that far-fetched to me, so you'd only kill that service and get at least some chance that the rest of your system remains usable.
If you have an actual enforced cap, those services will be disabled until you resolve the cap - which depending on the latency for usage updates, may be hours after you pass the cap, and hours after you resolve the issue.
Or you have ‘warnings’, and your services keep working, but you spend more $$.
Previously, people seemed to be more worried about service outages than raw $$. Now it’s the other way around.
It’s a common issue with disk quotas in on-prem systems too, and they tend to cause a lot of similar types of problems in both directions.
But a big part of the value in large clouds like GCP is the network's interconnectedness. Plus even if there was some global event that made communications impossible only for the billing service, I'd still expect charges to top out roughly proportional to the number of partitions as they each independently exceed the threshold. GCP only has 120ish zones.
Deleting those when a customer hits a limit will lose customer data or remove things that might be hard to add back. The "I hit my AWS limit and they deleted all my data" headlines will result.
and excluding those things makes the limit soft again..
(Generally, tech seems to skate by on creating insanely complicated things, knowing that given enough pain, people will start blogging about their solutions, ie effectively outsourcing the cost and effort of doing something about it.)
We essentially don’t have monopoly enforcement in the US anymore