> It's not just AWS. I think there are only two types of cloud providers: The ones like AWS and DigitalOcean that shift the risk to the customer and the ones that offer shady "unlimited" and "unmetered" plans.

Actually there is a third category, those who care. I will grant you it is a rare category but it is there.

One example name: Exoscale[1]

Swiss cloud provider, they offer:

    (a) hard spend limits via account pre-pay balances (or you can also have post-pay if you want the "usual" cloud  "surprises included" payment model).
    (b) good customer service that doesn't hide behind "community forums"

No I am not an Exoscale shill, and no I don't work for Exoscale. I just know some of their happy customers. :)

[1]https://www.exoscale.com/

I guess you'd want Hetzner. You get a generous amount per server and then a reasonable price for each additional TB.

It seems that automatic billing is something that cloud providers invented. For example, home Internet providers or mobile providers usually use prepaid plans, where they simply stop the service once you ran out of money (but you can connect your card account if you trust them). So you cannot get charged arbitrary amount for home Internet, and for mobile unless you travel.

Bare metal server with unmetered bandwidth.

Vultr has hard limits by default.

Hetzner also for CPU use, and last time I checked the traffic would drop to slower bandwidth if you pass some limit. I think they still charge you, though.

I don't think DigitalOcean shifts risk to the customer. They have "pre-paid" cloud VPS plans of 5/10 USD per month with hard-limits right?

> Hard spend limits are an anti-feature for enterprise customers

Yada yada yada, that's the same old excuse the cloud providers trot out.

Now, forgive me for my clearly Nobel Prize winning levels of intellect when I point out the following...

Number one: You would not have to turn on the hard spend limit if such functionality were to be provided.

Number two: You could enable customers to set up hard limits IN CONJUNCTION WITH alerts and soft limits, i.e. hitting the hard limit would be the last resort. A bit like trains hitting the buffers at a station ... that is preferable to killing people at the end of the platform. The same with hard spend limits, hitting the limit is better than waking up in the morning to a $1m cloud bill.

> Hard spend limits are an anti-feature for enterprise customers, who are the core customer of AWS. Almost no level of accidental spend is worth creating downtime or data loss in a critical application.

Great, so they don’t have to use the feature?

That excuse was a great excuse when AWS was an MVP for someone. 20+ years later… there is no excuse.

> Almost no level of accidental spend is worth creating downtime or data loss in a critical application.

That feels like a bit of a red herring — if that was their ethos, then you'd _have_ to choose burstable/autoscaling config on every service. If I can configure a service to fall over rather than scale at a hard limit, that points to them understanding different their use cases (prod vs dev) and customer types (start-up vs enterprise).

Additionally, anytime I've worked for an enterprise customer, they've had a master service agreement set-up with AWS professional services rather than entering credit card info, so they could use that as a simple way to offer choices.

> Even having the option of a hard spend limit would be hazardous, because accounting teams might push the use of such tools, and thereby risk data loss incidents when problems happen.

"Hazardous" feels like the wrong word here - if your customer decides to enact a spend limit it should not be up to you to decide whether that's good for them or not.

So have a “Starter” account with spend limits then, don’t understand how an individual is supposed to learn this stack and actually sleep at night without waking up panicking something has been left running.

Is every problem you see so insurmountable?

In the olden days if we spotted a customer ringing up a colossal bill, we would tell them. These huge Amazon bills are fast but still multiple days. They can trivially use rolling-projection windows to know when an account is having a massive spike.

They could use this foresight to call the customer, ensure they're informed, give them the choice about how to continue. This isn't atomic rocket surgery.

"Oh but profit" isn't an argument. They are thousands of dollars up before a problem occurs. The only money they lose is money gained through customer accident. Much of it forgiven to customers who cannot afford it. It's not happily spent. They can do better business.

Cool, have an "I know what I'm doing, opt me out!" button.

Make "unlimited spend" an opt-in. That way users who have explicitly chosen this and agreed to the terms can't then complain to support to try and get the bill waived.

> Almost no level of accidental spend is worth creating downtime or data loss in a critical application

