Cross-account operations

Problem

We recommend, in general, that you use multiple accounts. This is on the one hand for dealing with per-account limits, also known as Service Quotas , and on the other hand it helps with strengthening the security posture.

The question is now how and where are cross-account operations supported?

Solutions

Cross-account operations apply in principle to all services. This doesn't mean that all services support it out of the box. It usually boils down to mastering IAM (esp. resource-based policies) and what a specific AWS service provides in terms of API support.

From a theoretical point of view you first want to understand what resource-based policies are and how they differ from IAM roles:

Cross-account access with a resource-based policy has some advantages over cross-account access with a role. With a resource that is accessed through a resource-based policy, the principal still works in the trusted account and does not have to give up his or her permissions to receive the role permissions. In other words, the principal continues to have access to resources in the trusted account at the same time as he or she has access to the resource in the trusting account.

So, resource-based policies are attached to a resource while identity-based policies are attached to an IAM user, group, or role, with the principal (who is allowed to do something) implicitly set by the entity the policy is attached to. For a general introduction into the topic check out Becky Weiss' excellent re:Invent 2019 talk on permissions across accounts.

Finally, do some hands-on with the tutorial on delegating access across AWS accounts using IAM Roles and check out how to enable cross-account access to the console.

Let's have a look at some service-specific recipes now.

Compute (covering EC2, container services like ECS/EKS/ECR, as well as Lambda):

• Enabling cross-account access to Amazon EKS cluster resources
• Improve Operational Efficiency with Cross-Account AWS IAM Roles in ECS Containers
• Allow secondary account to push to/pull from ECR repository
• Cross account access for Lambda functions
• Managing Cross-Account Serverless Microservices

Networking-related:

• VPC sharing: A new approach to multiple accounts and VPC management
• Using VPC Sharing for a Cost-Effective Multi-Account Microservice Architecture

Data and storage topics:

• How can I provide cross-account access to objects that are in S3 buckets?
• How can I grant my EC2 instance access to an S3 bucket in another account?
• Cross-Account Access Control with Amazon STS for DynamoDB

Further reading

• Posts on the AWS Security Blog:
  • tagged with cross-account access
  • tagged with Resource-based policies
• New AWS Resource Access Manager – Cross-Account Resource Sharing
• Securely Accessing Customer AWS Accounts with Cross-Account IAM Roles

Conclusion

Using multiple accounts, while recommended, can be challenging. Using available tools and managed services along with applying good practices makes it a possible to strengthening your defense-in-depth and also overcome account limits.