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.
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.
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.
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.
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)
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.