Unexpected, large AWS charges have been happening for so long, and so egregiously, to so many people, including myself, that we must assume it's by design of Amazon.
A $1k AWS mistake
141–150 of 281 posts
Re: A $1k AWS mistake
#142As a bootstrapped dev, reading stories like these gives me so much anxiety. I just can’t bring myself to use AWS even despite its advantages.
Re: A $1k AWS mistake
#143Earlier quoted context omitted.
You can with some effort, but cloud providers don't provide real-time information on how much you're spending. Even if you use spending alerts to program a hard cut-off yourself, a mistake can still result in you being charged for 6+ hours of usage before the alert fires.
> You can with some effort, but cloud providers don't provide real-time information on how much you're spending. This should be illegal. If you can't inform me about the bill on my request you shouldn't be legally able to charge me that bill. Although I can already imagine plenty of ways somebody could do malicious compliance with that rule.
Re: A $1k AWS mistake
#144Re: A $1k AWS mistake
#145Earlier quoted context omitted.
Personally I don't even understand why NAT gateways are so prevalent. What you want most of the time is just an Internet gateway.
Only works in public subnets, which isn't what you want most of the time.
Re: A $1k AWS mistake
#146Saved >120k/month by deploying some vpc endpoints and vpc peering (rather than tgw).
VPC peering becomes ugly fast, once your network architecture becomes more complex. Because transitive peering doesn't work you're building a mesh of networks.
Re: A $1k AWS mistake
#147Earlier quoted context omitted.
It's not that it's technically impossible. The very simple problem is that there is no way of providing hard spend caps without giving you the opportunity to bring down your whole production environment when the cap is met. No cloud provides wants to give their customers that much rope to hang themselves with. You just know too many customers will do it wrong or will forget to update the cap or will not coordinate in…
Millions of businesses operate this way already. There's no way around it if you have physical inventory. And unlike with cloud services, getting more physical inventory after you've run out can take days, and keeping more inventory than you need can get expensive. Yet they manage to survive.
Re: A $1k AWS mistake
#148Earlier quoted context omitted.
Depends on various factors and of course the amount of money in question. I've had AWS approve a refund for a rather large sum a few years ago, but that took quite a bit of back and forth with them. Crucial for the approval was that we had cost alerts already enabled before it happened and were able to show that this didn't help at all, because they triggered way too late. We also had to explain in detail what measur…
Wait, what measures you implemented ? How about AWS implements a hard cap, like everyone has been asking for forever?
s/everyone has/a bunch of very small customers have/
Re: A $1k AWS mistake
#149> AWS charges $0.09 per GB for data transfer out to the internet from most regions, which adds up fast when you're moving terabytes of data. How does this actually work? So you upload your data to AWS S3 and then if you wish to get it back, you pay per GB of what you stored there?
Yes uploading into AWS is free/cheap. You pay per GB of data downloaded, which is not cheap. You can see why, from a sales perspective: AWS' customers generally charge their customers for data they download - so they are extracting a % off that. And moreover, it makes migrating away from AWS quite expensive in a lot of circumstances.
Please get some training...and stop spreading disinformation. And to think on this thread only my posts are getting downvoted....
"Free data transfer out to internet when moving out of AWS" - https://aws.amazon.com/blogs/aws/free-data-transfer-out-to-i...
Re: A $1k AWS mistake
#150I made the same mistake and blew $60k. I have never understood why the S3 endpoint isn't deployed by default, except to catch people making this exact mistake.
Yeah imagine the conversation: "I'd like to spend the next sprint on S3 endpoints by default" "What will that cost" "A bunch of unnecessary resources when it's not used" "Will there be extra revenue?" "Nah, in fact it'll reduce our revenue from people who meant to use it and forgot before" "Let's circle back on this in a few years"