AWS Logo
Menu

AWS IAM Advanced Best Practices

AWS Identity and Access Management (IAM) is arguably the backbone of security and governance in the AWS cloud.

Published Feb 3, 2025

1. Recap: Identity-Based vs. Resource-Based Policies

  • Identity-Based Policies : associated with an identity (user, group or role). Ex.: policies of the type IAM::Policythat grant specific permissions.
  • Resource-Based Policies : attached directly to a resource (e.g. an S3 bucket). Here, we define who can access and the permission level on the object itself.
Although it may seem simple, clearly understanding this division is essential to evolve into more complex structures.

2. Service Control Policies (SCPs) e AWS Organizations

When managing multiple accounts within an Organization (via AWS Organizations), we can control permissions globally using Service Control Policies (SCPs) .
  • What are SCPs?
    They are policies applied at the organization, folder (OU), or account level, defining an “umbrella” of maximum permissions. Even if a user within an account has IAM permissions to perform a certain action, an SCP can block that action if it is outside the allowed scope.
  • Usage Scenario : Restrict any account within your organization from creating EC2 instances in unapproved regions, or block the creation of certain types of resources, such as IAM Keys.
Tip : Always use the “FullAWSAccess” SCP (default) and tighten permissions only after you are sure that the policies will not block critical processes.

3. Permission Boundaries

Permission Boundaries are a feature that allows you to define the maximum limit of permissions that an entity (user or role) can have.
  • Why use it?
    It's useful in scenarios where teams need to create their own IAM roles, but you want to limit how far they can go (e.g. prevent the creation of roles with “ : ” permissions).
  • Example : You define a boundary that specifies that users can only create roles with read permissions on S3 and read permissions on DynamoDB. So even if a user assigns a more permissive policy, they won't be able to cross the boundary.

4. Attribute-Based Access Policies (ABAC)

ABAC (Attribute-Based Access Control) lets you grant IAM permissions based on tags (attributes) that identify resources, users, or roles.
  • Example : If each user or resource has the tag “Department=Finance”, you can create an IAM policy that restricts access to only resources with the same tag.
  • Advantage : Scalability. Instead of managing multiple users/groups for each permission, you control the tags for each resource/identity, facilitating dynamic access control.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"
}
}
}
]
}
Above is a simplified example of how to use tags to align permissions (the user can only access S3 buckets that have the same “Department” tag as him).

5. Cross-Account Roles

It is not uncommon to work with multiple AWS accounts in the same corporate environment. To avoid having to manage separate users and credentials in each account, the solution is to use cross-account roles .
  • Benefits :
    • Less need for static credentials.
    • Centralization of users in a single account (e.g.: “Identity” or “Master” account).
    • Unified logs of actions performed, as they are linked to the role the user assumed.
  • How to Configure :
    1. In the target account, create a trusted role for the source account.
    2. Define policies indicating which actions are allowed.
    3. In the source account, create an IAM policy that allows the user sts:AssumeRoleto call the created role.
Example of Trust Policy (on the destination account):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:root"
},
"Action": "sts:AssumeRole"
}
]
}
This says that account 111111111111 (source) can assume this role.

6. Federated Authentication (SAML, OIDC and Cognito)

Organizations that already use a corporate Identity Provider (IdP) , such as Okta, Active Directory Federation Services (ADFS) , or Azure AD , can federate with AWS via SAML .
  • Advantages :
    • Single Sign-On (SSO).
    • Centralized management of credentials outside of AWS.
    • Less risk of exposed keys or duplicate passwords.
  • Example : Set up a trust relationship between your IdP and IAM using a SAML provider, allowing users to authenticate to your IdP and then receive temporary credentials for AWS.
For web and mobile applications, Amazon Cognito is an excellent option for managing user logins, including support for social providers (Google, Facebook, Apple, etc.) and OIDC.

7. Advanced Best Practices

  1. Use MFA (Multi-Factor Authentication) Everywhere
    • Especially for root users and accounts with administrative privileges.
    • Consider adopting Hardware MFA (YubiKeys) for increased security.
  2. Avoid Root User for Daily Tasks
    • Create an administrative role with MFA for routine operations.
    • Store root credentials in a safe place and only use them when strictly necessary (e.g.: creating a new account in Organizations).
  3. CloudTrail Integration
    • Monitor all login events, login attempts AssumeRole, and IAM policy changes.
    • Configure alerts via CloudWatch/SNS for any abnormal behavior.
  4. Rotate Access Keys Periodically
    • If you need to use access keys (not a recommended idea for human users), set rotation policies and check for users with expired or unused keys.
  5. Stay Tuned for New Features
    • AWS frequently releases updates and new features in IAM (e.g., support for tags in roles, refinements to SCPs, etc.). Keep an eye out for announcements.

Conclusion

AWS IAM is a fundamental pillar for ensuring governance and security for any cloud environment. By understanding and applying these advanced features— SCPs, ABAC, Permission Boundaries, Cross-Account Roles, and Federation —you gain much more granular control and reduce the risk of insecure configurations.
In the next post, we will explore practical examples and demos of how to implement some of these configurations step by step. Stay tuned and see you there!

Useful Links and References

Do you have any questions or want to share your experience?

Leave a comment below or get in touch. We’d be happy to help strengthen your security and governance posture on the AWS Cloud!
See you soon and happy IAM setup!
 

2 Comments