5 ms·

TBH, the real problem is AWS bills cannot be capped in any way (you can setup an alarm, though). It's unreasonable to expect a programmer won't make mistakes.

by nitely 7y ago

manigandham 7y ago
Of course they can be capped, you just turn off the services. If you're asking them to automate that for you, then the counterpoint would be people accidentally setting a budget that wipes out their resources and complaining about that. Easier for both sides to just ask AWS for a refund if there's a reasonable case.
- nicoburns 7y ago
  > the counterpoint would be people accidentally setting a budget that wipes out their resources and complaining about that. This wouldn't be an issue if it was configurable.
  - manigandham 7y ago
    Mistakes will always be an issue. How you recover is more important. Would you rather make a mistake leading to a big bill with the possibility of a refund or set your max budget and have your resources permanently deleted?
    - nicoburns 7y ago
      There would be no need to delete existing resources. Just prevent me from creating new ones until action is taken. For small projects in particular, I'd much rather have service taken offline and an email notification than even a $1000 bill. And $1000 is small in the scale of what you could end up with on AWS.
      - manigandham 7y ago
        It's the existing resources that are a problem because most of them have a steady-state cost. EC2 instances, EBS volumes, S3 data... should AWS delete those when you hit your budget? How do you stop the billing otherwise?
        justinclift 7y ago
        > How do you stop the billing otherwise? With prioritisation, so the non-steady state services are stopped/killed with plenty of time to leave the needed foundations still running. :)
        manigandham 7y ago
        1) If you're AT the budget amount then everything must be deleted to avoid going over. 2) If it's a soft budget then it's no different than the alarms you already have. 3) If you want to stop it before it hits the budget, then you're asking for a forecasted model with a non-deterministic point in time where things will be shutdown. This just leads to neverending complexity and AWS doesn't want this liability. That's why they provide billing alarms and APIs so you can control what you spend.
        Dylan16807 7y ago
        > 2) If it's a soft budget then it's no different than the alarms you already have. Not if I'm busy, or away from work, or asleep. There is a massive difference between getting an alarm (which is probably delayed because AWS is so bad at reporting spent money) versus having low priority servers immediately cut. Even without a priority system, shutting down all active servers would be a huge improvement over just a warning in many situations.
        manigandham 7y ago
        That's not a soft budget then, so which option is it? 1 or 3? You want it to selectively turn off only EC2? Does it matter which instance and in which order? What if you're not running EC2 and it's other services? Is there a global priority list of all AWS services? Is it ranked by what's costing you the most? Do you want to maintain your own priority of services? And what if the budget was a mistake and now you lost customers because your service went down? Do you still blame AWS for that? Or would you rather have the extra bill? There is no easy solution.
- dragonwriter 7y ago
  > Of course they can be capped, you just turn off the services. That's not a he's cap, since turning off services isn't instant and costs continue to accrue. But, yes, there are ways to mitigate the risk of uncapped costs and they are subject to automation.
  - manigandham 7y ago
    See the sibling comment thread. It's just not that simple. It creates a lot of liability, could lead to permanent data loss, and doesn't really prevent any mistakes either (just swaps them for mistakes in budget caps). AWS would rather lose some billings than deal with the fallout of losing data or critical service for customers (and in turn their customers).
    - thayne 7y ago
      it depends on the use case. For example, I would like to have developer accounts with a fixed budget that developers can use to experiment with AWS services, but there isn't a great way to enforce that budget in AWS. In this case I don't really care about data loss, since it's all ephemeral testing infrastructure. In theory I could build something using budget alarms, apis, and iam permissions to make sure everything gets shut down if a developer exceeds their budget, but if I made a mistake it could end up being very expensive. Not that I don't trust developers at my company to use such an account responsibly, but it is very easy to accidentally spend a lot of many on AWS, especially if you aren't an expert in it.
      - manigandham 7y ago
        So now we have another potential mistake - you setup a "delete everything/hard budget" for a production account instead of a developer account. What then? It's impossible for AWS to know how to handle hard caps because there are too many ways to alter what's running and it's too contextual to your business at that moment. That's why they give you tools and calculators and pricing tables so that it's your responsibility (or a potential startup opportunity). Money is easy to deal with. Alarms work. Bills can be negotiated. But you can't get back lost data, lost service, or lost customers.
- ngcc_hk 7y ago
  Should be cap so you have a check. If your system does not allow threshold or assertion, please do not use it. If your cloud system do not have capped budget so you play in and alert you when you soon run out, do not use it.

