5 ms·

> the large cloud providers have clearly indicated by their actions that they’re simply not interested in implementing hard cost circuit breakers. I agree, my

> the large cloud providers have clearly indicated by their actions that they’re simply not interested in implementing hard cost circuit breakers. I agree, my term for this is “bad faith”. I recently had a free $200 credit for Azure. I setup their default MariaDB instance for a side project, figuring I’d get my feet wet with Azure. I didn’t spend time evaluating the cost bc I figured, how much could the default be if I haven’t cranked up the instance resources at all? Turns out the answer is more than $10/day which I discovered when authentication failed to my test DB. Back to Digital Ocean.

ghaff 5y ago
My term for it is “you’re not their use case.” For better or worse, they’ve prioritized usages that would much rather have an unexpected few thousand dollar bill than have services paused or shutdown unexpectedly.
- civilized 5y ago
  But computers can behave differently based on user choice. Right? So there could be a user option to cut service beyond a fixed spend. It wouldn't be hard to implement, and tons of people would use it. They don't do it. It's not a tragic case of priority and limited engineering resources. They like surprise bills, just like hospitals do. Businesspeople love it when you come to their service and click through their Russian novel of a service agreement that would take a team of lawyers to parse. Once you do that, your money belongs to them! It's their court, their rules! They love it!
  - nucleardog 5y ago
    > It wouldn't be hard to implement, and tons of people would use it. They don't do it. Please describe to me, in detail, how this works. Because every time this comes up everyone claims it's the easiest thing in the world, but if you try and drill into it what they end up actually wanting is generally "pay what you want" cloud services. There are a _ton_ of resources on AWS that accrue on-going costs with no way to turn them off. A "hard circuit breaker" that brings your newly accruing charges to zero needs to not just shut down your EC2 instances, but delete your EBS volumes, empty your S3 buckets, delete your encryption keys, delete your DNS zones, stop all your DB instances and delete all snapshots and backups, etc, etc. The only people I see using a feature like this are some individuals doing some basic proof-of-concept work and... a bunch of people that are going to turn it on not understanding the implications and then when they get a burst of traffic that wipes out their AWS account they're going to publish angry blog posts about how AWS killed their startup. If, like most people, you don't want literally everything to disappear the first time your site gets an unexpected traffic spike, you can already do this by setting up a response tailored to your workload--run a lambda in response to billing alerts that shuts down VMs, or stops your RDS instance but leaves the storage, etc.
    - void_mint 5y ago
      > Because every time this comes up everyone claims it's the easiest thing in the world, but if you try and drill into it what they end up actually wanting is generally "pay what you want" cloud services. Why is it on any (usually a relatively new) user to define how an entire cloud should behave? Users are asking for a feature that helps them stop accidentally spending more than they intended. This feature request is totally fair. Implementing such a feature would be an act of good faith towards new/onboarding users (also obviously just any user with a very specific budget use-case). > The only people I see using a feature like this are some individuals doing some basic proof-of-concept work and... Yes exactly. GCP offers sandboxed accounts for this exact purpose. Why is this such a far reach? > setting up a response tailored to your workload--run a lambda in response to billing alerts that shuts down VMs, or stops your RDS instance but leaves the storage, etc. If you're telling every individual user that falls into a specific category to build a specific set of infrastructure, why is it not acceptable to you to just ask AWS to build it?
      - thinkharderdev 5y ago
        I think the sandbox idea is a great one. They should just do away with the free tier entirely except for sandbox accounts in which everything just gets shut down the second you go over the free allowance. If you want to build something for real then you pay for whatever resources you use, but if you just want to tinker around and learn a few things then you can get a safe sandbox to do it in. BUT, I think the parent's point is that such a feature would actually be quite complicated. It's not just a matter of saying "I only want to spend $X in this account per month/total" but defining exactly what you want to do in the case where you hit that limit. Shut everything down? My guess is almost nobody would want to do that. So it ends up being some complicated configuration where you have to deeply understand all of the services and their billing models in order to configure it in the first place. What are the odds that the student who accidentally spins up 100 EC2s for a school project is going to configure this tool correctly? But I do think the sandbox would be great. Either you are a professional in which case it is your responsibility to manage your system and put in appropriate controls to prevent huge unexpected bills or you are a student (in the general sense of someone learning AWS, not necessarily just someone in school) in which case they provide a safe environment for you to experiment.
