[windex]

complexity = money for AWS. At this point, I am actually scared I will end up misconfiguring something and stare at a 6 figure bill one morning. I'd much rather use other services or spin up my own than have very delicate discussions with pushy AWS sales guys first thing in the morning.

[j45]

Very well articulated.

Software sales people are there for their goals first, and your goals second.

If there's a more optimal way for them to reach their goals in the long run, unbeknownst to you, it will happen.

[simianwords]

> complexity = money for AWS

why do you think so? this is a very incurious read into it because the space AWS works in is highly competitive.

[exe34]

I'll give them the benefit of the doubt when they implement a tuneable spending limit, even if it includes infinity by default. until then, they're a business beholden to shareholder value.

[nieksand]

What semantics do you expect when your spending limit is hit?

Turning off all compute resources (EC2, Lambda, Fargate, etc) seems obvious, but what about systems managing state like S3, EBS, and DynamoDB? Should buckets, volumes, and tables be deleted?

[ndriscoll]

Allow users to configure storage to deduct the cost of keeping it until the end of the billing cycle from their spending limit. Then even when you hit your limit, you still actually have enough allowed spend left to pay for your storage. Actually the same principle could be used with compute or any other per-time service, and could just be an option when creating a resource. If you ask for a reservation, then failure to make it because it would exceed your spend limit results in failure to create the resource.

This is a basic problem that every adult needs to know how to solve, like "how can I make sure I don't run out of money to pay for food and shelter when I'm buying toys?" You set aside money to pay for the important things first, and what remains sets your limit for discretionary spending.

[saulpw]

How about starting with the obvious? Doing nothing because you can't figure out how to do everything, is letting the perfect be the enemy of the good. Or maybe they don't have the incentives, as per the GP.

[jiggawatts]

Every time this debate comes up, I point that there are cost-limited subscriptions for Azure, but only for Visual Studio Subscriptions and the like.

The cloud vendors are capable of solving this problem, they just refuse to.

Unlimited spending by customers is precisely what they want.

[exe34]

yes, turn off everything when I hit the limit that I set. allow me to set the limit to infinity dollars.

Can you explain why this can't work as a first step into you figure out the rest?

[karmakaze]

This is either a disingenuous argument or lack of basic positive creativity.

A simple way is for each created resource or rule that creates resources have a toggle to stop/delete the resource if spending limit is reached. I would use this by not enabling this on backups and enabling them on non-production critical resources.

[catlifeonmars]

I’ve seen this argument repeated a lot and I think it’s disingenuous. If AWS cared about simplifying billing they could figure out semantics that make sense. Just to throw out an example, they could allow account owners to either opt in or opt out of a hard cutoff. It’s clear they don’t have an incentive to fix this problem.

[nieksand]

Unexpected, runaway AWS cost is a real problem.

"Tunable spending limit" has consequences that can create other, equally real, problems.

Best effort: Turn off all compute resources, drop dynamically-adjustable persistent resources to their minimums (e.g. dynamo write and read capacity of 1 on every table), leave EBS volumes and S3 alone. In some cases, a user might find their business effectively offline while still racking up a massive AWS bill.

Hard cutoff: Very close to deleting an AWS account. In addition to compute and dynamically-adjustable resources to minimums, this means deleting S3 buckets, Dynamo tables, EBS volumes and snapshots, and everything else that racks up cost by the hour.

The best effort approach sounds reasonable to me. The hard cutoff solution sounds worse than the problem it purports to solve.

Agreed that AWS is poorly incentivized to fix the problem.

[catlifeonmars]

I agree the best effort approach seems sane. Storage cost is typically dwarfed by compute and network I/O anyway. Overall AWS has very few guardrails and it would be useful to ask the user if they want to opt in to guardrails when they open an account. I’m thinking there are a handful of use cases that would have different defaults:

- student, learning how to use AWS: set a maximum spend limit and hard cutoff

- small business, running a website: ddos protection and compute limits, pause compute and alert user if spend goes over, giving them the option to raise the limit and/or resume

Etc etc

[simianwords]

if it is easy then the other providers would offer it to eat AWS's lunch.

[catlifeonmars]

AWS has other advantages. I don’t have deep experience with Azure or GCP, but is runaway spend as big of a problem on those platforms?