Amazon Web Services Identity and Access Management (IAM) is a security framework and web service that securely controls who can access AWS resources and what actions they are allowed to perform, acting as the backbone of account-level security in AWS. It manages:
Authentication: who can sign in
Authorization: what actions they are allowed to perform
IAM Users represent individual people or applications requiring long-term access to AWS.
Have permanent credentials (passwords and access keys)
Used for console, CLI, or API access
Best managed through groups, not individually
2. IAM Groups
IAM Groups are collections of users that simplify permission management.
Permissions are assigned once at the group level
Users inherit permissions automatically
Reduces administrative errors and improves scalability
3. IAM Roles
IAM Roles provide temporary permissions to trusted entities without using long-term credentials.
No passwords or access keys
Uses temporary, auto-rotated credentials
Ideal for AWS services and cross-account access
Most secure method for application permissions
4. IAM Policies
IAM Policies define what actions identities can perform on which AWS resources. Policies are written in JSON format.
Each policy contains:
Effect: Allow or Deny
Action: AWS operations such as s3:GetObject
Resource: Specific AWS resources
Types of IAM Policies
AWS-Managed Policies: Policies created and maintained by AWS for common use cases.
Customer-Managed Policies: Custom policies created and managed by users based on organizational requirements.
Inline Policies: Policies embedded directly into a single IAM user, group, or role.
Resource-Based Policies: Policies attached directly to AWS resources such as S3 bucket policies.
Feature
IAM User
IAM Group
IAM Role
IAM Policies
Purpose
Represents a specific person or application with long-term credentials.
A logical container to simplify permission management across users.
A temporary identity assumed by trusted entities for specific tasks.
Defines permissions that specify what actions are allowed or denied on AWS resources.
Credentials
Permanent (password, access keys).
None; not an identity.
Temporary, automatically rotated credentials.
No credentials; attached to users, groups, or roles.
Use for Humans
Rarely used for direct access; reserved for administrative or break-glass scenarios.
Assign common permissions (e.g., Developers, Auditors).
Grant short-term, elevated, or cross-account access.
Control what users and groups can access in AWS.
Use for Services
Not recommended due to long-term key risks.
Not applicable.
Best practice for service-to-service access (e.g., EC2 → S3).
Define permissions for AWS services and resource access.
Workflow of IAM
Identity and Access Management (IAM) works by clearly defining who can access AWS, what they can access, and under what conditions. Its working can be understood in the following flow:
1. Identify the User or Entity (Who)
IAM first identifies who is requesting access. This could be:
An IAM user (human)
An application or service
An AWS service assuming a role
2. Authenticate the Request
IAM verifies the identity using authentication mechanisms like:
Username and password
Access keys
Multi-Factor Authentication (MFA) (Only authenticated identities can proceed further.)
3. Authorize Using Policies (Can Access)
After authentication, IAM checks policies attached to the user, group, or role. These policies define:
Allowed or denied actions (e.g., s3:GetObject)
Specific resources (e.g., a particular S3 bucket)
Conditions (time, IP address, MFA usage)
4. Evaluate Permissions
IAM evaluates permissions in this order:
Explicit Deny: always blocks access
Explicit Allow: grants access
Implicit Deny: default if no allow exists
Access is granted only if an explicit allow exists and no deny overrides it.
5. Grant Access to Resources (What)
If authorization succeeds, IAM allows the user or service to perform the requested action on the specified AWS resource such as:
EC2 instances
S3 buckets
RDS databases
6. Temporary Access via Roles (Optional but Recommended)
For applications and services, IAM roles provide temporary credentials instead of long-term keys, improving security and reducing credential misuse.
Access management determines who can access which AWS resources and what actions they can perform.
Based on the principle of least privilege
Prevents over-permissioning
Improves security posture and compliance
Federation and Single Sign-On (SSO)
Federation allows external users to access AWS using existing identity providers.
Supports corporate directories and social logins
Enables Single Sign-On (SSO)
Reduces password fatigue and improves security
Role-Based Access Control (RBAC)
RBAC assigns permissions based on job roles rather than individual users.
Simplifies access control
Aligns permissions with organizational structure
Minimizes security risks caused by excess privileges.
Types of Permissions
Allow Permissions: An explicit "allow" permission grants the user, group, or role access to a resource. For Example, an IAM user with the "s3:ListBucket" permission can list the content of an S3 Bucket.
Deny Permissions: A "deny" permission explicitly prevents access to a resource. This can be set for security reasons, such as denying access to sensitive resources for certain users.
Implicit Deny: By default, if no policy is attached to a user, group, or role, access to a resource is denied. IAM denies access if no explicit allow rule is present.
How to Set Up IAM
Setting up IAM involves creating users, groups, roles, and policies that define what resources and actions are allowed. Below is a simple process for getting started:
Step 1: Create an IAM User
Open the IAM Console and click Users then Create User.
Enter the username, select the access type (e.g., programmatic or console access), and assign permissions.
To enhance security, enable MFA for critical IAM users (such as admins). MFA adds an extra layer of protection by requiring users to provide a second form of authentication (e.g., a mobile app).
Note: For the detailed setup and configuration process of Multi-Factor Authentication (MFA) in AWS, refer to the dedicated MFA article.
Step 4: Create IAM Roles
IAM roles can be created for cross-account access or to give AWS services permissions to interact with each other (E.g., EC2 needs access to S3).
Protects systems from unauthorized access and credential misuse
Controls user identities, roles, and permissions centrally
Supports fine-grained access control using IAM policies
Follows the principle of least privilege for stronger security
Supports secure scaling of users, applications, and AWS services
Best Practices
Lock Away Your Root User Credentials: Do not use the root user for daily tasks. Enable MFA on it and store the credentials securely.
Enforce the Principle of Least Privilege: Always grant only the minimum permissions required for a user or application to perform its task. Start with nothing and add permissions as needed.
Use Groups to Assign Permissions to Users: Never attach policies directly to individual users.
Use Roles for Applications and AWS Services: This avoids the need to manage long-term access keys.
Enable Multi-Factor Authentication (MFA): Add an extra layer of security for all your users, especially privileged ones.
Rotate Credentials Regularly: Implement a policy to rotate passwords and access keys periodically.
IAM Technologies and Tools
Single Sign-On (SSO): A choice that lets a user login and use multiple applications at once, as well as give more security to the services. Example: Its competitors include Okta and Microsoft Entra AD (Formerly Azure AD).
Multi-Factor Authentication (MFA): MFA requires users to verify their identity using two or more authentication methods. Example: Some of the examples of Two Factor Authentication applications are Duo Security and Google Authenticator.
Role-Based Access Control (RBAC): Secures the system based on employees’ roles, where the user will have the least privilege to access the system. Example: IBM Security Identity Manager.
Privileged Access Management (PAM): Performs functions associated with obtaining and maintaining high levels of accessible (“privileged”) computing resources. Example: CyberArk, BeyondTrust.
