4 ms·

It seems like a hard technical problem to shut down gracefully. But it's an easy product problem. Just suspend the account. AWS must do this already for some c

by bhntr3 10y ago

It seems like a hard technical problem to shut down gracefully. But it's an easy product problem. Just suspend the account. AWS must do this already for some cases. No one running a real business on AWS wants a hard ceiling instead of billing alerts and service by service throttling. Which Amazon has. So, this is just the nuclear option for people's pet projects. It's not a bad thing to have but I wouldn't expect it to operate any differently than what would happen if you broke the TOS and they suspended your account.

chx 10y ago
> No one running a real business on AWS wants a hard ceiling instead of billing alerts Are you sure? I'd imagine many startups would rather take a few hours of downtime over billed thousands erroneously. The latter could easily mean the end of the company but the former, when you are just striking out is not the end of the world by far.
- late2part 10y ago
  My CFO and I run a real business and we'd like this. Especially being able to constrain it by sub/child accounts and/or departments/tags.
__jal 10y ago
> No one running a real business on AWS wants a hard ceiling instead of billing alerts and service by service throttling That's absurd. Of course there are businesses that want hard ceilings. Perhaps not on their production website[1], but on clusters handed over to engineers and whatnot for projects, experimentation, etc.? I've seen these things lay around for months before they were noticed. [1] Maybe you don't consider startups 'real' enough, but I can totally imagine early stage startups wanting limits on their prod website, too. You can't save CPU cycles for later consumption.
vidarh 10y ago
> No one running a real business on AWS wants a hard ceiling instead of billing alerts and service by service throttling. Which Amazon has. I know startups that I could bankrupt with a few lines of code and a ~$60 server somewhere long before they'd be able to react to a billing alert if it wasn't for AWS being reasonably good about forgiving unexpected costs. I'm not so sure no one running a "real business" would like a harder ceiling to avoid being at the mercy of how charitable AWS feels in those kinds of situations, or when a developer messes up a loop condition, or similar. Perhaps not a 100% "stop everything costing money" option that'd involve deleting everything, but yes, some risks are existential enough that you want someone to figuratively pull the power plug out of your server on a seconds notice if you have the option.
- ec109685 10y ago
  Why don't those startups use something like cloudflare? It would stink to be at the mercy of the good graces of ddos purveyors to not attack.
  - vidarh 10y ago
    Consider API's etc.. A lot of businesses have needs where putting CloudFlare in between would be just as likely to block legitimate use. I love CloudFlare, and use it a lot, but it's not a panacea.
- bhntr3 10y ago
  I meant a business that makes significant revenue and has enough users that downtime or data loss would be unacceptable. If you can't afford downtime you probably can afford to wait for the alert and choose your own mitigation strategy. A system that can't tolerate downtime probably has an on-call rotation and these triggers ought to be reasonably fast. If you can't react or can't afford to react, you probably can afford some downtime / data loss. So the system doesn't need to have granular user defined controls. Just two modes. That was my point. I think I triggered people with the phrase "real business" and I apologize for that.
  - vidarh 10y ago
    > If you can't afford downtime Only a tiny fraction of businesses can't afford downtime. A lot of businesses claim they can't afford downtime, yet don't insure against it, and don't invest enough in high availability to be able to reasonably claim they've put in a decent effort to avoid it. In most cases I've seen of businesses that claim they "can't afford downtime", they quickly balk if you present them with estimates of what it'd cost to even bring them to four or five nines of availability. > A system that can't tolerate downtime probably has an on-call rotation and these triggers ought to be reasonably fast. A lot of such systems can still run up large enough costs quickly enough that it's a major problem. > If you can't react or can't afford to react, you probably can afford some downtime / data loss. I'd say it is the opposite: Those who can afford to react are generally those with deep enough pockets to be able to weather an unexpected large bill best. Those who can't afford to react are often those in the worst position to handle both the unexpected bill and the downtime / data loss. But of the two, the potential magnitude of the loss caused by downtime is often far better bounded than the potential loss from a crazily high bill.
zwischenzug 10y ago
Plenty of teams will want this for dev/test.

by bhntr3 10y ago

chx 10y ago

> No one running a real business on AWS wants a hard ceiling instead of billing alerts Are you sure? I'd imagine many startups would rather take a few hours of downtime over billed thousands erroneously. The latter could easily mean the end of the company but the former, when you are just striking out is not the end of the world by far.

late2part 10y ago
My CFO and I run a real business and we'd like this. Especially being able to constrain it by sub/child accounts and/or departments/tags.

__jal 10y ago

> No one running a real business on AWS wants a hard ceiling instead of billing alerts and service by service throttling That's absurd. Of course there are businesses that want hard ceilings. Perhaps not on their production website[1], but on clusters handed over to engineers and whatnot for projects, experimentation, etc.? I've seen these things lay around for months before they were noticed. [1] Maybe you don't consider startups 'real' enough, but I can totally imagine early stage startups wanting limits on their prod website, too. You can't save CPU cycles for later consumption.

vidarh 10y ago

> No one running a real business on AWS wants a hard ceiling instead of billing alerts and service by service throttling. Which Amazon has. I know startups that I could bankrupt with a few lines of code and a ~$60 server somewhere long before they'd be able to react to a billing alert if it wasn't for AWS being reasonably good about forgiving unexpected costs. I'm not so sure no one running a "real business" would like a harder ceiling to avoid being at the mercy of how charitable AWS feels in those kinds of situations, or when a developer messes up a loop condition, or similar. Perhaps not a 100% "stop everything costing money" option that'd involve deleting everything, but yes, some risks are existential enough that you want someone to figuratively pull the power plug out of your server on a seconds notice if you have the option.

ec109685 10y ago
Why don't those startups use something like cloudflare? It would stink to be at the mercy of the good graces of ddos purveyors to not attack.
- vidarh 10y ago
  Consider API's etc.. A lot of businesses have needs where putting CloudFlare in between would be just as likely to block legitimate use. I love CloudFlare, and use it a lot, but it's not a panacea.
bhntr3 10y ago
I meant a business that makes significant revenue and has enough users that downtime or data loss would be unacceptable. If you can't afford downtime you probably can afford to wait for the alert and choose your own mitigation strategy. A system that can't tolerate downtime probably has an on-call rotation and these triggers ought to be reasonably fast. If you can't react or can't afford to react, you probably can afford some downtime / data loss. So the system doesn't need to have granular user defined controls. Just two modes. That was my point. I think I triggered people with the phrase "real business" and I apologize for that.
- vidarh 10y ago
  > If you can't afford downtime Only a tiny fraction of businesses can't afford downtime. A lot of businesses claim they can't afford downtime, yet don't insure against it, and don't invest enough in high availability to be able to reasonably claim they've put in a decent effort to avoid it. In most cases I've seen of businesses that claim they "can't afford downtime", they quickly balk if you present them with estimates of what it'd cost to even bring them to four or five nines of availability. > A system that can't tolerate downtime probably has an on-call rotation and these triggers ought to be reasonably fast. A lot of such systems can still run up large enough costs quickly enough that it's a major problem. > If you can't react or can't afford to react, you probably can afford some downtime / data loss. I'd say it is the opposite: Those who can afford to react are generally those with deep enough pockets to be able to weather an unexpected large bill best. Those who can't afford to react are often those in the worst position to handle both the unexpected bill and the downtime / data loss. But of the two, the potential magnitude of the loss caused by downtime is often far better bounded than the potential loss from a crazily high bill.

zwischenzug 10y ago

Plenty of teams will want this for dev/test.