The Art of AWS Cross-Account Access: Simplifying Complexity
Dive Deep into AWS Identity and Resource Policies for Seamless Integration
In software development, there are patterns repeatedly confuse me and AWS across-account access is one of them. It’s so basic, yet confusing as it requires settings in at least 2 accounts with potentially multiple resources, policies and roles involved. It’s so common especially if you need to work across team or deal with microservices. I can’t remember how many times I need to dig into AWS documents and search forums to find a solution for different AWS services and use cases. Every time it feels like a new problem. But usually there are some common patterns, if we spend some time to identify and understand them, things can suddenly become simple and clear. So, next time you run into another issue of the same category, you can map them to a solution easily. (sounds like writing Scala code, isn’t it?)
Considering the broad range and rapid growth of AWS services, there might be exceptions (for example AWS CodeBuild supports cross-account resources sharing using AWS RAM instead of plain resource-based policy), but in general AWS services use 2 ways to grant cross-account access — either identity-based policy or resource-based policy. While Identity-based policy is supported by all AWS services, resource-based policy is only supported by certain AWS services (the most famous one would be S3).
