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.
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?
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.
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.
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.
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.
"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.
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
