AWS IAM Best Practises

AWS Identity and Access Management Best Practises

  • 10 min read

In this post we explore AWS IAM best practises.  IAM, or Identity and Access Management, is a global AWS service that controls both user and programmatic access to AWS resources.  Correct use of AWS IAM is essential to ensure the security and integrity of data and workloads hosted in the AWS cloud.  Within AWS IAM you can create and manage users and groups, and use policies and permissions to control their access to AWS resources.  IAM is a core service offered by AWS at no charge, and it is global – meaning users and groups are available in all AWS regions.

IAM Best Practises

By following AWS recommended IAM Best Practises you will be setting a solid security baseline for your AWS accounts.  It is important to only grant the level of access required to an individual user or service by ensuring that users are appropriately grouped together, and the right access policies are assigned to those groups.  Here we list 16 IAM best practises to help you keep your AWS accounts secure.

1. Securely Store AWS Account Root User Keys

When an IAM user is created in AWS, you have the option of creating an access key consisting of an Access Key ID and Secret Access Key is created to enable programmatic access to AWS.  The Access Key for the Root user of your AWS account should never be used – it grants full access to all AWS resources including billing data and it is not possible to reduce the permissions associated with the Root user.

Best practise dictates that you should not actually create an Access Key for your Root user.  If however you have created one, there are a few things you can do to protect it:

  •  Delete it!  You don’t need it.  If you really want to keep it, be sure to rotate it regularly in ‘My Security Credentials’.
  • Use a strong password to protect your Root Account (see point 7 in this post)
  • Enable MFA on your Root Account (see point 8 in this post)
  • Never share Root Account credentials with anyone else.

2. Create Individual IAM Users

Root Account credentials should never be used to access AWS.  You should first create an individual user account for yourself with administrative permissions, then log in with your individual user credentials and create additional users for anyone else in your company that requires access to your AWS accounts.

Creating individual IAM user accounts enables you to grant different permissions to different users, and also makes it easier to revoke permissions should you need to.  When granting permissions to IAM users, best practise dictates that you should use Groups – see point 3.

3. Assign Permissions to IAM users with Groups

Rather than managing individual permissions across large numbers of users, it is easier to assign permissions to groups that relate to job roles, eg admins, developers, finance etc.  Once you have created your groups, you can assign permissions to those groups and then add users to the groups.  This makes it easier should you want to change permissions for a particular job role – you can simply update the permissions for the group and they will be applied to all users in that group.

4. Adopt the Principle of 'Least Privilege'

The principle of ‘Least Privilege’ dictates that you should only grant the permissions required for your users or roles to perform a specific task.  You need to figure out what a specific user or group needs to do, then either select an AWS managed policy or design your own policy which enables them to do only that task.  So for example, a finance user may only need to be able to access the billing dashboard – you probably don’t want them to have full console access.

It’s best to start with what you think is the bare minimum permissions, and then slowly add permissions if the users are unable to perform the required tasks – this way, you avoid creating policies that are too lenient, which creates unnecessary risk.

5. Use AWS Managed Policies To Grant Permissions

Manually creating access policies for your users can be time consuming.  It can also be difficult to know what level of access your users will require until they are actually using AWS services.

AWS provide a set of Managed Policies which are regularly maintained by AWS and are available to all AWS customers.  AWS Managed Policies provide permissions for common use cases.  One example is the ‘AdministratorAccess’ policy which can be used to create your first admin user.  There are hundreds of Managed Policies for you to choose from to grant access to a whole range of AWS services.  And you can of course modify the Managed Policies to suit your own specific requirements.

6. Use Customer Managed Policies rather than Inline Policies

AWS recommends the use of Managed Policies when creating custom policies.  One reason is that it’s easy to view all Managed Policies in one place in the AWS console.  

A Managed Policy is an individual entity that can be attached to other users, groups or roles.  Managed Policies are therefore reusable.

By contrast, an Inline Policy only only exists on a single user, group or role.  Inline policies are useful if you want a strict one to one relationship between a specific policy and a specific identity.  Inline policies can be converted into Managed Policies if required to make them easier to manage.

7. Regularly Review IAM Permissions

It is important to regularly review your IAM policies to ensure that they continue to adhere to the principle of least privilege.  

AWS categorizes service actions into one of these 5 access levels, based on what the service action does:

  • List
  • Read
  • Write
  • Permissions management
  • Tagging