TBH, the real problem is AWS bills cannot be capped in any way (you can setup an alarm, though). It's unreasonable to expect a programmer won't make mistakes.

by nitely 7y ago

TBH, the real problem is AWS bills cannot be capped in any way (you can setup an alarm, though). It's unreasonable to expect a programmer won't make mistakes.

manigandham 7y ago

Of course they can be capped, you just turn off the services. If you're asking them to automate that for you, then the counterpoint would be people accidentally setting a budget that wipes out their resources and complaining about that. Easier for both sides to just ask AWS for a refund if there's a reasonable case.

nicoburns 7y ago
> the counterpoint would be people accidentally setting a budget that wipes out their resources and complaining about that. This wouldn't be an issue if it was configurable.
- manigandham 7y ago
  Mistakes will always be an issue. How you recover is more important. Would you rather make a mistake leading to a big bill with the possibility of a refund or set your max budget and have your resources permanently deleted?
  - nicoburns 7y ago
    There would be no need to delete existing resources. Just prevent me from creating new ones until action is taken. For small projects in particular, I'd much rather have service taken offline and an email notification than even a $1000 bill. And $1000 is small in the scale of what you could end up with on AWS.
    - manigandham 7y ago
      It's the existing resources that are a problem because most of them have a steady-state cost. EC2 instances, EBS volumes, S3 data... should AWS delete those when you hit your budget? How do you stop the billing otherwise?
      - justinclift 7y ago
        > How do you stop the billing otherwise? With prioritisation, so the non-steady state services are stopped/killed with plenty of time to leave the needed foundations still running. :)
        manigandham 7y ago
        1) If you're AT the budget amount then everything must be deleted to avoid going over. 2) If it's a soft budget then it's no different than the alarms you already have. 3) If you want to stop it before it hits the budget, then you're asking for a forecasted model with a non-deterministic point in time where things will be shutdown. This just leads to neverending complexity and AWS doesn't want this liability. That's why they provide billing alarms and APIs so you can control what you spend.
        Dylan16807 7y ago
        > 2) If it's a soft budget then it's no different than the alarms you already have. Not if I'm busy, or away from work, or asleep. There is a massive difference between getting an alarm (which is probably delayed because AWS is so bad at reporting spent money) versus having low priority servers immediately cut. Even without a priority system, shutting down all active servers would be a huge improvement over just a warning in many situations.
        manigandham 7y ago
        That's not a soft budget then, so which option is it? 1 or 3? You want it to selectively turn off only EC2? Does it matter which instance and in which order? What if you're not running EC2 and it's other services? Is there a global priority list of all AWS services? Is it ranked by what's costing you the most? Do you want to maintain your own priority of services? And what if the budget was a mistake and now you lost customers because your service went down? Do you still blame AWS for that? Or would you rather have the extra bill? There is no easy solution.
dragonwriter 7y ago
> Of course they can be capped, you just turn off the services. That's not a he's cap, since turning off services isn't instant and costs continue to accrue. But, yes, there are ways to mitigate the risk of uncapped costs and they are subject to automation.
- manigandham 7y ago
  See the sibling comment thread. It's just not that simple. It creates a lot of liability, could lead to permanent data loss, and doesn't really prevent any mistakes either (just swaps them for mistakes in budget caps). AWS would rather lose some billings than deal with the fallout of losing data or critical service for customers (and in turn their customers).
  - thayne 7y ago
    it depends on the use case. For example, I would like to have developer accounts with a fixed budget that developers can use to experiment with AWS services, but there isn't a great way to enforce that budget in AWS. In this case I don't really care about data loss, since it's all ephemeral testing infrastructure. In theory I could build something using budget alarms, apis, and iam permissions to make sure everything gets shut down if a developer exceeds their budget, but if I made a mistake it could end up being very expensive. Not that I don't trust developers at my company to use such an account responsibly, but it is very easy to accidentally spend a lot of many on AWS, especially if you aren't an expert in it.
    - manigandham 7y ago
      So now we have another potential mistake - you setup a "delete everything/hard budget" for a production account instead of a developer account. What then? It's impossible for AWS to know how to handle hard caps because there are too many ways to alter what's running and it's too contextual to your business at that moment. That's why they give you tools and calculators and pricing tables so that it's your responsibility (or a potential startup opportunity). Money is easy to deal with. Alarms work. Bills can be negotiated. But you can't get back lost data, lost service, or lost customers.
ngcc_hk 7y ago
Should be cap so you have a check. If your system does not allow threshold or assertion, please do not use it. If your cloud system do not have capped budget so you play in and alert you when you soon run out, do not use it.