Managing who has access to what is important for many reasons, least of which is certainly not risk and compliance best practices. AWS Identity Access Management (IAM) is the tool within Amazon Web Services (AWS) that securely controls access to resources within, using a friendly interface and logical system for how it works. IAM is the gatekeeper that manages access controls and authentication for users and also the “how” as it manages authorization tools, protocols and schemas of permissions that manage access to resources within AWS accounts and services.

The official AWS IAM documentation lives here: UserGuide/introduction.html

Rarely is there only one account, which means IAM is key to helping us manage multiple AWS accounts. With that in mind, there is more than one method of implementing controls across accounts:


By default, IAM operates in isolation of a single AWS account, typically the first or primary account used to set up all other AWS tools and services. Authentication and authorization to perform tasks are provided initially only within the boundaries of the account where it has been configured.

This is the most straightforward configuration. It effectively limits the scope of control to whatever resources are available to that account. While this is quick and easy for the average bear to set up initially, this method doesn't scale well beyond two or three users. As one might imagine, as needs change the addition of deeper configuration can significantly add complexilty to managing individual accounts, especially where there are more than two or three.

As this complexity and overhead increases, it does so in direct proportion to the likelihood that we will make mistakes, opening ourselves up to compliance errors or worse - being vulnerable.

AWS has some decent documentation on this:


Another method is use of an Identity Provider (IdP). IdPs leverage one of two approaches to an authentication strategy (or federation) that makes managing multiple accounts simpler. By making changes to a IAM templates and authenticating those users using one of these strategies, the overall management is both friendlier from a configuration perspective and far more consistent with less effort.

These two approaches include SAML 2.0-based federation or Web Identity Federation. Each allows use of identity management directories hosted externally. This could mean an Active Directory schema or other LDAP directory service. It also makes things friendlier for users because it offers a single-sign-on (or SSO) approach to resource offerings. 

Federation of this kind effectively leverages an existing single directory of usernames and vastly diminishes the overhead otherwise involved in managing multiple accounts. Upfront  and thoughtful configuration is still required in order to design, build, establish and document the build (or trust) between an AWS IdP and the directory source, but it is worthwhile because moving forward it simplifies ongoing management of accounts. It may not reduce the complexity in the overall administration of IAM roles and policies within IAM, but tasks such as the creation of addition of AWS accounts won't require the same amount of time and attention.

Here is the official documentation: id_roles_providers.html


IAM roles, put simply, are collections of permissions granting access to resources. They define the types and scopes of  actions available to users within those resources. These are granted to roles rather than individual users or groups.

Cross-Account IAM roles have two policies assigned to them: one is permissions and the other is trust. The permissions policy defines resources and accessible actions. The trust policy defines users that can take actions within those permissions. Both trusting and trusted assets can exist in a single account, or two accounts under a single organization’s control, or two separate accounts controlled by separate organizations.  

There, even I am starting to lose focus. That last bit got a big confusing, huh? We'll stop there for now.

If your eyes are not crossed, there is a an even more detailed explanation here:


If you're into using a single AWS account for everything, some elements of managing will still remain challenging. Setting up and continuing to manually manage accounts, while time consuming and confusing if you don't do it every day, is prone to mistakes like misconfiguration. Choosing to set up cross-account IAM roles or IdP federation, while they bring their own complexities, can be worth it over the long-term.

waxieus is happy to assist with any aspect of Identity and Access Management. Please get in touch!

Meanwhile, thank you for reading.