But not all applications are critical, and the company deploying those applications should be able to differentiate between what's critical and what's not. If they're unable to, that's their fault. If there's no option to set hard limits, that's AWS' fault.

This guy is a straight shooter with upper management written all over him.

(Office Space)

So make it an option. That’s not hard.

> Even having the option of a hard spend limit would be hazardous, because accounting teams might push the use of such tools, and thereby risk data loss incidents when problems happen.

This is an interesting point and something I can totally imagine happening! I guess if you have fixed spending limits in a large enough organisation, you lose some of the benefit of cloud infrastructure. Convincing a (metaphorically) remote Finance department to increase your fixed spending limit is probably a tougher task than ordering a load of new hardware!

> Even having the option of a hard spend limit would be hazardous, because accounting teams might push the use of such tools

Tell me you're Shadow IT without telling me you're Shadow IT.

I know legitimizing shadow IT is still the value proposition of AWS to a lot of organizations. But it sucks if that's the reason the rest of us can't get an optional feature.

But the presence of a feature does not mean it has to be used?

Well done AWS for finding a way to make your technical debt cost other people money.

Completely agree. Having worked previously for ... (humans?) ... I can authoritatively theorize it would be fixed in a jiffy if it weren't making them bucketloads of money.

To make my case: just ponder the opposite: "What would an honest version of AWS do?". They would address the concerns publicly, document their progress towards fixing the issue, and even try to determine who was overcharged due to their faulty code, and offer them some compensation.

"We're too big to fix our own code" is, sadly, taken from the MS playbook (IIRC, something like that was made public after the breach of MS manager mailboxes after the whole Azure breach fiasco that was discovered by, IIRC, the DOJ that paid to have access to logs).

And yet somehow every time they launch a new product they have no problem adding it to their billing code.

If there was a lawsuit, change in regulation, request from an enterprise customer, or doing so MADE THEM MORE MONEY it would be fixed in a week.

I've also shot myself in the foot with various APIs, e.g. I racked a 3k bill in a month with Google APIs for my side project, just because I wasn't checking the usage, I didn't think I was using that much. This is more of my fault I guess, but luckily support waived that fee for me after some back and forth. Also I'm not from the US so this bill is larger for me compared to US folks. But honestly also Google APIs are pretty expensive. For hosting my side projects I use a single dedicated DO droplet for $320 a month, where I have 40+ docker containers.

I have a personal account that I'm meticulously careful about (but still terrified of).

I also have an account with L̵i̵n̵u̵x̵A̵c̵a̵d̵e̵m̵y̵ A̵C̵l̵o̵u̵d̵G̵u̵r̵u̵ PluralSight: and while the courses are very variable (and mostly exam cramming focused) it has their Cloud Playground as a super nice feature.

I get four hours to play around with setting things up and then it will all get automatically torn down for me. There's no cloud bill, just my subscription (I think that's about $400pa at the moment - can't check right now as annoyingly their stuff is blocked by our corporate network!) It has a few limitations, but none that have been problems for me with exploring stuff so far.

Same. I will never touch AWS because the risk of accidentally bankrupting our business due to some small configuration mistake is just way too large.

I use a visa gift card for AWS, I only risk what I have on the card.

We missed the boat on that in the US, better luck in 2028

Not going to happen in the US for the next few years, at least.

Jeff Bezos killed the endorsement because he wanted Trump to win. Trump will return the favor.

You trust the government far too much. Regulated industries always end up costing the consumer more. See: medical care and education for examples.

A compromise solution to this could be to block creation of new resources if their monthly cost would exceed the monthly limit, unless the customer increases the limit.

It wouldn’t solve the problem for usage-based billing, but it would have solved the problem here.

For an AWS account dedicated purely to experimentation that would be fine, though.

Having one AWS account where you actually run stuff, and one that follows the rule of "if it can't be paved and recreated from github, don't put it there" is exactly how a lot of people do it anyway.

https://en.wikipedia.org/wiki/Straw_man

AWS Budget Actions: https://docs.aws.amazon.com/cost-management/latest/userguide...

Nowhere (serious) does billing limits work like this

