Top 11 IAM Best Practices to Live By

A must watch session on IAM Best Practices

AWS Identity and Access Management (IAM) best practices help improve your security posture. Learn how to manage users, security credentials, IAM roles and how to set permissions.

Learn more:


# Category Best Practice Benefits/Use Cases
1. Basic User and Permissions Management 0.      Create Individual Users –       Unique Credentials.

–       Individual credential rotation.

–       Individual permissions.

1.      Grant least privilege –       Less chances of people making mistakes.

–       Easier to give more permissions than tighten up.

–       More granular control.

2.      Manage permissions with groups –       Easier to assign the same permissions to multiple users.

–       Simpler to reassign permissions based on changes in responsibilities.

–       Only one change to update permissions for multiple users.

3.      Restrict privileged access further with conditions –       Additional granularity when defining permissions.

–       Can be enabled for any AWS service API.

–       Minimized chances of accidently performing privileged actions.

4.      Enable AWS CloudTrail to get logs of API calls –       Visibility into your user activity by recording AWS API calls to an Amazon S3 bucket.
2. Credential Management 5.      Configure a strong password policy –       Ensures your users and data are protected.
6.      Rotate security credentials regularly –       Best Practice is to rotate both the password and the Access Keys.
7.      Enable MFA for privileged users –       Supplements username and password to require a one-time code during authentication.
3. Delegation 8.      Use IAM roles to share access –       No need to share security credentials.

–       No need to store long-term credentials.

–       Use Cases:

a)    Cross-account access

b)    Intra-account delegation

c)     Federation

9.      Use IAM roles for Amazon EC2 instances –       Easy to manage access keys on EC2 instances

–       Automatic key rotation

–       Assign least privilege to the application

–       AWS SDKs fully integrated

–       AWS CLI fully integrated

10.  Reduce or remove use of root account –       Reduce for potential misuse of credentials.

–       Delete root account access keys.

–       Lock down root access with MFA.

So, summarizing the 11 top IAM best practices:
0. Users – Create individual users.
1. Permissions – Grant least privilege.
2. Groups – Manage permissions with groups.
3. Conditions – Restrict privileged access further with conditions
4. Auditing – Enable AWS CloudTrail to get logs of API calls
5. Password – Configure a strong password policy
6. Rotate – Rotate security credentials regularly
7. MFA – Enable MFA for privileged users
8. Sharing – Use IAM roles to share access
9. Roles – Use IAM roles for Amazon EC2 instances
10. Root – Reduce or remove use of root account


When should I use?

IAM Users vs. Federated Users
IAM Users are most suitable for startups or small organizations where you don’t have any existing identity management source such as Active Directory.


Federation – managed elsewhere such as AD and you are giving access to my AWS environment with IAM roles.

Federated users with IAM roles is the recommended practice. In this way you can manage users in one place such as AD.

–          Delegating access to your account – Federated users (IAM roles).

–          Mobile applications access, should always be federated access. Use AWS Cognito.


So, Federation offers better control, credential rotation and user management in one place.

Access Keys vs. Passwords
If the user needs NOT to access to the AWS Mgmt. Console and is going to use API, CLI, SDK then Access Keys are required.

–          When creating an IAM user right AWS Access type i.e. Programmatic access or AWS Management Console access.

–          Make sure to rotate credentials regularly.

–          Use Credentials Report to audit credential rotation.

–          Configure policy to allow access key rotation.

For AWS Mgmt. Console access, you need Password.


–          Make sure to rotate credentials regularly.

–          Use Credentials Report to audit credential rotation.


Inline Policy vs. Managed Policy
Inline policy is directly attached by value to the entity; its data that is on the entity (user). So if you delete the entity, the policy gets deleted as well.

Use inline policies when you need to:

–          Enforce a strict one-to-one relationship between policy and principal.

–          Avoid the wrong policy being attached to a principal.

–          Ensure the policy is deleted when deleting the principal.

–          Policy size = 2K

Managed policy is attached by reference; it’s an object like any other object that is managed separately.

Recommendation is to use Managed Policy. Use managed policy when you need:

–          Reusability.

–          Can be attached to User, Group and Roles.

–          Central change management.

–          Versioning and rollback.

–          Delegation of permissions management.

–          Automatic updates for AWS managed policies.

–          Larger policy size (=5K).

Groups vs. Managed Policies
Groups allow you to Logically group and manage users.

Central location to manage permissions.


If you want to assign a policy to all the 3 entities i.e. users, groups and roles, then you have to use Managed Policies.


Recommendation: Combine the power of groups AND managed policies.

So use both of them together.

Resource-Specific Policy vs. Tag-Based Access Control
Use resource-specific policy when you need to:

–          Control access to a specific resource.

–          Control access to most AWS service resources.


Use Tag-based access control when you need to:

–          Using tags you are logically grouping your resources and assign permissions based on tag e.g. project = blue. So, create a policy with a condition to allow access to all resources where a tag project=blue is created.

–          Automatically enforces the permissions when new resources are created with the same tag.

Note: Services that currently support tag-based access control are:

EC2, VPC, EBS, RDS, SWS and Data pipeline

One AWS Account vs. Multiple AWS Accounts
Use a single AWS account when you:

–          Want simpler control of who does what in your AWS environment.

–          There is no need to isolate projects/ products/teams.

–          There is no need to breaking up the cost.

Use multiple AWS accounts when you:

–          When you need full isolation between projects/teams/environments.

–          Want to isolate recovery data and/or auditing data (e.g. writing your CloudTrail logs to a different account).

–          Need a single bill (Consolidated Bill), but want to break out the cost and usage.


Leave a Reply

Your email address will not be published. Required fields are marked *