AWS - Automated Wallet Slimming?
Some text is required
Amazon Web Services has come under fire for lack of hard spending limits on accounts, after some users reported unexpected bills from what they thought were tutorial accounts. AWS does not have a freemium business model (unlike, say, GitHub or Dropbox), but it does have "free tier" services that cost nothing to use, within …
Not just AWS, I fell foul of Amazon UK when I tried to buy some tat for my niece's birthday present. Everything was going ahead until I tried to redirect the delivery to her address, it would have been no use to have it delivered to my address, it's over 100 miles away from hers. Suddenly, everything disappeared from my basket, and I was locked out of my account. When I eventually got through to Customer Support, I was told that there appeared to have been some fraudulent activity on my account, so it had been locked pending investigation, and all my orders had been cancelled. Six days later, they took the money from my bank account anyway, and are refusing to give me a refund because of "Fraudulent Activity". Beware of the piratical actions of Amazon UK, they'll rip you off mercilessly and then refuse to communicate with you.
AWS and amazon have stung me, I swapped to Aliexpress for a bit and accepted 10% loss/junk on purchases until I hit that limit, tried dhgate they took my first payment and ran.
These cunts have been profiteering from covid and should be jailed, its organised crime.
Failure to provide a human contact should be a crime punishable with time.
If a dispute is not worth the wages of an operator give them the money back and close the call.
For the above I think this is reasonable of MS here.
By definition the act of releasing your code into Production should include impact analysis of the changes which should include a pretty robust assessment of the charging/scaling expectations, followed up by a period of aftercare where things like resource utlliization are monitored more closely than usual.
TL:DR. - Dont use the production tier if you dont use/understand SDLC.
SDLC along with real robust test plans are what separates software professionals from gifted* amateurs imo. Just because you have the job title and the pay grade don't mean you are, and lets face it we've all met even some very senior people who fall in this bucket - and take their colleagues/teams down with them.
* I leave it the reader to define what this means.
It is a sadly common one, but you are making the potentially fatal mistake of assuming all of your systems will A) work as designed and intended and B) no one will abuse your deployment in ways that can cost you money. That's hubris that Murphy's law and it's corollaries will punish cruelly and often.
ALL cloud accounts that include usage based billing need to have the option to set a hard cap on spending. That needs to be a SHALL not a SHOULD. If you make cloud connected heart monitors or something where the uptime it critical, don't set set it if you don't think you need it and you can eat the costs if your system gets jacked by crypto-miners.
The rest of the world deserves a deterministic backstop, even in production on Azure. It's not too much to ask. If there is a large delay in billing calculations at scale, let them take a "Wind Down" deposit for large scale customers to cover costs as they trip the circuit breakers and wind down their deployment cleanly.
Code of all kinds includes limits to prevent problems that were not found in production. It is why production software checks whether memory was allocated correctly and handles out of memory conditions even though their assessment indicated that this was unlikely. For the same reason, they should have the ability, especially when it's only running on their systems, to have a safety cutoff for various types of unexpected resource usage. Most software running on the backend already has a lot of things like this. For example, a system which checks individual jobs for ones that seem to be taking too long or too much processing and may therefore be malfunctioning. Such jobs can be investigated or killed to prevent them causing damage to the rest of the backend.
True, but quite a lot of professionals have much less talent and flexibility than gifted amateurs.
I would wager that the vast majority of successful projects were started and built by gifted amateurs as passion projects.
Malwarebytes is a good example of this. Built by a student who laughed his ass off when the Uni sysadmin came to his machine to remove a virus (that was being used experimentally in testing) using the very product he was building.
Never under estimate a man in his shed with nothing but passion for his creations.
What the article is describing is something that I thought was fairly obvious when I took a look at AWS to see what you got from the "free" tier. I mean, anything that insists on being supplied with payment card details before you can have it is obviously very much not "free", because you are giving them the authorisation and the means to take money off you. It's the shame shitty trick they pull with "free" Amazon Prime subscriptions. I mean, even the people with the most rudimentary programming knowledge here know how trivially easy it would be to write the code to just stop the service once the limit is reached. But they'll never do that because it might stop a few unsuspecting souls from being financially skimmed by Emperor Bezos, and this is obviously part of modern day "business models".
Which is why, if I were going to sign up for such a service, I'd use a PAYG refillable credit card as the payment instrument on file. If I like the service then I'll keep the card topped up to pay for said service. If I try to kill the service but don't dot every t & cross every i then they can't try to bankrupt me for not getting it right. If some process runs away & tries to cost a few hundred thousand bucks then AWS will be up shit creek when the attempted charge riccochets in their face.
Not that I ever intend on using anything offered by the Bezos Behemoth, I'd rather not give that rich bastard a single penny.
True, but for the cost of 3$ or so in card fees, they may still have enough money in their bank account to pay rent etc while they work out the billing snafu.
The idea that any company can take an unlimited about of money from your account is a little terrifying. I still link their services to a card with a low limit and no overdraft for the same reasons.
Sure, they can chase Heywood Jablome at 123 Eatmybutt St in Big Dong Lick Arkansas all they want.
Never sign up for a 'free' tier of anything that wants payment details with your real name, use a prepaid debit card with a few pennies left on it that you bought with cash, and use the free wifi from the McBurger place to connect to it.
And when you do go into production, set up a shell corp in Bermuda to sign up, if there's a serious screwup and it gets overbilled, oops it went bankrupt. It's what Amazon would do to you.
HI Neighbor! =-D
I wish I could upvote you a few hundred more times for expressing what should have been bleeding obvious. If you use fake PII as registration data, record all those fake answers in a plain text file named the service name so you can regurgitate it back later if need be, & then use an anon PAYG card with which to pay for said services, you can walk away as easily as you can empty the card balance at your local QuickieMart & drop it in the skip on your way out the door. How is the service going to come after "you" when the PII they have that identifies "you" is utterly ficticious in the first place? My neighbor Heywood is an Amazon prime example of this practice.
*Hands you an extra tall pint*
I mean, even the people with the most rudimentary programming knowledge here know how trivially easy it would be to write the code to just stop the service once the limit is reached.
Probably horrifically complex.
You're not monitoring 1 instance and reacting to it, you're monitoring many instances among millions and having to react in a reasonable time.
Otherwise you'll just have people hammering your 'free' offering for short term compute usage.
OK, so you could document that "once you reach your spending cap we will stop your services (and stop you from launching new ones) as soon as possible. Due to usage reporting not being instant, it may take up to 15 minutes from going over your spending cap until we stop the services and block new services from starting. You must pay for your usage during that time. If, due to systems failure, we fail to stop the services, you don't have to pay for your usage after the 15 minute period, unless we can show that you knew there was a systems failure and deliberately abused it."
>You're not monitoring 1 instance and reacting to it, you're monitoring many instances among millions and having to react in a reasonable time.
Your (the Cloud providers) problem, not mine.
If you are too stupid and/or lazy to not effectively instrument and orchestrate your cloud service and real-time integrate it with your billing service then tough, you pick the overspend bill up.
Yes, there might be delays in data hitting the billing system, however, nothing stopping you from implementing mitigations.
I suspect the real problem is that cloud service providers don't want to properly integrate billing as that would increase their overheads, so running lean with approximate billing (in their favour) is the order of the day.
Your (the Cloud providers) problem, not mine.
No, it isn't.
You don't have to use their services.
They're a business out to make money, they're making a boatload of money. They only have to do these things if it starts affecting their bottom line.
It doesn't, so they won't.
If you are too stupid and/or lazy to not effectively instrument and orchestrate your cloud service and real-time integrate it with your billing service then tough, you pick the overspend bill up.
It's not stupid, or lazy. Doing that would cost them development resources, time, (is actually qute technically challenging) and would lose them money as legally you don't pick the overspend bill up. (They are run by the worlds richest man, who still thinks the US taxpayer should fund his rocket ambitions).
Arguably the stupid people are the ones giving out payment details. (Aside: I think AWS is interesting and useful, but I would never set up a personal account for this very reason; it's too easy to get into a mess).
If you're happy having people deficate in bags to protect the bottom line you've got no interest in some future non-customer saving themselfs a few hundred dollars.
(The solution to this is for people to stop using Amazon, not complaining about it).
I am not a coder so am not sure if you are correct or not, but wouldn't a simple "If X >= $Y then EndProcess" style entry do the entire job automaticly with no Human intervention required?
You ask the customer to define the limit at which $Y is triggered, the system auto-triggers when that If Then statement is True, and kills the process until such time the customer pays the bill or up's the limit.
I don't buy the time delay aspect. If they can bill in real time, then they can monitor/kill process' in real time, otherwise they can never know exactly what to bill to whom & when. If you can only guesstimate a +-15minute range for billing, then you've just written in a "get out of jail free" card to said customers as they can claim to have tried to kill their process' "but the system kept going for an extra 15 minutes". If you can't *prove in court* that they used exactly Hh:Mm:Ss of service, then the customer can refute the bill with you already having established reasonable doubt as to the validity of said bill.
It doesn't matter if you have one instance or billions, the same If Then statement included with each one of them will do the job in real time with no intervention at all, no?
The Unfair Terms in Consumer Contracts Regulations 1999
5.—(1) A contractual term which has not been individually negotiated shall be regarded as unfair if, contrary to the requirement of good faith, it causes a significant imbalance in the parties' rights and obligations arising under the contract, to the detriment of the consumer.
A couple of years back I racked up £300 mobile data charges for going over my free allowance despite having a £50 cap on my account. I complained and was told the system can take a couple of days to log and process data usage so the cap doesn't take effect as soon as it's hit... The pricks happily ripped me off for 2 days at about £10 per MB and kindly gave me a small discount for having complained.
Sounds like the subject of the next class action lawsuit. We already had one on the other side of the pond, now our carriers have to stick to the contract value and they just knock you down to dial-up speeds if you go over and don't top off your data.
"now our carriers have to stick to the contract value and they just knock you down to dial-up speeds if you go over and don't top off your data."
I have a plan the comes with a set amount of high speed data, but may drop to lower speeds once that threshold is reached. I can always go online and purchase more high speed if I need it, but that's never happened. I don't bury myself neck deep in my phone so I use very little of my allocation. I did want a plan that wouldn't just cut off or bill me insane amounts of money if I butt-dialed a HQ stream and chewed through a month's worth of data one day.
A YouTuber who I follow recently had the credentials for his AWS account stolen. He had unwisely not enabled 2FA for the account either.
Armed with his account details, someone logged in to his account and set up an instance to run some crypto-coin mining software, doing so in the middle of the night while the victim was asleep. By the time he woke up and checked his email, the fraudster had already managed to rack up a $500 bill which is now the unfortunate victim's responsibility to pay. They had even set up the mining instance in such a way that the victim could not stop or remove it which resulted in some panic-stricken calls to AWS support.
I haven't heard whether he managed to get any reduction of his bill from Amazon. Even if he does, it was a painful way to learn that 2FA should be mandatory on any Internet service which can rack up a huge bill while you're not even awake to receive an emailed alert.
Yeah, that's been going around with 40-60k bitcoin. It's also useful to point out if you have your own mail domain it's possible to separate the account privs to help limit an account breech. It's not super user friendly yet though. But even if they had a hard cap, it wouldn't help if your account it breached and they can just disable the cap.
But yeah, MFA for everything that has billing.
We use AWS for a few things, and at one point I was running a MSSQL database with them which I've since removed all trace of. On our monthly bill there is still a charge of about $1.50 itemised to this service.
It's such a small amount I can't be arsed to chase it but I wonder how many others are billed the same thing for ghost processes?
Because that would run contrary to Jeff's wallet needs.
One simple rule to remember: AWS Free Tier is not free. It is designed to take your money.
Amazon is not a tech company. They don't give out freebies for researchers or developers. They are just a retailer.
"Because that would run contrary to Jeff's wallet needs."
Jeff only gets a salary of around $80k/year. His money is in the stock he holds which doesn't correlate with net profits, just what others think the company is worth. Besides, he's stepping down on 7/5 to only the Board chairman role. I'm not saying he's a complete angel, but this has nothing to do with him.
Your contribution to Bezos's ever-growing cash pile will help fund his transformation into the real Big Brother. You gotta milk the suckers is his personal mantra.
With Amazon the only store left standing by 2026 everyone will be beholden to him making it easy for him to declare himself ruler of the world (for life)
AWS and their support has been heading rapidly downhill for a number of years. They have got complacent. The cost seems to be rising and actually getting hold of someone who is capable of understanding a technical issue rather than categorising it based on a script seems to be approaching zero.
In summary: here be dragons.
I'd say avoid, but the big name competition is just as bad. Maybe take out a VM with a smaller supplier.
It's getting worse? really? wow.
Quick story - back in 2010/2011 I worked for a small startup in Seattle. The CEO's brother was the head of Amazon cloud(now the CEO of Amazon I guess). I met with him and my small team at the time, gave them our list of complaints and their response was basically yeah we know that is a problem and we are working on it(manager at the time said it was their typical response). On paper the startup had upwards of $500k/mo bill with them. I don't know how much, if any was forgiven on the backend given the close relations with the executives(though they did direct us to cut spending by as much as we could got it down to maybe $250k?? per month? -- so $3M/year - actually pushed a project to move them out of the cloud which had a ~6 month ROI but the company board didn't like it despite all management including CTO and CEO being on board they didn't want to fight the board for that).
Anyway, the core part of the story, my director(new guy after original manager left) had a history of working AT amazon for more than a decade. Everyone at the company(especially me) hated their cloud. Non stop problems, outages lies you name it. So my director reached out to their support(keep in mind they were just a few miles away) and said HEY, we spend a lot of money with you, have a lot of executive tie ins between us, and we're in Seattle just like you are. Everyone here hates your cloud. We must be doing something wrong, maybe many things wrong. Can you come on site and help us out.
Their answer? No. Not their model, tough shit. Your problem.
I really struggle to think of any vendor on the planet if you are spending half a million dollars a month on calls to complain and ask for help they would have someone on the plane(if required) the same or next day without question. I remember Oracle flying on site to one of my employers to help diagnose an issue. I recall EMC was a couple hours away from flying someone on site to that same company to fix another issue(which ended up not being an EMC issue at all but a bug in the script the storage person wrote, I remember that call with EMC they were practically panicing to get our processes going again after said storage engineer fucked up the script and went on vacation immediately after). That company spent a FRACTION of the $ per month on that stuff.
Amazon told us to fuck off. Kind of needless to say my director(again he worked at amazon for 10+ years and we had many ex-amazon employees working) was quite surprised at their response.
I left not long after and the company I have been at now(hired by first manager at previous startup) have been saving over $1M/year by moving out of Amazon cloud(bill was over $100k/mo in late 2011/early 2012 for an app stack that launched from day 1 in their cloud and we've grown tons since). So easily $10 million in savings over the past ~9.5 years or so since we moved out. Executives have come and gone and tried to pitch cloud again but they could never come close to making costs work.
I have read over the years their support has improved so quite possibly the support response would not be what it was for us back then for that kind of customer. But seeing your comment reminded me of this experience.
That sounds mad - unless one's computational demand is ridiculously lumpy, a 5 digit dollar monthly cloud bill is hard to justify. There comes a point that buying some kit, maybe leasing some DC space, and hiring some staff is a no brainer.
Cloud is useful for SMEs with the emphasis on S. By the time you get to M, you need to start cutting costs. Why on earth anyone thinks that is moving their stuff to the cloud, rather than moving stuff out of it, is a mystery to me. You end up with ridiculous situations like NASA outsourcing data storage when they have the experts, the facilities, the funds and the physical space to do it themselves and then getting (deservedly) rinsed.
By way of contrast, I worked for a company a few years ago that had a monthly AWS bill of several million $. We were based outside the US but had a dedicated support manager and three technical consultants from AWS on 24/7 call, plus regular support meetings and NDA briefings on product roadmaps etc. On several occasions we ended up in direct contact with product teams to help resolve issues. We did have some issues with AWS but support definitely wasn't one of them.
In the beginning I was stupid enough to try the Lightsail service of "quickly" standing up a server. ( Little did I know that its actually easier to do it all yourself and
it's easier to understand ). Then when I tried to delete it as my ROOT account it told me that I didnt have permission to do this. But...er... I'm root and can delete anything can't I? Well a few queries into the forums found some very smug unhelpful people who said that I had to do some advance IAM to grant my root account the permission to delete what it had just created. This is another way that AWS tries to lock you in for good. Cloud is more of the same old IT business of the past 40 years - vendor lock-in is top priority. I've closed the account completely now, gone to the opposition.
This is the same company that uses all the tricks in the book to get you to sign on to a "free trial" of Amazon Prime.
In my case, I installed the Kindle app and got to a screen on which the only visible button registered you to a free trial. You had to use the Android back button to refuse. And I only knew I was registered when I called support about the unknown charge on my credit card — the subscription didn't even show anywhere on the Amazon website.
Remember the "good old days" when we were billed for CPU resources used? And when user terminals were dumb, with all the work done on the "cloud" innthe server room?
Give it a few years, and we'll be back to MS launching a new fandangled desktop computer that lets you work locally and independently of other users, with its own disks so you don't have to worry about network failures etc.
"Remember the "good old days" when we were billed for CPU resources used? And when user terminals were dumb, with all the work done on the "cloud" innthe server room?"
Yes, and then some C-level exec that finds a sharp knife to be high tech goes to seminar on outsourcing and suddenly the company is contracting out all of its core activities to a third party they have very little control over. Been there, had the argument (I won, surprisingly).
I recall a discussion about NASA outsourcing its data storage. NASA is all about data. That's what they do. The hardware is only there to go out and get more data so storing it offsite and paying a company the costs and a hefty profit margin is sort of stupid. I think one of the issues was the retrieval demands from the scientists working with the data. Backups are one thing, but live data being worked with is another.
Speak for yourself. My start in IT was at a company that rented time on a Boroughs B1900 mainframe. A dozen or so customers all connected in via kilo stream lines and shared the services. Sound familiar? Worked great until the assholes working for Birmingham Cable dug the road up and chopped all the BT cables.
First thing I looked into when I had AWS Free Tier... how do I set things up so I don't have massive potential cost overruns. There's a few machine types where they throttle your CPU usage when you "burst" to using too much usage, so your maximum monthly bill is like $5/month. I made sure to use those (I didn't exceed free usage, but if I did I couldn't end up with that large a bill. Of course, it also meant I didn't have much more processing power than I'd have on my personal desktop anyway).
It's true though, (not that I blame it on Amazon, they are there to make money off usage...), their documentation didn't really even discuss this kind of thing, and they make it much easier to start up machines and rack up usage than to make sure they are shut off, and it's harder than it should be to accurately track what your actual usage (and thus bill) is (I didn't realize the alerts are like a day behind though -- that's pretty ridiculous given you could potentially blow through a month's expected spending in a minute or two if things went seriously sideways... for instance by having some auto-scale thing turned on, have your stuff malfunction and fire up like 10,000 instances.)
Obviously there is no "spending cap" because it would be impossible to implement by stopping all possible activities across dozens of services that might incur a charge beyond some nominal spend limit. Even AWS cannot calculate total spend across a whole account fast enough to guarantee some process that might stop all services in time to prevent a limit being exceeded.
In my experience almost all users of AWS accounts for training or experimentation purposes have no issues keeping within the free tier limits. On the rare occasion someone does exceed the limit (and I have done this myself once by accidentally leaving a database cluster running) a message to support has been enough to have the charge reversed.
Basically if you don't do your homework to understand how free tier services work then you're responsible for the charges incurred, but even then you probably won't have to pay them.
Seriously, go to privacy.com. Single use & single vendor credit cards where YOU define the purchase limit. This is totally what you need to take control of spending in an as-a-service world where vendors like AWS just charge away once you provide a credit card number - and hope you won't notice.
Hard limits are a big no with production.
They're only relevant for sandboxes and PoCs.
For their own billing purposes the different clouds will cut you off if you start spending too much. A sensible approach would be to set a spending limit for new accounts with some level of configurability.
e.g. accounts start with a $50/month limit. Like the way credit cards start with a low credit limit.
Biting the hand that feeds IT © 1998–2021