There's always a dunning period and multiple alerts

No, setting a limit doesn't work. They will still try to charge you. A friend had a charge for $0.35 running for a year after his credit card expired. They closed his account later but would definitely come after you if the amount was significant.

The latter: you've used the service so, even if your card rejected the payment, you'd still have a debt with your provider.

I don't think it's particularly obvious or necessary. AWS makes its money on big enterprise customers who probably don't want or need this feature. Hobbyists learning AWS in their spare time are a rounding error on AWS revenue.

I would bet that the reason they don't implement it is not that they're being "shady" but because they don't care about the hobbyists and personal projects and implementing hard spending limits would be a huge, complicated feature to implement. And even if they did put in the huge effort to do it, individuals would still manage to not use it and the steady trickle of viral "I accidentally spent X thousands bucks on AWS" stories would continue as usual.

Not really. Do you think that this is trivial at AWS scale? What do you do when people hit their hard spend limits, start shutting down their EC2 instances and deleting their data? I can see the argument that just because its "hard" doesn't mean they shouldn't do it, but it's disingenuous to say they're shady because they don't.

Except people do get fired for choosing AWS and drastically increasing costs or making big mistakes that cost several times their annual salary.

It’s just not the kind of thing you’re going to see in a blog post.

> Charging per deployment sounds crazy though.

I think technically I was just being charged for the container host machine, but while each individual deploy only lasted a minute or so, I was being charged the minimum each time. And each new deploy started a new host machine. Something like that anyway, it was a few years ago, so I don't remember the specifics.

So I can understand why, but it doesn't change that if their logging hadn't been so flaky, I should have been able to fix the issue in minutes with minimal cost, like I did on Digital Ocean. Besides, the $100 they charged me doesn't include the much more expensive two days I wasted on it.

Yes I believe that is the equivalent to ACA. I use ECS in prod and its incredibly cheap and efficient. Like all things it requires a little legwork to make sure its the best fit. They just charge for the underlying machines not the deployment itself.

I'm not trying to defend AWS, they are kinda shit, but deploying containers straight to EC2s is an extremely supported feature and it is very clear how to do it in the ECS admin panel https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...

For containers, you don't want EC2, you want ECS, possibly even Fargate depending on your use case. They're different compute primitives based on your needs.

There isn't a boxed product like Bigquery, but the pieces are all there - DynamoDB, Athena, Quicksight...

For AWS the solution for container deployments (without dealing with VMs) is Fargate, which imo works reasonably well.

You can set up daily or hourly cost and usage reports on the account. I built a finops function based on it, feeding the data into a Postgres db. Make sure to select incremental updates, if not you’ll en up paying for tb of s3 storage.

The people who write these tutes have (I imagine) an unlimited budget with some special account which maybe leads to this situation

Yes i was charged $400 once for services i had running for three months without any idea it was happening

The billing department knows exactly what you were running, but they only tell you once a month...

