AWS Identity and Access Management (IAM) service allows you to manage access and control over AWS services and resources. IAM handles both Authentication and Authorization aspects of security for AWS.


Following diagram shows a simplified view of how IAM works:

AWS Identity and Access Management - How it Works

Image courtesy of AWS


Let’s look at both aspects of IAM

  • Identities, and
  • Access Management


IAM allows you create Identities to be used for AWS services and resources. There are three types of Identities in IAM:

  • User
  • Group, and
  • Role



An IAM User is uniquely identifiable Principal, who can be recognized by AWS services and thus can grant access.

  • A User may represent a person, a system or application, or sometimes even an organization.
  • User can login / enter AWS through console login or programmatically using an access key.
    • Console Login – User ID and Password
    • Programmatically – using Access Keys
  • It’s recommended to rotate Access Keys periodically
  • Multi-factor Authentication (MFA) can be added to an IAM User’s login process for additional security.
  • Users can have SSH Keys to be used for specific purpose – such as in case of CodeCommit repositories.


  • Root User – for each AWS Account created there is a special User created called the Root User.
    • The Root User has full access to all AWS resources
    • It is highly recommended to have MFA enabled for Root User
    • It’s also recommended to not use Root User for day-to-day operations. Rather create additional Users to perform respective tasks.
  • When you create a new User, that User has no access to perform any action – other than may be login (if Login is enabled)
    • You have to explicitly grant permissions to the User
  • Each AWS Account has a limit of 5000 users.
    • For higher User count (such as in case of Mobile Apps), you can make use of Role or Identity Federation to have virtually unlimited user-base



A Group is a collection of (IAM) Users.

  • Groups don’t have login access. Its Users do.
  • Groups can be granted permission.
  • Group is a convenient way to organize permission to set of Users who have to perform similar type of functions. Examples:
    • Administrators
    • Developers
    • Product DBAs
  • A User can belong to multiple Groups.
  • Groups cannot be nested – that is a Group cannot be added to another Group.



An IAM Role is a defined entity with IAM that contain a set of permissions for AWS services and resources.

  • Purpose of a Role is to allow other entities (such as Users, Applications, or some AWS services) to gain temporary access.
    • This is called “assuming the Role”
  • A Role is created just like a User, and access policies may be attached in similar ways.
  • For an entity to assume the Role, you make a call to AWS Security Token Service (STS) AssumeRole APIs to get temporary security credentials.
    • These credentials can then be used to sign requests to AWS service APIs
    • There are three key STS AssumeRole APIs
      • AssumeRole
      • AssumeRoleWithWebIdentity
      • AssumeRoleWithSAML
    • You can configure Temporary credentials validity period from 15 minutes to 36 hours. Default is 12 hours.
  • Roles cannot be added to Groups.



A Principal is a person or an application that can make a request for an action or operation on an AWS resource.

  • Principal may be authenticated as a User or Role to gain access to applicable AWS resources


Access Management

In AWS the Access Management is done through Access Control Policies.

  • A Policy defines a set of permissions.
  • You create Policies and attach them to IAM Identities (Users / Groups / Roles) or AWS resources.
  • When a Principal makes a request, AWS evaluates Policies to determine whether that request would be allowed or denied.


An Access Control Policy defines several aspects of permission management:

  • Effect – to “Allow” or “Deny”
  • Principal – Account / User / Role / Federated User that’s being allowed or denied the request
  • Action – list of actions being allowed or denied
  • Resource – to what resource is the action being allowed or denied to
  • Condition – to specify criteria


Following example shows use of some of these aspects:

AWS IAM - Access Control Policy Sample


There are two types of Access Policies:

  • Identity-based policies – are attached to a User, Group, or Role.
    • They specify what the Identity can do.
    • Example – you can create a user Jane, and attach Identity Policy specifying she can delete S3 Buckets
  • Resource-based policies – are attached to the AWS resource.
    • They specify who can perform (or cannot perform) what type of action on this resource
    • Example – you can attach a policy to S3 bucket specifying that it can only be accessed by a specific Group (e.g., Auditors)


An there are two ways to define Policies

  • Inline – along with the source
  • Managed – standalone


Inline Policies

An Inline Policy is a policy that is embedded in the IAM Identity definition it’s associated with.

  • It may be embedded in User, Group, or Role at the time of creation of that entity, or later


Managed Policies

A Managed Policy is a policy that is defined separately (from Identities) and can be attached to them (User / Group / Role) at any time.

  • You can add up to 10 managed policies per User / Role / Group
  • Size of each managed policy cannot exceed 6,144 characters
  • Managed Policies are further divided into two categories:
    • AWS Managed Policies are standalone policies that are created and administered by AWS.
      • Each such policy has its own Amazon Resource Name (ARN), and thus uniquely identifiable.
      • Meant for most common use cases. Examples – Full Access to S3, or Full Access to DynamoDB
      • You cannot modify these policies.
    • Customer Managed Policies are created by you for specific purposes.
      • You can create these from scratch, or copy a closely related AWS Managed Policy and then update it
      • These Policies also have unique ARNs


Key Points

  • IAM is a global service that is common across all Regions
  • IAM service may be used via:
    • AWS Management Console
    • AWS Command Line Tools (CLI)
    • AWS SDKs
  • Effect of policies: to determine access, AWS takes in to consideration all policies – Identity and Resource Policies
    • All requests are implicitly denied. A request must be explicitly allowed.
    • An explicit Deny for a request overrules any other allows.


See also

  • AWS Organizations
  • Security Token Service (STS)



There is no charge for using IAM service.