- deleted 5y ago
  [deleted]
whoknew1122 5y ago
It's not bad faith. It's 'providing the resources you signed up for'. Does it mean you have to go into your planning with more consideration as to cost? Yeah. But how would you feel if your start-up finally goes viral, you're having your best day ever, and then your app just stops working because someone forgot to remove a hard spend limit? Most people would rather see their app continue running. And what does turning off the lights look like? If your database hits your cost limit, do you stop serving requests? Delete the data? To what extent do you want 'cost protection' for resources you signed up for?
- imwillofficial 5y ago
  It’s not unreasonable to ask for a mechanism to not be billed thousands unexpectedly. Cloud billing is not easy to understand. I would know, I work for the part of AWS that calculates people’s bills.
  - whoknew1122 5y ago
    It's not rocket science, either. I would know, I work for premium support. Every time I see an unexpected bill of thousands of dollars, it's because the customer poorly architected their infrastructure. People seemingly want the freedom of complete control without the responsibility that comes with having that much control.
    - deleted 5y ago
      [deleted]
- nlitened 5y ago
  > If your database hits your cost limit, do you stop serving requests? Delete the data? To what extent do you want 'cost protection' for resources you signed up for? Sounds like a reasonable configurable option rather than “you shouldn’t be able to choose at all”.
  - eropple 5y ago
