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.
They should either add technical measures to prevent overcharging on these types of accounts, or amend the terms of service to explicitly say that the account owner is not liable for charges incurred by an unauthorised user who obtains user credentials.
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.
>Guess anyone trying to cancel their Amazon Prime subscription would agree.
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.
> Well, it's not a roadblock but it's a dark-pattern and user hostile. Just like the lack of spending limits on AWS.
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.
Well, I didn't really mean to say that what made him a billionaire was making it hard to cancel amazon prime, that was just an example I came up with that demonstrates Amazon general stance on user-friendliness.
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.
There's still a lot they could do around that though, e.g. requiring that billing details be re-entered upon change or sending an email alerting the user with instructions to secure the account if it was not authorized.
Just as likely as basic credential compromise is lateral attacks on compute resources from vulnerabilities such as Log4J.
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)
Does AWS require distinct billing accounts for each project? I use GCP, I can attach the same account to multiple projects. (It also lacks this basic billing limit feature, unfortunately.)
No, that's why it would be silly to have to change it for every account. (and also problematic for a team with a bunch of child accounts to then have to gain access to the org's card or something like that to change settings for their childs)
I don't follow. But they could make the quota feature a toggle (that has the same mechanic to unlock). Easy, easy enough for a junior dev. And I'm sure folks spending more than a few minutes chatting about it could come up with an even better solution.
This is the reason I refuse to use AWS for anything that I work on in my own time. I don't want to wake up to a $20k bill because someone thought it would be funny to DDoS my weekend project.
Limiting billing is ambiguous. The computation spent is spent, unless AWS can predict how much you are going to cost by even initiating certain operation, which is not going to be straightforward for all the services they provided.
It's not hard to invert the transaction, ask the billing service if an action can be done instead of bill upon completion. Done. This isn't that hard. If your credits won't make it to the end of the month, send out the email warnings to top up - which should be predictable unless there's a large spike hitting the account. If you prefer invoice billing because you never want your services going down, it's trivial to accommodate with this system design.
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.
In theory, all IaaS services could be built like an Ethereum node:
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.
azure seems to manage that just fine with their free azure credit that they give to MSDN subscribers ($150/month spending limit, refilled every month, no chance of going over).
They bill by the request or minute for most of the services. Billing for storage is a little more complicated, but many services could easily be limited.
This does not stop the high bills from your account being hacked. Just reduces the amount before you notice. spinngin up gpu and ec2 resources until limits are hit in how many are created is an operation that takes seconds.
AFAIK setting a budget or alerts does not say "Not authorized to spend more than X amount, deny any spending over this limit". It will alert you, yes. (Also, not on by default)
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.