AWS IAM Simply Explained

This one is a bit deeper and longer to read. Ensure you bookmark this article to revisit it later!

A Lambda function cannot upload a file to S3. A deployment fails with AccessDenied. Someone accidentally gives a developer admin access. An audit finds roles with permissions they never needed.

Until then, IAM feels like theoretical.

But every request made to AWS passes through IAM.

Starting an EC2 instance, reading an S3 object, updating DynamoDB, accessing Secrets Manager or deploying through CI/CD all depend on one decision:

Should AWS allow this request or deny it?

Once you understand how AWS makes that decision, IAM becomes much easier.

IAM stands for Identity and Access Management.

It answers three basic questions:

For example:

AWS checks all applicable policies and then allows or denies the request.

IAM mainly handles authentication and authorization.

Authentication confirms who you are.

This can happen through:

Authorization decides what you are allowed to do after AWS knows your identity.

Successfully logging in does not mean you have permission to perform actions.

An IAM user can log in successfully and still receive AccessDenied for every AWS API request.

You do not need to memorize every IAM feature on day one.

Start with these two rules.

AWS starts with an implicit deny.

Unless a policy explicitly allows an action, AWS blocks it.

For example, creating a role does not automatically give it access to S3, EC2 or DynamoDB. You must explicitly allow those actions.

Suppose one policy allows S3 access, but another policy explicitly denies it.

The final result is deny.

It does not matter how many policies allow the action. One matching explicit deny is enough to block the request.

A useful troubleshooting method is:

IAM has four important identity types.

An IAM user is a long-term identity inside one AWS account.

It can have:

IAM users were commonly used for developers and applications in older AWS setups.

Today, AWS roles and temporary credentials are preferred.

Long-term IAM user credentials can be copied, leaked, forgotten or accidentally committed to Git.

A group is simply a collection of IAM users.

For example, you may create groups such as:

Instead of attaching the same policy to 20 users, you attach it once to the group.

Groups cannot log in, make API calls or be assumed. They only make user permission management easier.

Roles are the preferred way to provide AWS access.

A role does not normally have permanent credentials. It provides temporary credentials when someone or something assumes it.

Roles are commonly used by:

Temporary credentials expire automatically, which makes them safer than permanent access keys.

The root user is created when the AWS account is created.

It has full control over the account and can perform some actions that normal IAM identities cannot.

You should:

Do not use the root user for daily AWS work.

IAM permissions are written as JSON policy documents.

A basic policy contains:

Example:

This policy allows reading objects from one specific S3 bucket.

It does not allow:

That is what least privilege should look like.

There are several policy types in AWS, but juniors should first understand these five.

These policies are attached to users, groups or roles.

They define what that identity can do.

For example, a Lambda role may have permission to:

Identity policies can be managed or inline.

Managed policies are reusable and can be attached to multiple identities.

Inline policies exist directly inside one user, group or role.

Managed policies are generally easier to reuse, audit and maintain.

These policies are attached directly to resources.

Common examples include:

A resource policy usually answers:

Which principal can access this resource?

For example, an S3 bucket policy can allow a role from another AWS account to upload objects.

Resource policies are especially important for cross-account access.

A trust policy is attached to an IAM role.

It controls who is allowed to assume that role.

A role can have permission to access S3, but nobody can use that role unless its trust policy allows them to assume it.

This is a common source of confusion.

For role assumption to work:

Both sides must be configured correctly.

A permissions boundary sets the maximum permissions a user or role can receive.

It does not grant permission by itself.

Suppose a role policy allows S3 and EC2, but its permissions boundary only allows S3.

The role can use S3, but not EC2.

Think of a permissions boundary as a ceiling.

The role still needs an identity policy that allows the action. The boundary only limits how far those permissions can go.

Boundaries are useful when teams are allowed to create IAM roles but should not be able to grant unlimited access.

Service Control Policies, or SCPs, are applied through AWS Organizations.

They set permission limits for entire AWS accounts or organizational units.

For example, an SCP may:

SCPs do not grant permissions.

A role may have AdministratorAccess, but an SCP can still block specific actions.

This is why a permission problem may not be visible when you only inspect the IAM role.

AWS credentials generally fall into two categories.

IAM user access keys are long-term credentials.

