After my experience 3 years ago, I will never use them again. I priced out an instance that estimated around $30/month via their calculator. Instance is indeed around $30 for the first 2 months, then I get a $200 bill. I don't know what the hell happened, but it was over 6x what I had budgeted. I tried to get someone to review my account, but I didn't get a response and just had to suck it up. I paid the $200 and moved on. Never again, I'll use Linode or something else instead.
I clearly did something wrong, but the process was so confusing that I couldn't tell you what it was. It probably had to do with running the server at sub-optimal times when rates were higher, but I don't remember reading anything about that. It was a Windows-based game server, so the extra cpu overhead might have had something to do with it.
I'm using Google Fi. Once I exceed my paid for bandwidth level for a given month it notifies me. When I go 50% over it notifies me a second time. If I want to know the bandwidth used I can check it anytime I want on my phone.
Considering the huge amount of developers having problems of this kind how hard would it be for AWS to implement a similar system?
Google did this to me with Adwords. They gave me a "free" $200 to run a test campaign but it never turned off and I was not notified in anyway. They ended up charging me $800 for a completely test campaign for a non product blog website that ended up not even getting any traffic. Very scummy behavior even worse than AWS. It was basically extortion because I would have lost my entire Google account if I disputed the charges with my credit card.
This is why I don't like to sign my credit card to any subscription service or anything similar. There is almost no way to delete the credit card, and it is hard to notice the charging before it happened. We should have legislation to make them offer one-shot charging without storing my payment information. Pay as my budget. Shutdown if exceed.
Except they are in the process of changing their bank that they work with, so that they can change the type of cards they issue, and you have until the end of December to change over all your old cards from the old format to the new one, which means changing the card numbers, too.
This is a royal pain in the ass for those of us with hundreds of cards registered through them.
If there was another service of this type that existed, I’d switch to them in a heartbeat. And I will no longer recommend them here.
>how hard would it be for AWS to implement a similar system?
I don't want to be that guy who yells out from my armchair to say something is easy. But........ quota management at its core is incrementing a number, then reading the number back. AWS is already doing things plenty more complicated than that. I'm sure they could build this if they cared to.
Other providers let users put billing limits on their accounts. Seems like Amazon benefits when users aren't able to put a $30 a month limit on their accounts like the OP wanted to.
If you have to be a domain expert to configure it correctly, as is clearly the case with AWS since configuring it is a whole separate industry, then for all intents and purposes it is not there as far as a regular user is concerned. If it helps, imagine a Cessna pilot who's suddenly asked to fly a big intercontinental aircraft without any of the assistance features turned on. All the controls are there, but as far as the Cessna pilot is concerned, they can't fly it.
Billing limits, as in, a hard limit over which resources will shut down and I can be sure I won't be charged over that limit? I'm pretty sure that doesn't exist.
You have to configure (correctly) an AWS IAM account with permissions to run actions you have to specify when budget amounts are hit. There's no simple 'Do not spend more than $X per month' setting. You have to understand AWS's auth and roles to set a limit using an action.
Monitoring, alerts etc are not the same thing as being able to put a cap on the amount of money Amazon can charge your account for services per billing period.
It's possible that was the issue, but I estimated a 20gb storage partition. Maybe usage was to blame, I know the server was inefficient with reads and writes.
I just don't remember the details. As I said earlier, it's likely I made a mistake, but the process was not clear and I was not notified when my instance expense ballooned to something I clearly wasn't expecting. I never had these kinds of issues with Heroku, Linode or any other host.
I had a similar experience as you. You are getting lured in by the free tier, but then this paid additional service is needed and that paid on top.
Didn't work for me at all.
With AWS, you can set up billing rules to notify you of any charges over any limit you want, and you can break that down by service or overall charges, etc…. You learn a lot about this process when you become an AWS Certified Cloud Practitioner.
Sadly, they don’t turn these things on by default. You have to know about them in advance, and you have to know how to configure them. That’s one thing I wish they would improve.
I'm not a Microsoft fan (he writes from his Linux desktop) but I was astonished that Azure actually has working "This is how much we can spend, and literally no more" behaviour coming from previously working with AWS where that's either entirely unavailable or black magic known only to experts.
Why does it have that? Because Azure gives away $150/ month Azure credits to students with Visual Studio. If Azure "mistakenly" lets a student spend $5000 it doesn't get to bill their credit card or chase them with debt collectors, those student accounts don't have any money, don't have a credit card, may have no bank account, so long as some institution paid for Visual Studio licenses there may not even be a real human being behind them. So, the only option for Microsoft is to have a water-tight shut off once you spend $150. Added 1TB of SSD to a virtual machine when you meant 1GB? That's gonna burn your $150 real fast. Accidentally picked the turbo-fast Azure SQL instance instead of the toy one you actually needed to demo Power BI? Ditto. But you don't get an enormous bill and then hope they let you off, the credit runs out and everything goes dark instead.
Amazon seems to believe that so few people care about this they don't need to compete. Maybe they're even right. But I, for one, don't want to risk my life savings every time I'm on a screen where a fat-finger costs $5000 per hour, so Azure looks pretty attractive.
Oddly, there's certain things in Azure that don't work with the credits feature, like spot instances. I'm not sure why, but it's awesome for not blowing up my bank account because I did something wrong.
> There are entire consulting businesses based on the idea of helping people understand their AWS bill.
More broadly, there's a whole cottage industry of businesses that exist only because the UI for the major cloud providers is terrible. Stuff like security auditing or even telling exactly WTF is going on (let alone over time) is so painful that it's worth paying someone else to provide a better UI. Same for billing.
It's a valid one. Engineering teams work with AWS kinda in the same way mass market 90s C code was written. They get it running, but boy are there huge leaks and crashes hiding in plain sight.
From that perspective, I think it might be ok to say that most eng folk complaining about AWS billing need a safer language (higher level abstraction) where they are protected from causing harm or being harmed.
One thing that would make a difference on small accounts is the ability to do prepaid billing only. That way you define your budget in advance and they enforce it. The problem with the current billing is that people who are new to the system have no hope of understanding what is going on and they have to accept the open-ended nature of the billing system to learn.
One issue is what gets shut down when you hit the max? If you have an EC2 instance running and you hit the max, do they shut it off? Would customers understand that and be ok with it? What if you have an S3 bucket? Should they just delete the data? That's probably not what you want.
You can basically do max bill now -- you can set up a cloud watch alarm for billing and when it reaches a certain price, run a script. Your script could just shut everything down and delete everything, or do whatever is appropriate for your account. That's their solution to this.
Also they don't have instant feedback on usage -> cost. They batch process it. So if you get a huge spike in usage, AWS may not even know that for a while. They could in theory be willing to eat the cost of usage between it happening and their processing, but are probably unwilling.
There must be a process for unpaid bills, whatever that process is they could just enact it at the user's threshold instead of their own threshold. Ideally a soft limit that would disable networking and resource creation and then later a hard limit where your account is wiped out.
Because of the potential overhang before the billing system catches up I think it would be appropriate to lower the service quotas on this type of account. I'm not sure if the customer can lower their own quotas which would be an alternate cost control strategy but a beginner wouldn't know to think of that anyway. The solution with billing alerts is good at a company level but too much for a beginner in my opinion.
I know unexpected costs were a concern for me when I started using AWS as a student in 2008 and it is still a concern for people in the same situation, just with so much more complexity on top of it all. It will be a tiny fragment of their revenue but as time goes on a higher and higher level of expertise is required to get started, even though you can accomplish a lot with just the free tier. The amount of progress they've made on this issue in the last 13 years is just not impressive.
Yeah, shut off EC2 instances, block access to all resources, etc. Preserve bucket data and other storage for N days or $M max allowance (ultimately billable) before deleting. AWS could limit how much storage they make available to someone with a budget, reducing their risk substantially.
It's pretty easy stuff, IMO, but the upside for them is low -- after all they are already #1.
That might work for you, but not everyone. They might even have legal trouble with such a system, if they delete data that was required to be retained for example. You're not thinking of all the edge cases.
Their egress bandwidth pricing definitely wasn't designed to meet my needs. I forget how many orders of magnitude above market it was when I priced it out, but it was ugly.
The complexity is to meet customer needs, not the prices themselves. But aren't you glad they have bandwidth tiers so the more you use the cheaper it gets? :)
I think there is a class action law suit waiting to happen to be honest, it's clearly deliberate and everyone who has set up AWS personally is being charged $2-5 per month for services that are still running but they cannot find.
You may not be that far off from the truth. It took me a paid course (though, admittedly at a deep discount and for basically no money for a professional) to understand the purpose of the VPC section of the AWS control panel. And a while later, to understand why the items on the left-hand side are grouped in such a seemingly nonsensical way.
Now that I know this complexity, I can't unlearn it. But for everyone else, I would just recommend Digital Ocean, Scaleway or Hetzner.
It's a very special kind of evil. They can always argue it's your fault, because you haven't read something, you misunderstood something. There are even stories circulating of people who lost their life savings by mistake but the AWS team charitably decided they will forgive them just this time, how nice of them!
Everybody knows it's complex to their advantage, they are not stupid - but they can always defend themselves using the flexibility card. I don't believe a class action would ever happen.
Google doesn't allow prepaid cards last I checked. I tried to use a card from privacy.com and the Google form explicitly stated that you can't use prepaid cards.
You'll still owe the money, but it's unknown whether or not they'll come after you or report you to credit agencies (which they can do w/o SSN). I guess you could use a fake name and address, though.
Last time i checked AWS didn't accept prepaid cards. Even if they did, they could still after you if you live in the USA, and if the amount in question is significant, also in other countries.
Except they are in the process of changing their bank that they work with, so that they can change the type of cards they issue, and you have until the end of December to change over all your old cards from the old format to the new one, which means changing the card numbers, too.
This is a royal pain in the ass for those of us with hundreds of cards registered through them.
If there was another service of this type that existed, I’d switch to them in a heartbeat. And I will no longer recommend them here.
I was actually successfully in reversing a $500 AWS bill. I had needed an Active Directory domain controller so I found one in the AWS marketplace and deployed it to an EC2 instance. Well guess what, the DC must have had some malicious start up scripts in it because it proceeded to download a few TBs of data from outside to the AWS EC2 instance which equaled nearly $500. I complained and AWS immediately reversed it without any need to escalate. This was on a personal AWS account so no relation to any large organization. Morale of the story, dont trust AWS marketplace images from sketchy sources.
I'm honestly at the point where I assume the AWS Console is awful on purpose as a way to drive people towards infrastructure as code. It's just so awful that it can't be on purpose (I hope).
I clearly did something wrong, but the process was so confusing that I couldn't tell you what it was. It probably had to do with running the server at sub-optimal times when rates were higher, but I don't remember reading anything about that. It was a Windows-based game server, so the extra cpu overhead might have had something to do with it.