Understanding AWS Identity and Access Management (IAM)

Identity and Access Management (IAM) is a security framework that involves policies, processes and technologies for organisations to manage digital identities and human access to critical information and systems. This is a broad topic involving security, and today we will start looking at AWS Identity and Access Management (IAM) at a higher level.

What is AWS Identity and Access Management (IAM)?

IAM is a web service that helps users securely control access to AWS resources by managing users' permissions for which AWS resources they can access. IAM controls who is authenticated (signed in) and authorised (has permissions) to access and use resources within an AWS account(s). In simple, you control the access and IAM provides the infrastructure to control authentication and authorisation for your AWS accounts. IAM is eventually consistent, meaning that changes made are not always immediately visible. Make sure to verify that the changes have been propagated before production workflows depend on them.

Fig1.1 AWS Identity and Access Management

Key IAM Terminologies

Before we go any further, it would be good to define some of the key terminologies you would come across when using IAM so we are on the same page:

Identities

In IAM, an identity refers to an entity that can authenticate with AWS and be authorised to perform actions on AWS resources. These identities are the building blocks for managing access securely. There are different types of identities that you will come across so let's cover them briefly:

1. AWS Account root user - The root user is the default identity created with a new AWS account. It has full access to all services and resources. You sign in using the account’s email and password. AWS advises against using the root user for daily tasks—create IAM identities with specific permissions instead. Keep root credentials secure and use them only for critical account-level actions.

2. IAM User - An identity with specific permissions for a single person or application. Where possible, AWS recommends using temporary credentials rather than relying on long term credentials like passwords and access keys. If you need to use these long-term credentials for specific use cases, then make sure to rotate credentials as recommended by AWS.

3. IAM Role - these are temporary credentials with specific permissions that can be assumed to access resources in an AWS account or cross-account access. Recommended approach as you don't have to deal with passwords and access keys.

4. IAM Groups - identity that specifies a collection of IAM users. You can't sign in as a group, but you use it to define permissions for multiple users. This makes it easier to manage permissions for large sets of users.

How does IAM work?

1. A human or application uses their sign-on credentials to authenticate with AWS. IAM matches these credentials to a principal (an IAM user, AWS STS federated user, IAM role, or application) trusted by the AWS account and authenticates permissions to access AWS.

2. IAM makes a request to grant or deny the principal access to resources in response to the authorisation request. An example is when you access the console. When selecting a service, you send an authorisation request to IAM for that service. IAM verifies your identity is on the authorised list of users, determines the policies covering the level of granted access, and evaluates any other policies that might be in effect. Principals from within the account or from another AWS account that you trust can make the authorisation request.

Once authorised, the principal can then perform actions or operations on those resources in your AWS account e.g spinning up an EC2 instance, etc.

IAM Policies

IAM policies are JSON documents that specify permissions for principal entities. There are several types of policies that can affect an authorisation request. The two most frequently used are identity-based policies and resource-based policies. We will look at these different types of policies in a separate blog post.

IAM checks each policy that applies to the context of the authorisation request. IAM policy evaluation uses an explicit deny, meaning that if a single policy includes a denied action, IAM stops evaluating and denies the entire request. The following are rules that the evaluation logic for a request in a single account follows:

• 🔒 Default Deny: All requests start off denied.

• 👤 Root User Exception: Requests made using root credentials are always allowed.

• ✅ Explicit Allow: If any identity-based or resource-based policy explicitly allows the request, it moves forward.

• 🛡️ Policy Boundaries Check: Even with an allow, the request must pass through SCPs, RCPs, permissions boundaries, and session policies. If any of these deny the request, it’s implicitly denied.

• ❌ Explicit Deny Overrides All: If any policy explicitly denies the request, it’s blocked—no exceptions.

Least-Privilege permissions

An IAM best practice recommendation is to use least-privilege permissions. This is to grant users only the required permissions for them to perform a task and no other additional permissions. The root user and the administrative IAM users have powerful permissions that aren't required for everyday tasks. If you are using IAM Identity Center, consider using permissions sets for access to resources. If you are not using IAM Identity Center, then consider using IAM roles with least-privilege permissions defined for different IAM entities.

Summary

In this introductory post, we explored the foundational concepts of IAM, a critical security framework that governs authentication and authorization across AWS environments. IAM enables organizations to manage digital identities and control access to resources through a combination of users, roles, groups, and policies. We clarified the distinctions between key identities—such as the root user, IAM users, roles, and groups—and emphasized best practices like using temporary credentials and enforcing least-privilege access. We also unpacked how IAM evaluates access requests allowing access only when explicitly permitted. Importantly, any explicit deny overrides all other permissions. Understanding this evaluation logic is essential for designing secure and scalable access strategies in AWS.

Looking ahead, the next post will dive deeper into IAM policies - the JSON-based documents that define permissions for identities and resources. We’ll break down the differences between identity-based and resource-based policies, explore how boundaries and session policies interact, and walk through real-world examples of policy evaluation. You’ll also learn how to troubleshoot access issues using tools like IAM Access Analyzer and Policy Simulator, helping you build confidence in managing permissions with precision and clarity.