3 ms·

GCP doesn't support a cap, only alerts. You can use those alerts to implement your own cap mechanism, same as how it works on AWS except AWS billing is only on

GCP doesn't support a cap, only alerts. You can use those alerts to implement your own cap mechanism, same as how it works on AWS except AWS billing is only on a one hour delay I believe so I'd say AWS wins here.

runnerup 6y ago
Indeed, here is GCP's own guide which confirms what you say and provides a hacky way to implement a cap mechanism. https://cloud.google.com/billing/docs/how-to/notify#cap_disable_billing_to_stop_usage https://cloud.google.com/billing/docs/how-to/notify#cap_disa...
Agingcoder 6y ago
We talked about caps with the Google reps at my day job. The short answer was 'we can, but don't want to' (note : this may be completely unrelated to what Google thinks internally, and is just what the fairly high up the food chain rep told us)
Clewza313 6y ago
App Engine used to support caps. They're no longer supported, because for every customer pleasantly surprised, there were five customers incandescent with rage that their service had gone down at the worst possible moment due to a spike in actual demand.
- Arnt 6y ago
  Ho do you know? I can easily believe it, and I can easily believe that AWS employees have heard such stories, but I'd love to have it be more than an anecdote.
  - pydry 6y ago
    I could equally well believe that they got rid of it because it affected the quarterly earnings report and there was maybe one customer who was "incandescent with rage" that the caps they put in place worked exactly as advertised.
    - Arnt 6y ago
      Well... most cloudy limits only affect current operations. If you add a limit to the number of VMs running you might experience service degradation for a while, until you learn to cope with new peak demand by increasing your quota or being more efficient. That raging customer might well assume that because almost all limits are like that, all are, including the new S3 limit, but the S3 limit causes service degradation forever, not during peak load. The writes that failed for a while map to reads that'll fail forever, because that data isn't there. We can come up with possibilities that sound more or plausible. I'd love to hear something more factual.
dijit 6y ago
I'm using caps right now, they work- it shuts down all resources attached to the billing account if it goes over. There are many levels of alerts before it hits that though. its on the "total spend" of a billing account level though, and obviously you'd have to be a billing administrator, so to work with it would is awkward; many billing accounts across disparate projects is basically the only way.

runnerup 6y ago

Indeed, here is GCP's own guide which confirms what you say and provides a hacky way to implement a cap mechanism. https://cloud.google.com/billing/docs/how-to/notify#cap_disable_billing_to_stop_usage https://cloud.google.com/billing/docs/how-to/notify#cap_disa...

Agingcoder 6y ago

We talked about caps with the Google reps at my day job. The short answer was 'we can, but don't want to' (note : this may be completely unrelated to what Google thinks internally, and is just what the fairly high up the food chain rep told us)

Clewza313 6y ago

App Engine used to support caps. They're no longer supported, because for every customer pleasantly surprised, there were five customers incandescent with rage that their service had gone down at the worst possible moment due to a spike in actual demand.

Arnt 6y ago
Ho do you know? I can easily believe it, and I can easily believe that AWS employees have heard such stories, but I'd love to have it be more than an anecdote.
- pydry 6y ago
  I could equally well believe that they got rid of it because it affected the quarterly earnings report and there was maybe one customer who was "incandescent with rage" that the caps they put in place worked exactly as advertised.
  - Arnt 6y ago
    Well... most cloudy limits only affect current operations. If you add a limit to the number of VMs running you might experience service degradation for a while, until you learn to cope with new peak demand by increasing your quota or being more efficient. That raging customer might well assume that because almost all limits are like that, all are, including the new S3 limit, but the S3 limit causes service degradation forever, not during peak load. The writes that failed for a while map to reads that'll fail forever, because that data isn't there. We can come up with possibilities that sound more or plausible. I'd love to hear something more factual.

dijit 6y ago

I'm using caps right now, they work- it shuts down all resources attached to the billing account if it goes over. There are many levels of alerts before it hits that though. its on the "total spend" of a billing account level though, and obviously you'd have to be a billing administrator, so to work with it would is awkward; many billing accounts across disparate projects is basically the only way.