3 ms·

Flexibility and pay-as-you-go has absolutely nothing whatsoever to do with the capability to set an account hard cost limit. If AWS wanted to add such a feature

Flexibility and pay-as-you-go has absolutely nothing whatsoever to do with the capability to set an account hard cost limit. If AWS wanted to add such a feature they could do. They obviously don't for their own commercial reasons. It is very easy on AWS to make mistakes and it's off putting to people like me who do not have unlimited budgets as clearly you do.

wahnfrieden 4y ago
attacks are frequent, and then you gotta deal with waiting on aws to confirm it was an attack and refund etc. it's easy to avoid attacks with best practices but the fact stands that they are still common in customer accounts and then you have a financial risk on top of the attack risk.
orf 4y ago
It absolutely does have everything to do with it. How would this actually work? Actually think a bit about how hard it would be to add a global, synchronised and immediate view of an accounts cost and check it on every single API call. Take S3 for example: you set a 1$ limit then concurrently upload 10 1$ per month files. What happens? Should 9 of those uploads fail? How would you ever synchronise that? Or perhaps they complete, but should the bucket delete the contents after the ”storage cost per hour” limit is reached? Perhaps you could reconcile the account cost usage every hour, and when reached the account should be locked somehow and no new writes or reads can be done on anything. Which is basically breaking the account and everything that runs on it. Most people don’t want that. How would it even work with bandwidth? You’re serving a file from S3 or EC2 with your 10$ account limit. What happens after you use 10$ bandwidth? Should your accounts external internet connection be cut off? How would you even calculate that cost in real time at scale. Use your brain. AWS are not stupid. It’s a minefield of complexity that would be super expensive to implement and that benefits nobody. The “if you mess up we will refund you up to 2 times” policy works absolutely fine.
- IMSAI8080 4y ago
  You're being aggressive and rude now, so I think this will be my last reply on this subject. As to "benefits nobody", that's clearly wrong. I have clearly stated what the issues are and other people on this thread have raised similar issues with AWS billing. I don't think you'd have to do too much googling to find more people with the same complaints. What they could do is pause services immediately that can be paused and then give you grace on services where their billing technology has not caught up with real time. They don't necessarily have to actually stop services if they cannot technically do it instantly, just stop charging you at an agreed amount. That's all that's needed.
  - orf 4y ago
    Sounds like a great way to dodge your expensive AWS bill and get a bunch of resources for free. “Oh sorry I used 100tb of bandwidth over my 10$ limit, I guess your billing technology has not caught up with real time! Lucky you are so nice and stopped charging me at an agreed amount”.
- edgineer 4y ago
  >Perhaps you could reconcile the account cost usage every hour, and when reached the account should be locked somehow and no new writes or reads can be done on anything. I would like that.

wahnfrieden 4y ago

attacks are frequent, and then you gotta deal with waiting on aws to confirm it was an attack and refund etc. it's easy to avoid attacks with best practices but the fact stands that they are still common in customer accounts and then you have a financial risk on top of the attack risk.

orf 4y ago

It absolutely does have everything to do with it. How would this actually work? Actually think a bit about how hard it would be to add a global, synchronised and immediate view of an accounts cost and check it on every single API call. Take S3 for example: you set a 1$ limit then concurrently upload 10 1$ per month files. What happens? Should 9 of those uploads fail? How would you ever synchronise that? Or perhaps they complete, but should the bucket delete the contents after the ”storage cost per hour” limit is reached? Perhaps you could reconcile the account cost usage every hour, and when reached the account should be locked somehow and no new writes or reads can be done on anything. Which is basically breaking the account and everything that runs on it. Most people don’t want that. How would it even work with bandwidth? You’re serving a file from S3 or EC2 with your 10$ account limit. What happens after you use 10$ bandwidth? Should your accounts external internet connection be cut off? How would you even calculate that cost in real time at scale. Use your brain. AWS are not stupid. It’s a minefield of complexity that would be super expensive to implement and that benefits nobody. The “if you mess up we will refund you up to 2 times” policy works absolutely fine.

IMSAI8080 4y ago
You're being aggressive and rude now, so I think this will be my last reply on this subject. As to "benefits nobody", that's clearly wrong. I have clearly stated what the issues are and other people on this thread have raised similar issues with AWS billing. I don't think you'd have to do too much googling to find more people with the same complaints. What they could do is pause services immediately that can be paused and then give you grace on services where their billing technology has not caught up with real time. They don't necessarily have to actually stop services if they cannot technically do it instantly, just stop charging you at an agreed amount. That's all that's needed.
- orf 4y ago
  Sounds like a great way to dodge your expensive AWS bill and get a bunch of resources for free. “Oh sorry I used 100tb of bandwidth over my 10$ limit, I guess your billing technology has not caught up with real time! Lucky you are so nice and stopped charging me at an agreed amount”.
edgineer 4y ago
>Perhaps you could reconcile the account cost usage every hour, and when reached the account should be locked somehow and no new writes or reads can be done on anything. I would like that.