AWS IAM: Deep Dive into the Basics

15 Mar, 2026

It is not my intention to describe all the basic vocabulary and functionality of AWS IAM in this text. Rather, I combine the basic concepts and organize them in a structured way.

Policies

Main Elements

Every policy includes the following parts:

• Principal
• Resource (or NotResource)
• Action (or NotAction)

In essence, a policy allows or forbids a certain principal to perform a listed action on a given resource.

Classification

There are two main ways to classify policies:

• identity-based and resource-based;
• inline and managed.

If we combine these two classifications, we get the following possible combinations:

1. Inline identity-based
2. Managed identity-based
3. Inline resource-based
4. Managed resource-based

We have only three because Managed resource-based one does not exist on AWS.

I use the following diagram to help myself remember it:

Now, to understand identity-based policies, let's talk about identities and how they differ from principals.

Identities vs Principals

Identity

Identity-based policies describe which identities can do what. What is an identity, then? AWS does not provide a definition of an IAM identity, but it lists the 4 kinds of identities (https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html):

• root user
• user
• user group
• role

We can describe an IAM identity as an IAM resource that represents something you manage in your account and to which you attach permission policies.

Principal

A principal is an entity that actually makes a request to the AWS API. It accesses AWS resources and performs actions on them. The kinds of principals are described here: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html.

Identity-Based vs Resource-Based Policies

Identity-Based

All policies include a principal. In identity-based policies the principal is implied. But how can the principal be implied if a policy is attached to an identity, not a principal? Now we know that an identity-based policy describes which action a given identity may perform on a specified resource. During the request, identities act as a principal:

• A user acts as a principal.
• A user group does not act as a principal. The actual requester is always a user that receives permissions through a group.
• A role acts as a principal through an assumed-role session.

Resource-Based

This kind of policy deals with the same elements (principal, resource and action) from a resource perspective. For a given resource, it states which principal can do what. It can only be inline.

Diagram

We can illustrate the identity-based vs resource-based kinds of policies in a diagram:

Examples

Earlier I provided the following classification: inline indentity-based, managed identity-based, inline resource-based. This is all good in theory. But a good engineer needs to zoom into each one, understand why each of them exists, and see what the practical use cases are.

1. Managed identity-based policies. We create them for reusability and central management. Example: a managed policy that grants read-only access to a specific S3 bucket. You can attach it to multiple IAM users or roles that need that access.
2. Inline identity-based policies. We create them when we do not expect the policy to ever be reused. We simply define it in place. Example in SAM code:

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    Policies:
      - Statement:
          - Effect: Allow
            Action:
              - s3:GetObject
              - s3:GetObjectVersion
            Resource:
              - arn:aws:s3:::mybucket-*

The policy ends up attached to the execution role of the MyFunction Lambda function and allows it to retrieve objects from a bucket.

3. Inline resource-based. There are many specific use-cases. I will write a dedicated article on resource-based policies. For now, let's consider another SAM example:

TriggerFunction:
  Type: AWS::Serverless::Function
  Properties:
    # This results in Lambda's resource-based policy
    Events:
      S3Event:
        Type: S3
        Properties:
          Bucket: !Ref MyBucket
          Events: s3:ObjectCreated:*

SAM will automatically add a resource-based policy that allows S3 to invoke the Lambda function.