> There's no easy way to find out all the resources I'm currently paying for (or if there's a way, I couldn't find it

Cost Explorer, in the management account if you’ve got Organization set up.

this is one of the things i love about azure, easily being able to see everything.

closest i found in aws was something like tag manager?

What about the billing dashboard? You can break it down by service and say CPU or memory, or tags if you use them. That has always given me good enough insight into where my client's money is being spent. I'm not sure it's totally realtime, but certainly daily.

BTW I'm a supporter of spending caps, not saying this should be the only way.

Every so often, I'd get a random bill from AWS totaling to a few cents. No idea where it comes from and it's not worth the non trivial effort to find out about it. Just another reason I avoid AWS unless necessary.

Cost and usage reports will show you what is being paid for. Then there are resources that won’t show up on that so I have used aws:config to pull down other resource lists and finally you can cross both reports to more less find everything.

I thought the tag editor was where one could get a comprehensive inventory of account resources? (Unable to check as I don't currently have easy access to the AWS console)

I hear people say that all the time, but it's not my experience.

I once ran up a bill of $60 accidentally, didn't get a refund. I've had three friends with bills, one got a refund.

It might depend on who you know, if you look like someone who is likely to spend more money in future, how stupid your mistake was, I don't know.

I accidentally pushed an AWS key to a public repo, and by the next day, had like $50k in charges from crypto miners. AWS reversed the charges, with the only condition that we enable some basic security guardrails that I should have had in place to begin with.

> It is very unusual for AWS not to issue refunds in situations like this

...when asked to. But what percentage of mistakes like this end up just being "eaten" by the end-user, not realizing that they can ask for a refund? What percentage don't even get noticed?

I very recently had a run away SageMaker issue that wasn't refunded. Wasn't much, only $50, but they said no.

Pretty ironic that you're actually listing more things why I would not use AWS at all. You mention: "stay away from", "ensure that you", "reasonable caching", "bandwidth is the only real nightmare" are all huge red flags.

Feature request: Write more guides that charge the user $400/day for a toy example.

In some cases (cough javascript sdk) you can literally feel the fear of being fired from the people who were writing these services.

If they use a non-standard version of JSON (for example, one supporting comments, or one with rules about duplicate keys, or any other rule that's not part of the underspecified JSON spec) they should use a custom content type. Something can be valid JSON but invalid AmazJSON and this is exactly how you would distinguish between the two.

The alternative is charging for the rental by the day but a huge proportion of your customers (who probably own a bmw) constantly complain that they’re being overcharged and they want a discount cause they don’t need the blinkers, and refuse to pay for them.

I joke, but this persona is very real, and it leads you to this nickel and dime billing model.

I'm old and was self hosting 20 years ago, but we're comparing apples to oranges a bit here!

Using AWS for smaller personal projects will always be more expensive and probably less fun.

On the other hand I recently had to run an ML model over hundreds of thousands of media files. I used AWS to launch 100s of GPUs using spot instances and complete the job in a few hours, then just turned it all off and moved on. It cost a few hundred dollars total.

In my mind it's at this kind of scale AWS really makes sense.

Yes, thats why all these services are popping up and earning tons of cash… look at next.js for example.

They lead young devs into their framework and make them believe that the only way to serve their sites is through them, and to pay their extortionate prices…

People are not educated to self host. Everything is run in a “droplet” and just a click away.

Yeah, but then they can't win "customer service" points by not making you pay outright extortionate rates, thus further inducing lock-in.

It's very clever - either people pay the overages, or contact you and you can look good by giving them company scrip to spend on other of your services.

There's certainly wastage in large organisations. Over provisioning or keeping that huge S3 bucket full of data from some long forgotten project.

I suspect a lot of the huge AWS customers just eat this because it's so hard to mitigate.

If a business has hundreds of AWS accounts it becomes very hard to track, and if each account can only shave a few hundred dollars a month off their individual bill then there's very little impetus to actually do the work for the individual teams. Despite that possibly adding up substantial savings for the overall business.

I believe you are right, but no tin foil hat theory needed just sound pricing strategy. Eg. factor in underutilization but also refunds. For a flat rate, a price point at 70% of total value of included volume still is better bottom line if you set included volume high enough that the average usage is 50%, yet it still feels more generous and less risky from customer point of view. OTOH very granular unit pricing lets everyone underestimate total costs and complicates comparison with competing offers, „bread and butter“ product prices mask more uncommon ones, etc. In IT underutilization is high, also on own infra, that’s something cloud vendors (and hardware and software vendors) can rely on. Paying for it at least incentivizes to improve utilization, autoscaling is better, sometimes the cloud vendor does it for you, sometimes you have to donitnyourself. In IT laziness is rampant, time is often seen as more valuable than cash out. Also someting the vendors can rely on. I‘ve seen a howto for Azure for a scalable LLM API Gateway. It cost me almost 2 hours to get an estimate for min costs - with default values it would have cost almost 10k per month, I could size it down to less than 1k. A simple loadbalanced reverse proxy on vms cost less than 400. Be especially cautious when everyone is in a hurry. The pre-made solutions may try to cash in on that. Over all: Pricing and pricing models are part of the product properties you buy, and looking for and dealing with psychological pricing strategies and tactics is part of doing business.