[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