4 ms·

I feel like whenever this topic comes up, people go back and forth over whether or not AWS should allow you to set a hard limit and what that entails on both si

by scrose 5y ago

I feel like whenever this topic comes up, people go back and forth over whether or not AWS should allow you to set a hard limit and what that entails on both sides / why it’s impossible. I feel like a better approach would be to specify what services you actually want to run and that requires a separate secret key that you will never use for other development tasks, and you have the ability set hard limits for those services. AWS already has hard limits on things like the number of S3 buckets you can create, that require manually requesting an increase if you want more. Why can’t people say ‘I only want a maximum of 5 EC2 servers, and I don’t want the ability to spin up anything above a t3.large(translated to maybe ~20cents/hour per server)’. A similar approach can be taken for other resources. This gets around the issue of ‘what should AWS do if you hit your spending cap’ by allowing you to set an upper bound in the amount of hardware you can actually spin up. It also solves the issue of a compromised dev key or root user account that would likely trivially allow someone to remove a spending limit anyway.

zokier 5y ago
> I feel like a better approach would be to specify what services you actually want to run and that requires a separate secret key that you will never use for other development tasks, You can get pretty far along by never using the root user, and having very limited iam policy for your day-to-day user. That is also what AWS documents as best-practice: > We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practi... You can not set quotas that way, but you can at least limit which services are accessible. Furthermore e.g. ec2 has fairly rich set of conditions you can use in policies to lock down the access even more: https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-policy-keys https://docs.aws.amazon.com/service-authorization/latest/ref...
- caymanjim 5y ago
  This is the right solution. Secure your root account, don't share the credentials, use 2FA, etc. Make role-based accounts with limited permissions and never put anything in the root account. AWS recommends it, and their UI encourages it, but doesn't require it. Third-party auditing services like Vanta are great for identifying issues like this that should be addressed. That said, AWS should make it easier or even require it. AWS is full of footguns and weak security defaults and small players (like the person who tweeted about the bill) lack the knowledge and experience to adequately defend themselves.
- scrose 5y ago
  I know not to use the root user and am aware of many of the advanced policy conditions you can use to help control usage, but that doesn’t address the ability for service usage to quickly spiral out of control from either simple mistakes or a compromised user. People make mistakes. People’s accounts get compromised. I’m sure AWS has plenty of data on what services are most likely to be abused and could come up with a UX that minimizes or prevents that abuse in a simpler way than just providing hundreds of configuration options and calling it a day.

by scrose 5y ago

zokier 5y ago

> I feel like a better approach would be to specify what services you actually want to run and that requires a separate secret key that you will never use for other development tasks, You can get pretty far along by never using the root user, and having very limited iam policy for your day-to-day user. That is also what AWS documents as best-practice: > We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practi... You can not set quotas that way, but you can at least limit which services are accessible. Furthermore e.g. ec2 has fairly rich set of conditions you can use in policies to lock down the access even more: https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-policy-keys https://docs.aws.amazon.com/service-authorization/latest/ref...

caymanjim 5y ago
This is the right solution. Secure your root account, don't share the credentials, use 2FA, etc. Make role-based accounts with limited permissions and never put anything in the root account. AWS recommends it, and their UI encourages it, but doesn't require it. Third-party auditing services like Vanta are great for identifying issues like this that should be addressed. That said, AWS should make it easier or even require it. AWS is full of footguns and weak security defaults and small players (like the person who tweeted about the bill) lack the knowledge and experience to adequately defend themselves.
scrose 5y ago
I know not to use the root user and am aware of many of the advanced policy conditions you can use to help control usage, but that doesn’t address the ability for service usage to quickly spiral out of control from either simple mistakes or a compromised user. People make mistakes. People’s accounts get compromised. I’m sure AWS has plenty of data on what services are most likely to be abused and could come up with a UX that minimizes or prevents that abuse in a simpler way than just providing hundreds of configuration options and calling it a day.