Building Your Cloud in AWS Part 1: IAM Best Practices

This article is intended to give practitioners with limited technical experience an overview of Identity and Access Management (IAM) policies and user roles, a key area to set up when first starting out in AWS.

You’ve created an AWS account—great! Now what? Well for starters, remember not to use the root account that you just created to log in and use services. That’s just for administrative changes like billing and support.

Whatever the catalyst for you starting your journey into building a cloud environment, it’s always a good practice to first set up a secure, flexible infrastructure for you to build your services in. It can be tempting right away to spin up an EC2 and start deploying applications, but the foundation of a great AWS experience relies on a few core architecture principles. The first in this series is IAM, which is the primary way to control user access across your AWS environment.

IAM Dashboard

The IAM section in the AWS console allows you to control user accounts, passwords, keys, permissions, policies, and roles. As mentioned above, it is a general best practice to use an individual named IAM account (with admin access) instead of your root account to build out services.

The Dashboard below shows an overview of the current user base, as well as the status of additional security measures that should put in place (e.g. multi-factor authentication).

Users: an up-to-date list of all user accounts in the AWS account as well as details on access keys, groups, and recent activity. You will go here to manage individual user permissions and policies

Groups: AWS allows users to be grouped together so policies and permissions can be applied at the team level. This is the best way to give access to similar services for a group of users. One thing to note is there is a limit of 10 policies that can be applied at the group level. A workaround to this would be to create multiple groups for the same set of users and apply the two sets of policies across the multiple groups.

Roles: You will see Roles very frequently when using AWS as they are the permissions that allow AWS services to access other AWS services. For example, if you need an EC2 instance to fetch data from an S3 bucket and push data into Redshift, that instance needs to have the proper permissions to each of those services just like a user would.

Policies: Policies are identity-based entities that define permissions for a given resource or user. Out of the box, AWS provides a long list of Managed Policies that offer either full or partial access to each AWS resource. In addition, admins have the ability to create custom policies to limit access to a particular resource even further or combine AWS services into a larger policy to apply at the service or user level. For example let’s say you want to grant a user access to a specific S3 bucket instead of all S3 buckets. Because this isn’t a Managed Policy, you will need to use either the visual editor in the console or a JSON file to specify the restrictions on that user.

Finally, after ‘Policies’ there are a few sections related to Identity Providers (single-sign on for enterprise accounts), account settings, and downloading user data for reporting purposes. AWS also offers a key management service for securely managing user and encryption keys.