• hey@aysharshad.com
  • Norway
Getting Started with AWS Identity and Access Management (IAM)

Getting Started with AWS Identity and Access Management (IAM)

Identity and Access Management is one of the major components of the Triads of AWS Cloud Security. AWS is a vast collection of over 200 Web Services. And these Web Services are interacted with using API calls. Identity and Access Management provides the means to Authenticate, Secure and Authorize these API calls.

These API calls are either made by Users or other Digital Entities (other Applications or AWS Resources themselves). And Identity and Access Management help authenticate and authorize them all.


Identity and Access Management (IAM) consists of two sections:

  1. I(Identity)-Authentication: Authenticates the requester either a Human entity (User) or Digital Entity (other Applications or AWS Resources).
  2. AM(Access Management)-Authorization: Helps you secure access to AWS Cloud Resources.

IAM Identities

IAM identities are a way to authenticate the API caller. These identities include:

  1. Users
  2. Groups
  3. Roles

API calls are made via three main mediums:

  1. AWS Console
  2. AWS Command Line Interface (CLI)
  3. AWS Language-based Tools and SDKs (like BOTO3, Terraform or Node-Red)


Users are human entities that access AWS Resources based on what permissions they possess. New users have np permissions by default hence everything is implicitly denied.

Users can have two modes of access:

  1. Console Acess
  2. Programmatic Access


IAM User Groups is a way of combining Users so that they can be managed centrally. Permissions are attached to the whole group. A maximum of ten policies can be attached to a user. Hence groups are also used to attach more policies by grouping policies. That way User Groups are also used to group policies as well.


Roles are a way to authenticate digital or non-human entities that include: 

  1. Digital processes (API calls made by AWS Resources)
  2. Cross account access
  3. Federated Users

In order to provide access to these entities, policies are attached to these roles. Roles never work unless they are assumed by some entity.


After the actors are authenticated second part comes where their scope of access is defined. Policies are written in JSON and they decide what kind of API call a Principal is allowed to make on a particular resource. Policies never work unless they are attached to some other identity.

Types of IAM Policies

IAM Policies can be categorized into two types based on Actors:

  1. Identity-based Policies: Describes what an identity (users, groups and roles) has access to. 
  2. Permission Boundary: Describes the maximum amount of access an Identity-based Policy can provide to an identity. Access of an entity to a resource is decided if allowed by both Identity-based Policy and Permission boundary.
  3. Resource-based Policies: Describes who has access to a specific resource. 

A further classification of Identity-based Policies include two types:

  1. AWS Managed Policies: These policies are pre-designed by AWS and just need to be attached to users.
  2. Customer Managed Policies: Customer Managed Policies are a customer-specific combination of permission sets and they can be attached to any entity(users, groups and roles).
  3. Inline Policies: Inline Policies are also a kind of customer-managed policy but they are limited to the scope of a specific user or role. 

Resource Glossary

error: Content is protected. You are automatically reported to the Authorities!