The fact that AWS has no way to limit billing seems insane to me. Your only recourse for an accidental (or malicious) overcharge is beg customer support. It's an incredible liability.
I find it hard to fathom that a company which sells machine learning as a service cannot detect that an account sitting dormant for months, which suddenly spins up several large VMs, has been compromised.
It's unsatisfactory that the only recourse is hoping for a favourable exercise of discretion on Amazon's part to waive the charges.
The unsubscribe button was easy enough to find, but had to maybe go through 2 nag screens before letting me cancel. I guess it's not pro-user, but it's also not exactly a roadblock to me canceling.
Compare that to the experience of unsubscribing from netflix, for instance.
Yeah I explicitly say it wasn't pro user. I was more disputing the "Jeff Bezos did not become a billionaire" (presumably by making it hard to cancel prime) part.
Still, I'm not sure I understand what you're trying to dispute. If we agree with both premises(1. Bezos is a billionaire and 2. Amazon products aren't usually user-friendly), than I maintain my position that the expression "Jeff Bezos did not become a billionaire by being user-friendly" evaluates to true.
Enabling MFA, restricting intra/inter-VPC access, removing hard-coding credentials from configuration files/source etc., switching to SSO/removing user accounts with passwords, creating and applying restricted IAM roles, and applying those reduced privileges to EC2/ECS/EKS instances are all things that and should be done as soon as possible. (Non-exhaustive, but illustrative list)
Sure, big warnings about data loss/services down in the event of zeroing out your credits.
Having such a safety net would really help the thousands of people who sign up for transient reasons. I don't recommend a noob set up an AWS account. I also don't let my kids play on the freeway.
1. fill an account with abstract "multi-resource usage credits" (or gas);
2. have each API call specify how many credits the caller is willing to spend from their account on the operation (a gas limit);
3. operations in progress are tracked using real-time resource accounting (= distributed tracing, but cheap-as-possible at the expense of granularity);
4. any operation that goes over-budget is cancelled (even if it completed successfully, the user doesn't get the benefit of that completion), with the user being charged exactly the limit they specified.
(Yes, that means that the IaaS eats the overhead costs of any additional processing they did before noticing and stopping the workload going beyond its limit. This incentivizes the IaaS to optimize their scheduling, at all levels of the stack, to minimize the amount of "overhang" work it allows.)
And yes, to be clear, this would "infect" every layer of every service. If the IaaS provided a DBaaS, the DB's query planning and execution layers would need to know about these limits and accounting mechanisms. Etc.
I'm not saying it's practical. But it's definitely possible, with no foreknowledge of cost.