7 ms·
If you were "hacked" (ie password reuse), the attacker can just relimit this.
by thejosh 5y ago
If you were "hacked" (ie password reuse), the attacker can just relimit this.
- notreallyserio 5y agoAWS could simply require the user verify they have access to the card or other payment method on file.
- oneplane 5y agoThat is super impractical when you run 200 AWS accounts in production.
- notreallyserio 5y agoDoes 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.)
- oneplane 5y agoNo, 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)
- notreallyserio 5y agoI 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.
- Retric 5y agoThe option to set a limit doesn’t require you to set one. Assure lets users have a limit without any significant issues.
- jetrink 5y agoThere'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.
- stephbu 5y agoJust 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)