They include:

These credentials remain valid until they are manually disabled or deleted.

That creates several risks:

Access key IDs beginning with AKIA are usually long-term IAM user credentials.

Temporary credentials are normally issued by AWS STS.

They contain:

Access key IDs beginning with ASIA are normally temporary credentials.

Temporary credentials are safer because they automatically expire.

Use temporary credentials wherever possible.

Common patterns include:

You should not place AWS access keys inside application code, Git repositories, Dockerfiles or Kubernetes manifests.

In most cases, the correct solution is to attach or assume a role.

Imagine a Lambda function tries to read an object from S3.

AWS roughly follows this process.

AWS verifies the Lambda role's temporary credentials.

AWS collects information such as:

AWS checks relevant policies, including:

Any matching explicit deny blocks the request.

At least one applicable policy must allow the request.

The permission must also be inside the limits set by boundaries, SCPs and session policies.

When AWS finds no valid allow, the request is denied.

That is the basic IAM evaluation model.

Most workloads access resources inside the same AWS account.

The normal pattern is to attach permissions to the workload's role.

For example, suppose a Lambda function needs to:

Its role should receive only those permissions.

Avoid broad policies such as:

This may quickly fix an AccessDenied error, but it gives the workload access to almost everything in the account.

A production policy should use:

Start small and add permissions based on actual requirements.

Cross-account access involves two AWS accounts.

The most common method is role assumption.

Suppose Account A needs access to resources in Account B.

Account B creates a role with:

The identity in Account A also needs permission to call sts:AssumeRole on that role.

Another method is a resource-based policy.

For example, an S3 bucket in Account B can directly allow a role from Account A to upload objects.

Cross-account problems usually happen because only one side was configured.

Always check:

Creating IAM users for every developer does not scale well.

Modern AWS environments normally use federation or IAM Identity Center.

Users authenticate through an identity provider such as:

After authentication, they assume a role and receive temporary credentials.

This provides several benefits:

When someone leaves the company, disabling their identity provider account removes their AWS access.

You do not need to manually search every AWS account for IAM users and access keys.

CI/CD systems also need AWS access.

The unsafe method is storing an IAM user's access key as a CI/CD secret.

A better method is OIDC federation.

Platforms such as GitHub Actions can use OIDC to request temporary AWS credentials.

The flow is:

There is no permanent AWS secret to rotate or leak.

You can also restrict the role so that only a specific repository, branch or environment can assume it.

Least privilege means giving an identity only the access it requires.

Instead of:

Prefer:

Do not try to create the perfect policy immediately.

A practical process is:

AWS tools such as IAM Access Analyzer, CloudTrail and service last-accessed information can help identify required and unused permissions.

When an AWS request fails with AccessDenied, do not immediately attach AdministratorAccess.

Check the problem in this order.

Find out which user or role is making the request.

From the CLI, you can run:

Do not assume you are using the role you expected.

Your local terminal may be using an old profile, expired session or different AWS account.

The application may say it cannot access S3, but the failed action may actually be:

These actions require different permissions and sometimes different resource ARNs.

The policy may allow the right action on the wrong resource.

For S3, the bucket ARN and object ARN are different.

Bucket:

Objects inside the bucket:

s3:ListBucket normally uses the bucket ARN.

s3:GetObject normally uses the object ARN.

Confirm that the role or user has an applicable allow statement.

Inspect the S3 bucket policy, KMS key policy, SQS policy or other resource policy.

Check:

The failed request may involve more than one AWS service.

An S3 object encrypted with KMS may require:

Allowing S3 alone may not be enough.

CloudTrail shows:

CloudTrail is often the fastest way to stop guessing.

For most DevOps teams, these rules provide a strong starting point:

IAM becomes easier when you stop thinking of it as a large collection of JSON policies.

For every failed request, ask:

Who is making the request?

Which API action are they calling?

Which resource are they accessing?

Which policy allows it?

Is any policy explicitly denying it?

Is a boundary, SCP or session policy limiting it?

The final rules are simple:

You do not need to memorize all of IAM. You need to understand how AWS reaches the final allow or deny decision.

👋 Find me on Twitter | Linkedin | Connect 1:1

Thank you for supporting this newsletter.
Y’all are the best.