Hacker News Reader

Comment by appdrag | Hacker News Reader

Hey segment, are you aware that you can have several env (dev, stag, prod, ...) on the same AWS account? :p You can secure each environement with different credentials (IAM) so no need to create several AWS accounts!

View on HN

In practice, cramming all this into the same account doesn't work. Segment is following best practice here.

For example, IAM doesn't provide the granularity in resources and conditions that you'd want to effectively isolate the blast radius of developer keys. ec2:TerminateInstances didn't (doesn't?) support VPC level conditions, so being able to terminate one instance meant you could terminate all instances.

Similarly, you might want your engineering team to iam:PutUserPolicy in development, but have a much more restricted group in production which isn't possible with IAM today.

I've taken this pretty far in the past to attempt segmenting within one account, but always run into limits: https://github.com/witoff/self-service-iam

The other bit would be blast radius. What if someone does get access to your single account? How confident are you that your policies were airtight? By using many accounts, you create clear isolation boundaries that require opt-in sharing.

>>> By using many accounts, you create clear isolation boundaries that require opt-in sharing.

In theory yes. In practice, you will achieve the opposite of that.

Developers and ops will have to juggle between 10 keys and accounts to get anything. The keys will end up saved and written all over the systems. It will be impossible to have audit between all the accounts and access.

Op here. I don't think you read the blog post! Our entire engineering org has a grand total of 0 AWS keys!

Per-account isolation is great for security and especially reliability, if you run in to constant ratelimit issues like we do.

ec2:TerminateInstances still doesn’t support the vpc as a condition but it does allow you to use tags. You can also limit a role to tagging only the instances they create (as long as they include the tags when they call ec2:RunInstances). You can even require that specific tags are present. Combine all of that with some kind of “owner” tag and it’s a pretty decent solution to the problem. Add automatic tagging on the backend and it’s even better.

That said, it’s not perfect and there’s probably plenty of resources it wouldn’t work for. It’s also comparatively fragile.

It is recommended to use multiple accounts for isolation. AWS has recently launched Organizations to make creation and management of multiple accounts simple. See https://aws.amazon.com/organizations

Tools like aws-vault and now aws-okta make securing credentials a piece of cake.

This just in: directories are pointless because you can put all files in the same one!

---

There are advantages in multiple accounts, for organization and security. Random example: adding tags to ec2 instances is an account-wide permission, for all ec2 instances. Multiple various things by 100 and accounts make sense.

It's a bad idea to use multiple env in the same AWS account.

Can you expand on that?

But you have to prefix all of your resources then, i.e if you are using SQS, DynamoDB, Lambda's and it becomes a huge mess.

OP here. You _can_ do this but IAM Policy wise it is a mess and not very maintainable.

You end up needing to constantly grant and revoke access to individual resources if you went this route. Instead, it's nice to give engineers access to everything that's in their account, and not worry about IAM policies.

Really the problem is that IAM is not a capability system. If you can write a policy at all, there are no limits on what you can put in it, so we can only let trusted admins touch policies. An engineer should be able to grant some of their own privileges to the things they run.

Lots of good information and considerations here: https://aws.amazon.com/answers/account-management/aws-multi-...

As with all of AWS (and software, and life) there is no one size fits all answer.

Their reason for multiple accounts seems to be due to API rate limiting imposed by aws? At least thats my understanding.

Route53 API rate limits are per account and very low.

It sucks not being able to fix the production A record because somebody did a lot of changes on the staging zone.

I was also alarmed to see that dynamodb:DescribeStream is limited to 10 QPS per account, making low-latency stream consumers into noisy neighbors of each other. Then there's all the "open a support ticket" per-account limits on table provisioning and running EC2 instances…

Reply on news.ycombinator.com