4 ms·

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 cred

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!

Thaxll 9y ago
It's a bad idea to use multiple env in the same AWS account.
- rpedela 9y ago
  Can you expand on that?
throwbacktictac 9y ago
Their reason for multiple accounts seems to be due to API rate limiting imposed by aws? At least thats my understanding.
- zimbatm 9y ago
  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.
  - erik_seaberg 9y ago
    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…
jeffnappi 9y ago
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 https://aws.amazon.com/organizations Tools like aws-vault and now aws-okta make securing credentials a piece of cake.
rwitoff 9y ago
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 https://github.com/witoff/self-service-iam
- dastbe 9y ago
  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.
  - user5994461 9y ago
    >>> 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.
    - ejcx 9y ago
      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.
    - deleted 9y ago
      [deleted]
- 9y ago
paulddraper 9y ago
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.
ejcx 9y ago
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.
- erik_seaberg 9y ago
  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.
mooreds 9y ago
Lots of good information and considerations here: https://aws.amazon.com/answers/account-management/aws-multi-account-security-strategy/ 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.
CSDude 9y ago
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.

Thaxll 9y ago

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

rpedela 9y ago
Can you expand on that?

throwbacktictac 9y ago

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

zimbatm 9y ago
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.
- erik_seaberg 9y ago
  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…

jeffnappi 9y ago

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 https://aws.amazon.com/organizations Tools like aws-vault and now aws-okta make securing credentials a piece of cake.

rwitoff 9y ago

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 https://github.com/witoff/self-service-iam

dastbe 9y ago
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.
- user5994461 9y ago
  >>> 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.
  - ejcx 9y ago
    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.
  - deleted 9y ago
    [deleted]
9y ago

paulddraper 9y ago

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.

ejcx 9y ago

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.

erik_seaberg 9y ago
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.

mooreds 9y ago

Lots of good information and considerations here: https://aws.amazon.com/answers/account-management/aws-multi-account-security-strategy/ 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.

CSDude 9y ago

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.