| > S3 data..? Delete it. O_o > ... Make it read only. The primary use-case of s3 is reading objects. This would not be a deterrent for quite a few use-cases > ... Pretend to delete it, but make recovery possible for x days. Still consumes the space that they're charging for in the first place > People who want a cap are going to more concerned with the overspend than any data or service integrity. This is patently not true, and is why I think you don't really grok why implementing a cap is difficult. It's specifically why I said "everyone would demand different behaviour at the cap". Some would want only this or that service to stop, for example. A small business sets up a payment cap and hits that cap because they went viral? BAM, all their block storage, destroyed. All their backups, their analytics, their RDS databases, just gone. Right at the time they needed it most.That's a much harder lesson to deal with than "oops, our bill's a bit high because we made a mistake, can you please forgive it?". Or even "ouch, okay we'll pay it". The protection you want for hobbyists would destroy small businesses that may not understand what is actually meant when that hard cap is hit. It's not that caps aren't doable at all, it's just that they're a wicked problem, and the more you look at it, the more issues you can see. As for soft caps, what is the functional difference between a soft cap and the billing warnings they already have? Also, their claim on s3 is "we don't lose objects". Destroying objects because of billing would utterly undermine that claim. > If your payment methods gets declined I'm prepared to bet Amazon don't just let all your services continue running indefinitely because shutting them down automatically is too hard of a problem for them to solve. AWS does not destroy your services because of late payment. Source: we've just been in late payment. |
Are you serious? This would mean Azure is not fit for business:
https://docs.microsoft.com/en-us/azure/billing/billing-spend...
When your usage results in charges that exhaust the monthly amounts included in your offer, the services that you deployed are disabled for the rest of that billing month. For example, Cloud Services that you deployed are removed from production and your Azure virtual machines are stopped and de-allocated. To prevent your services from being disabled, you can choose to remove your spending limit. When your services are disabled, the data in your storage accounts and databases are available in a read-only manner for administrators. At the beginning of the next billing month, if your offer includes credits over multiple months, your subscription will be re-enabled. Then you can redeploy your Cloud Services and have full access to your storage accounts and databases.
The decision not to implement this in AWS has nothing to do with technical issues - they can all be solved in this way or another.