TriNetra 5y ago
Yes in some cases the default is quite expensive – the same was there with SQL Azure (though they have changed that recently) and it had created a good amount of bill for us (though for their credit, Azure did refund in all such occasions because we didn't use the capacity at all). However, I don't know why the alert system doesn't have an option to say "here's my budget, alert me as soon as when my daily pace is set to exceed the monthly budget" instead, you have % of budget amount consumed based alerts, like you can get email if you say 50% of my budget is consumed, which happens every month so kinds of defeat the purpose of an alert. We ended up creating a simple solution (cloudalarm.in – in beta) that provides such budgeted pace based alert and more ways to get instant alert which isn't possible with usage based alerts.

ghaff 5y ago

My term for it is “you’re not their use case.” For better or worse, they’ve prioritized usages that would much rather have an unexpected few thousand dollar bill than have services paused or shutdown unexpectedly.

civilized 5y ago
But computers can behave differently based on user choice. Right? So there could be a user option to cut service beyond a fixed spend. It wouldn't be hard to implement, and tons of people would use it. They don't do it. It's not a tragic case of priority and limited engineering resources. They like surprise bills, just like hospitals do. Businesspeople love it when you come to their service and click through their Russian novel of a service agreement that would take a team of lawyers to parse. Once you do that, your money belongs to them! It's their court, their rules! They love it!
- nucleardog 5y ago
  > It wouldn't be hard to implement, and tons of people would use it. They don't do it. Please describe to me, in detail, how this works. Because every time this comes up everyone claims it's the easiest thing in the world, but if you try and drill into it what they end up actually wanting is generally "pay what you want" cloud services. There are a _ton_ of resources on AWS that accrue on-going costs with no way to turn them off. A "hard circuit breaker" that brings your newly accruing charges to zero needs to not just shut down your EC2 instances, but delete your EBS volumes, empty your S3 buckets, delete your encryption keys, delete your DNS zones, stop all your DB instances and delete all snapshots and backups, etc, etc. The only people I see using a feature like this are some individuals doing some basic proof-of-concept work and... a bunch of people that are going to turn it on not understanding the implications and then when they get a burst of traffic that wipes out their AWS account they're going to publish angry blog posts about how AWS killed their startup. If, like most people, you don't want literally everything to disappear the first time your site gets an unexpected traffic spike, you can already do this by setting up a response tailored to your workload--run a lambda in response to billing alerts that shuts down VMs, or stops your RDS instance but leaves the storage, etc.
  - void_mint 5y ago
    > Because every time this comes up everyone claims it's the easiest thing in the world, but if you try and drill into it what they end up actually wanting is generally "pay what you want" cloud services. Why is it on any (usually a relatively new) user to define how an entire cloud should behave? Users are asking for a feature that helps them stop accidentally spending more than they intended. This feature request is totally fair. Implementing such a feature would be an act of good faith towards new/onboarding users (also obviously just any user with a very specific budget use-case). > The only people I see using a feature like this are some individuals doing some basic proof-of-concept work and... Yes exactly. GCP offers sandboxed accounts for this exact purpose. Why is this such a far reach? > setting up a response tailored to your workload--run a lambda in response to billing alerts that shuts down VMs, or stops your RDS instance but leaves the storage, etc. If you're telling every individual user that falls into a specific category to build a specific set of infrastructure, why is it not acceptable to you to just ask AWS to build it?
    - thinkharderdev 5y ago
      I think the sandbox idea is a great one. They should just do away with the free tier entirely except for sandbox accounts in which everything just gets shut down the second you go over the free allowance. If you want to build something for real then you pay for whatever resources you use, but if you just want to tinker around and learn a few things then you can get a safe sandbox to do it in. BUT, I think the parent's point is that such a feature would actually be quite complicated. It's not just a matter of saying "I only want to spend $X in this account per month/total" but defining exactly what you want to do in the case where you hit that limit. Shut everything down? My guess is almost nobody would want to do that. So it ends up being some complicated configuration where you have to deeply understand all of the services and their billing models in order to configure it in the first place. What are the odds that the student who accidentally spins up 100 EC2s for a school project is going to configure this tool correctly? But I do think the sandbox would be great. Either you are a professional in which case it is your responsibility to manage your system and put in appropriate controls to prevent huge unexpected bills or you are a student (in the general sense of someone learning AWS, not necessarily just someone in school) in which case they provide a safe environment for you to experiment.
deleted 5y ago
[deleted]

whoknew1122 5y ago

It's not bad faith. It's 'providing the resources you signed up for'. Does it mean you have to go into your planning with more consideration as to cost? Yeah. But how would you feel if your start-up finally goes viral, you're having your best day ever, and then your app just stops working because someone forgot to remove a hard spend limit? Most people would rather see their app continue running. And what does turning off the lights look like? If your database hits your cost limit, do you stop serving requests? Delete the data? To what extent do you want 'cost protection' for resources you signed up for?

imwillofficial 5y ago
It’s not unreasonable to ask for a mechanism to not be billed thousands unexpectedly. Cloud billing is not easy to understand. I would know, I work for the part of AWS that calculates people’s bills.
- whoknew1122 5y ago
  It's not rocket science, either. I would know, I work for premium support. Every time I see an unexpected bill of thousands of dollars, it's because the customer poorly architected their infrastructure. People seemingly want the freedom of complete control without the responsibility that comes with having that much control.
  - deleted 5y ago
    [deleted]
nlitened 5y ago
> If your database hits your cost limit, do you stop serving requests? Delete the data? To what extent do you want 'cost protection' for resources you signed up for? Sounds like a reasonable configurable option rather than “you shouldn’t be able to choose at all”.
- eropple 5y ago

TriNetra 5y ago

Yes in some cases the default is quite expensive – the same was there with SQL Azure (though they have changed that recently) and it had created a good amount of bill for us (though for their credit, Azure did refund in all such occasions because we didn't use the capacity at all). However, I don't know why the alert system doesn't have an option to say "here's my budget, alert me as soon as when my daily pace is set to exceed the monthly budget" instead, you have % of budget amount consumed based alerts, like you can get email if you say 50% of my budget is consumed, which happens every month so kinds of defeat the purpose of an alert. We ended up creating a simple solution (cloudalarm.in – in beta) that provides such budgeted pace based alert and more ways to get instant alert which isn't possible with usage based alerts.