3 ms·

> BUT, I think the parent's point is that such a feature would actually be quite complicated. Sure, but so is making a cloud. Putting the onus of defining a fe

> BUT, I think the parent's point is that such a feature would actually be quite complicated. Sure, but so is making a cloud. Putting the onus of defining a feature like this on users, only after hearing their request ("I want to control my spend"), is IMO unfair.

thinkharderdev 5y ago
Not complicated as in "too hard for AWS to build" but complicated as in "really hard to use as someone trying to limit your spend on AWS." So the people most at risk of huge unexpected bills are also not going to be the people knowledgable enough to setup the billing cap correctly. So it would mostly be a feature for enterprises and most enterprises would rather just pay the extra $ rather than potentially turn off a critical system or accidentally delete some user data. I worked at a company that spent ~$10m per month on AWS. We had a whole "cloud governance" team who built tools to identify both over and underutilized resources. But they STILL never cut any thing off automatically. The risk/reward ratio just wasn't there. You make the right call and shave $10k off a $10m bill every month, but the one time you take down a mission critical service, you give all of that back and then some.
- void_mint 5y ago
  > So the people most at risk of huge unexpected bills are also not going to be the people knowledgable enough to setup the billing cap correctly Yes, which is why AWS builds it. > . So it would mostly be a feature for enterprises and most enterprises would rather just pay the extra $ rather than potentially turn off a critical system or accidentally delete some user data. It would be mostly not Enterprises IMO
- BackBlast 5y ago
  I've been there. I shut down a bunch of what looked like idle instances doing nothing to reduce spend. 80% of which were, in fact, doing nothing. I did drop off two vms that were supporting critical infrastructure. Everyone who had done any work on them was long gone. I had done my due diligence to identify what they could possibly be. Still, the day of reckoning came, and we got calls of services down a week after I turned them off. I spun them back up, and they were going again without any real impact to the business. This turned out to be a blessing as the very next week the cert these same services depended on expired and if I hadn't learned about the system by turning them off we never would have known which boxes held up those services. Also a lesson in what happens when people leave without any documentation on where the work they did lives and how it works.

thinkharderdev 5y ago

Not complicated as in "too hard for AWS to build" but complicated as in "really hard to use as someone trying to limit your spend on AWS." So the people most at risk of huge unexpected bills are also not going to be the people knowledgable enough to setup the billing cap correctly. So it would mostly be a feature for enterprises and most enterprises would rather just pay the extra $ rather than potentially turn off a critical system or accidentally delete some user data. I worked at a company that spent ~$10m per month on AWS. We had a whole "cloud governance" team who built tools to identify both over and underutilized resources. But they STILL never cut any thing off automatically. The risk/reward ratio just wasn't there. You make the right call and shave $10k off a $10m bill every month, but the one time you take down a mission critical service, you give all of that back and then some.

void_mint 5y ago
> So the people most at risk of huge unexpected bills are also not going to be the people knowledgable enough to setup the billing cap correctly Yes, which is why AWS builds it. > . So it would mostly be a feature for enterprises and most enterprises would rather just pay the extra $ rather than potentially turn off a critical system or accidentally delete some user data. It would be mostly not Enterprises IMO
BackBlast 5y ago
I've been there. I shut down a bunch of what looked like idle instances doing nothing to reduce spend. 80% of which were, in fact, doing nothing. I did drop off two vms that were supporting critical infrastructure. Everyone who had done any work on them was long gone. I had done my due diligence to identify what they could possibly be. Still, the day of reckoning came, and we got calls of services down a week after I turned them off. I spun them back up, and they were going again without any real impact to the business. This turned out to be a blessing as the very next week the cert these same services depended on expired and if I hadn't learned about the system by turning them off we never would have known which boxes held up those services. Also a lesson in what happens when people leave without any documentation on where the work they did lives and how it works.