Access levels can be found in the policy summary which can be found on the ‘Policies’ page for managed policies, or on the ‘Users’ page for policies attached to a user.

8. Enable and Configure a Strong User Password Policy

If you allow your users to change their own passwords, then you should enforce a complex password policy and regular password rotation.  Password policies can be be created on the ‘Account Settings’ page of the IAM console.  The password policy dictates password length, what characters should be included and the required frequency of password rotation.

9. Enable and Enforce Multi-Factor Authentication

Multi-Factor authentication requires users to enter both their password and the response to an authentication challenge in order to log in.  This could be a simple virtual MFA device such as a smartphone app (Google or Microsoft Authenticator) or a hardware device such as an RSA key or U2F security key.

Administrators can enable MFA for IAM users, but enforcing MFA login must be achieved using a custom policy.

10. Use IAM Roles for EC2 hosted Apps

In order for applications running on EC2 instances to access other AWS services, the EC2 instance needs credentials.  For example, the application hosted on the EC2 instance may need access to a database hosted on an RDS Instance , or objects stored in S3.  The recommended and most secure way to give credentials to an EC2 instance is by creating an IAM Role.

An IAM role is an entity with it’s own set of permissions, but it is different to an IAM user or group.  With IAM roles, credentials are regularly and automatically rotated by AWS.

IAM Roles can be specified in the launch parameters of an EC2 instance

11. Delegate Permissions using IAM Roles

If you need users in one AWS account to access resources in another AWS account, permissions should be granted using IAM Roles.  You should not share security credentials between AWS accounts.  An IAM role can specify the permissions to be granted to the users in the other account, and which users are able to assume the role.

12. Do not Share Access keys

Access keys should not be shared between users in an AWS account, nor embedded in un-encrypted application code.  If you have an application that needs AWS access, this should be granted using an IAM role.  If individual users require programmatic access to AWS, they should have their own individual access keys.

13. Regularly Rotate Credentials

Passwords and access keys should be changed regularly by all AWS users. In doing so you limit the length of time compromised credentials can be used to access your AWS account.  You can enforce the rotation of credentials using a password policy.

14. Delete unused or Unnecessary IAM Credentials

Password and access keys that are no lnger required should be removed, for example when a user leaves your organisation.  Similarly, if a user has programmatic access keys but only ever uses the AWS console, the access keys should be deleted.

You can easily tell when credentials were last used by downloading the ‘Credentials Report’.

15. For Extra Security, use Policy Conditions

It is possible to define optional ‘conditions’ under which a policy grants access to your AWS resources.  For example, you may wish to define a set of IP addresses that you will accept requests from, or perhaps you wish to only accept requests at certain times of the day.  You may wish to restrict access to users who have authenticated using MFA.

This is achieved by building expressions with ‘condition operators’ (less than, equal etc) to match condition keys in the policy against values in the request context.

16. Use Logging to Monitor Account Activity

AWS offers a number of logging features which keep track of actions taken by users in your account and the resources that they used.  Log files show the details of what actions were taken by whom, on what date and time, actions which failed due to lack of permissions and so on.

Logging features are available in:

CloudTrail – logs all API calls made by an AWS account, whether by a user or programatically.

CloudWatch – monitors your AWS resources and applications and can generate alarms based on conditions you define

CloudFront – the AWS Content Delivery Network (CDN) logs user requests received.

Config – provides a detailed history of the configuration of your AWS account at a particular point in time.  

S3 – access requests to S3 buckets are logged.

Keeping on Top of IAM Best Practises

Lots to think about in this post right?  May sound pretty daunting to some.  But fear not, there are a number of tools to help you keep on top of your IAM configurations and ensure that you are adhering to IAM best practises.

AWS have a number of tools which I’ve listed under point 16 which can be used to both record IAM configurations but also alert you to changes in your IAM configuration.

CloudTrail and CloudWatch can be configured to send an alert via SNS (Simple Notification Service) when your IAM configuration changes.

AWS Config Rules can be configured to check the policies in use by your users.

3rd Party Tools such as CloudCheckr and CloudHealth regularly monitor your AWS configuration and alert you to changes or policy breaches.

Or you could work with an AWS Managed Services Provider like Logicata who will work with you to ensure that you are adhering to IAM best practises.


Karl Robinson

Director and Co-Founder of Logicata, an AWS Managed Services Provider. Over 20 years experience in the internet & cloud industry. Closet geek, AWS & Azure certified.