AWS Identity and Access Management (IAM)
This article provides a clear introduction to AWS Identity and Access Management (IAM). It explains how IAM controls access to AWS resources using users, groups, policies, and roles. It covers authentication and authorization, IAM policies, the root user, temporary credentials, EC2 roles, instance profiles, identity federation, and the principle of least privilege, with simple examples for beginners.
AWS Identity and Access Management (IAM)
Introduction
AWS Identity and Access Management (IAM) is an AWS service that helps securely control access to AWS resources. It allows organizations to manage who can access AWS services, what actions they can perform, and which resources they can access.
IAM is an important part of AWS security because not every user, application, or service should have full access to an AWS account.
The main concepts of IAM include users, groups, policies, roles, authentication, authorization, and identity federation.
1. Authentication and Authorization
Before accessing AWS resources, a user needs to be authenticated and authorized.
Authentication
Authentication answers:
"Who are you?"
For example, when a user signs in to AWS using their credentials, AWS verifies their identity.
Authorization
Authorization answers:
"What are you allowed to do?"
After the identity is verified, AWS checks the permissions assigned to that identity.
For example, a user might be allowed to read objects from an S3 bucket but not delete them.
Therefore:
- Authentication = Who are you?
- Authorization = What can you do?
2. Ways to Access AWS
AWS services and resources can be accessed in several ways:
- AWS Management Console — graphical web interface
- AWS Command Line Interface (CLI) — command-line tool
- AWS SDKs — programming libraries used by applications
- AWS APIs — allow applications to communicate directly with AWS services
IAM helps control access regardless of which method is used.
3. IAM Users
An IAM user represents an individual identity in an AWS account.
For example, an organization might create separate IAM users for different employees.
Each user can have credentials used for authentication.
However, creating a user does not automatically give that user access to AWS resources. Permissions must be provided through IAM policies or other appropriate mechanisms.
4. IAM Groups
An IAM group is a collection of IAM users.
Groups make permission management easier when an organization has many users.
For example, an organization might create:
- Developers group
- Finance group
- Human Resources group
A policy can be attached to the Developers group. Users added to that group can then receive the permissions associated with the group.
Instead of assigning the same permissions individually to many users, administrators can manage permissions at the group level.
Example
1
2
3
4
5
Developers Group
|
|-- User 1
|-- User 2
|-- User 3
If the Developers group has permission to access certain AWS services, members of the group can receive those permissions.
5. IAM Policies
An IAM policy defines permissions in AWS.
IAM policies are written in JSON format and specify what actions are allowed or denied.
Important elements of a policy include:
Effect
Defines whether an action is:
- Allow
- Deny
Action
Specifies what operation can be performed.
For example, an S3 policy might allow a user to read an object.
Resource
Specifies the AWS resource to which the permission applies.
For example, the policy could apply to a specific S3 bucket.
Condition
Specifies additional requirements under which the permission applies.
For example, access might be allowed only when a request comes from a particular IP address.
Therefore, a policy can be understood using:
Effect + Action + Resource + Condition
Not every policy needs a condition.
6. Default Deny
IAM follows an important security principle: access is not automatically granted.
If a user does not have permission to perform an action, that action is denied.
For example:
1
2
3
4
5
User
|
|-- Read S3 object → Allowed
|
|-- Delete S3 object → Not allowed
If the user has only been given permission to read an S3 object, they should not automatically receive permission to delete it.
This helps organizations follow the principle of giving users only the permissions they need.
7. Using Groups and Policies Together
A common way to manage IAM permissions is:
- Create an IAM group.
- Create or select an appropriate IAM policy.
- Attach the policy to the group.
- Create IAM users.
- Add users to the appropriate groups.
For example:
1
2
3
4
5
6
7
Development Group
|
↓
Development Policy
|
↓
User 1, User 2, User 3
This approach makes permission management easier as the organization grows.
8. AWS Root User
Every AWS account has a root user.
The root user has full access to all AWS resources and services in the account.
Because of its high level of access, AWS recommends avoiding the root user for normal daily activities.
The root user should generally be reserved for tasks that specifically require root-level access, such as certain initial account setup activities.
For everyday administration, an appropriate IAM identity should be used instead.
9. IAM Roles
An IAM role is an identity that has permissions but does not have long-term credentials associated with it.
Instead, when a user, application, or AWS service assumes a role, temporary security credentials can be provided.
Roles are useful when temporary or delegated access is required.
Example
A user normally has limited permissions:
1
2
3
User
|
└── Normal permissions
When the user needs additional permissions, they can assume a role:
1
2
3
4
5
6
7
User
|
↓
Assume Role
|
↓
Temporary permissions
After the role is no longer needed, the user returns to their normal permissions.
10. Why IAM Roles Are Important
IAM roles reduce the need to use long-term credentials.
Suppose an application running on an Amazon EC2 instance needs to access an Amazon S3 bucket.
One approach would be to place AWS access keys directly inside the application's source code.
This is not a good security practice because credentials could be exposed and rotating those credentials would require changes to the application.
A better approach is to use an IAM role.
1
2
3
4
5
6
7
8
9
10
EC2 Instance
|
↓
IAM Role
|
↓
Temporary Credentials
|
↓
Amazon S3
The application can use the permissions provided through the role without storing long-term AWS credentials in its source code.
11. IAM Roles and Instance Profiles
When an IAM role is associated with an Amazon EC2 instance, an instance profile is used to pass the role to the instance.
The overall concept is:
1
2
3
4
5
6
7
8
9
10
11
12
13
EC2 Instance
|
↓
Instance Profile
|
↓
IAM Role
|
↓
Temporary Credentials
|
↓
AWS Services
This allows applications running on EC2 to securely access AWS resources.
12. Roles for Temporary Administrative Access
Roles can also be used when a user occasionally needs additional permissions.
For example, suppose an employee normally has limited access to an S3 bucket.
Sometimes the employee may need administrative permissions to perform a specific task.
Instead of permanently changing the employee's permissions, an administrator can create a role with the required permissions.
The user can then assume the role when necessary.
1
2
3
4
5
6
7
8
9
10
11
12
13
Normal User
|
↓
Assume Administrative Role
|
↓
Temporary Administrative Access
|
↓
Complete Task
|
↓
Return to Normal Permissions
This avoids repeatedly changing the user's normal policy.
13. Identity Federation
IAM also supports identity federation.
Identity federation allows users from an external identity system to access AWS without requiring a separate IAM user for every person.
For example, an organization may already use:
- Microsoft Active Directory
- Another third-party identity provider
The user can authenticate through the existing identity provider and then obtain access to AWS by assuming an appropriate IAM role.
The basic flow is:
1
2
3
4
5
6
7
8
9
10
11
12
13
External User
|
↓
Identity Provider
|
↓
Authentication
|
↓
IAM Role
|
↓
AWS Resources
This is especially useful for organizations that already have a centralized identity management system.
14. IAM and the Principle of Least Privilege
A key security idea behind IAM is the principle of least privilege.
This means:
Give a user, application, or service only the permissions required to perform its job.
For example, if an application only needs to read files from an S3 bucket, it should not receive permission to delete the entire bucket.
Instead:
1
2
Required permission → Read S3 objects
Unnecessary permission → Delete S3 bucket
This reduces the risk of accidental or unauthorized changes.
15. Real-World IAM Example
Imagine a software company with three departments:
1
2
3
4
5
Company
|
|-- Development
|-- Finance
|-- HR
The company can create:
1
2
3
Development Group
Finance Group
HR Group
Each group receives appropriate policies.
For example:
1
2
3
4
5
6
7
8
9
10
11
Development Group
↓
Development permissions
Finance Group
↓
Finance permissions
HR Group
↓
HR permissions
Employees are then added to the correct groups.
If a developer joins the company, the administrator can create an IAM user and add that user to the Development group.
The user receives the permissions associated with that group.
17. Key IAM Workflow
A simple IAM workflow can be represented as:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
User/Application
|
↓
Authentication
|
↓
Identity
|
↓
Permissions / Policy
|
↓
Authorization
|
↓
AWS Resource
For a role-based application:
1
2
3
4
5
6
7
8
9
10
11
12
13
Application
|
↓
Assume IAM Role
|
↓
Temporary Credentials
|
↓
Authorization
|
↓
AWS Resource
Conclusion
AWS Identity and Access Management is a fundamental AWS security service used to control access to AWS resources.
IAM allows organizations to create and manage users and groups, define permissions using policies, and provide temporary access through IAM roles.
Authentication determines who a user is, while authorization determines what that user is allowed to do.
IAM roles are especially useful for applications and AWS services because they allow temporary credentials to be used instead of storing long-term credentials in application code.
IAM also supports identity federation, allowing organizations to use existing identity providers such as Microsoft Active Directory or other external identity systems.
By using IAM correctly and following the principle of least privilege, organizations can improve the security of their AWS environments while giving users and applications only the access they actually need.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article