AWS IAM Explained for Developers: Users, Roles, Policies, and Permissions

AWS gives developers access to hundreds of cloud services, but access itself needs to be controlled carefully.

An application may need to read files from Amazon S3.

A backend service may need to access a database.

An EC2 instance may need to send logs to another AWS service.

A developer may need access to AWS resources without being allowed to delete production infrastructure.

This is where AWS Identity and Access Management (IAM) becomes important.

IAM controls who or what can access AWS resources and what actions they are allowed to perform.

For developers, the most important IAM concepts are:

• Users
• Groups
• Roles
• Policies
• Permissions
• Resources
• Actions
• Least privilege
• Temporary credentials

The most important idea is simple:

Do not give an application more AWS permissions than it actually needs.

Quick Answer

A simplified IAM relationship looks like this:

1. What Is AWS IAM?

AWS Identity and Access Management is the AWS service used to control access to AWS resources.

For example, imagine a backend application that needs to upload images to an S3 bucket.

The application should be able to:

Upload image
Read image

But it probably should not be able to:

Delete the entire bucket
Create IAM users
Modify billing
Delete EC2 instances

IAM allows you to create permissions around these actions.

2. Why IAM Matters to Developers

IAM is not only an administrator's topic.

Developers interact with IAM whenever an application communicates with AWS services.

Common examples include:

• Backend → S3
• EC2 → S3
• Lambda → DynamoDB
• GitHub Actions → AWS
• Application → Secrets Manager
• ECS → CloudWatch
• CI/CD → ECR
• Server → SQS

A common architecture looks like:

The application does not need unrestricted access to AWS.

Instead, it receives specific permissions.

3. IAM Users

An IAM user represents an identity within an AWS account.

Historically, developers commonly created IAM users with access keys and used those credentials from applications or command-line tools.

For example:

Developer
   |
   v
IAM User
   |
   v
Permissions
   |
   v
AWS Resources

However, applications should generally avoid storing long-lived AWS access keys when a role or another temporary credential mechanism can be used instead.

For human access, modern AWS environments often prefer centralized identity and temporary credentials rather than creating individual long-lived access keys for everyday work.

4. IAM Groups

Groups allow users to be organized based on their responsibilities.

For example:

Developers
 ├── Developer A
 ├── Developer B
 └── Developer C

Operations
 ├── Engineer A
 └── Engineer B

A group can have policies attached to it.

For example:

Developers
   |
   +-- Read S3
   +-- Read CloudWatch
   +-- Read EC2

This makes permission management easier than manually assigning the same policies to every user.

5. IAM Roles

Roles are one of the most important IAM concepts for developers.

A role is an identity that can be assumed by a trusted principal.

Applications commonly use roles instead of storing permanent access keys.

For example:

EC2 Instance
      |
      v
   IAM Role
      |
      v
   IAM Policy
      |
      v
    S3 Bucket

The EC2 instance can obtain temporary credentials associated with the role.

The application does not need to keep an AWS access key and secret key inside its source code.

6. Why Roles Are Better for Applications

Consider this bad pattern:

const accessKey = "YOUR_ACCESS_KEY";
const secretKey = "YOUR_SECRET_KEY";

Never put real AWS credentials directly into source code.

It creates several risks:

• credentials can accidentally reach Git
• credentials can appear in logs
• credentials can be copied by another developer
• leaked credentials may be abused
• rotating credentials becomes harder

A better architecture is:

The application receives credentials through the AWS environment rather than embedding permanent secrets in the code.

7. IAM Policies

A policy defines permissions.

A simplified policy might say:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::example-bucket/*"
}

This means the identity can perform:

s3:GetObject

against objects inside:

example-bucket

A policy is essentially a set of permission statements.

8. Understanding a Policy

A typical IAM policy statement contains concepts such as:

Effect
Action
Resource

For example:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::example-bucket/*"
}

Effect

Determines whether the statement allows or denies an action.

Common values:

Allow
Deny

Action

Defines what operation is being requested.

Examples:

s3:GetObject
s3:PutObject
s3:DeleteObject

Resource

Defines which AWS resource the action applies to.

For example:

arn:aws:s3:::example-bucket/*

9. Allow vs Deny

An IAM policy can explicitly allow or deny an action.

For example:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::example-bucket/*"
}

Another statement could explicitly deny an operation.

The important practical rule is:

An explicit deny overrides an allow.

This is one reason IAM policies need to be designed carefully.

10. What Is Least Privilege?

Least privilege means giving an identity only the permissions it needs to perform its job.

Suppose an image-processing application needs to read images from S3.

A broad permission such as:

s3:*

may give it far more access than necessary.

A narrower permission might be:

s3:GetObject

for a specific bucket or object path.

The difference is significant.

The narrower permission reduces the potential impact if the application is compromised.

11. Wildcard Permissions

You will often see wildcards in IAM policies.

For example:

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

This is extremely broad.

It effectively grants all S3 actions across all resources covered by the policy.

For learning or temporary testing, broad permissions may sometimes appear in examples.

For production applications, avoid using broad permissions when narrower permissions are possible.

12. A Better S3 Example

Suppose a backend application only needs to upload profile images.

Instead of allowing every S3 action:

s3:*

you might grant only:

s3:PutObject

against the appropriate resource.

Conceptually:

Application
     |
     v
IAM Role
     |
     v
PutObject
     |
     v
profile-images/*

This is much closer to the least-privilege model.

13. IAM and EC2

EC2 instances often need to communicate with other AWS services.

For example:

EC2 Application
      |
      v
   S3 Bucket

One approach is to assign an IAM role to the EC2 instance.

The application can then use AWS SDKs or the AWS CLI without embedding permanent credentials into the application.

14. IAM and Lambda

Lambda functions can also use IAM roles.

For example, a Lambda function may need to write records to DynamoDB.

Lambda Function
      |
      v
Execution Role
      |
      v
DynamoDB Permissions
      |
      v
DynamoDB Table

The role defines what the Lambda function is allowed to do.

15. IAM and S3

S3 is one of the easiest places to understand IAM.

Suppose you have:

my-app-assets

Your application may need:

GetObject
PutObject

But not:

DeleteBucket

The policy should reflect the application's actual requirements.

For example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-app-assets/*"
    }
  ]
}

The exact policy required depends on the application's behavior and AWS resource configuration.

16. IAM vs Authentication

These concepts are related but different.

Authentication

Answers:

Who are you?

Authorization

Answers:

What are you allowed to do?

IAM is primarily concerned with identity and authorization within AWS.

For example:

Authentication
      |
      v
Identity
      |
      v
Authorization
      |
      v
Allowed AWS Actions

A developer may successfully authenticate to AWS but still receive:

AccessDenied

because the identity does not have the required permission.

17. IAM vs Application Authentication

Do not confuse AWS IAM with user authentication in your own web application.

For example, Karyvio might have:

User
  |
  v
Karyvio Login
  |
  v
Application Session

AWS IAM controls access to AWS resources:

Application
  |
  v
AWS IAM
  |
  v
S3 / EC2 / Lambda / DynamoDB

They solve different problems.

18. IAM Access Keys

AWS access keys generally consist of an access key ID and a secret access key.

For example:

Access Key ID
Secret Access Key

They can be used by tools and applications to authenticate requests.

The important security rule is:

Never commit real AWS access keys to GitHub.

Avoid:

.env
config.js
credentials.json

containing real secrets when those files could reach source control.

Use appropriate credential-management mechanisms instead.

19. AWS CLI and IAM

The AWS CLI can use configured credentials to interact with AWS.

For example:

aws sts get-caller-identity

This command is useful when troubleshooting because it tells you which AWS identity is currently being used.

For example, if your application unexpectedly receives an access-denied error, checking the active identity can help determine whether you are using:

• the expected user
• the expected role
• the expected AWS account

20. Debugging AccessDenied

Suppose your application returns:

AccessDenied

Do not immediately add administrator permissions.

Instead, investigate the request.

A useful troubleshooting flow is:

Ask:

1. Which identity made the request?
2. What AWS action was requested?
3. Which resource was requested?
4. Does the policy allow that action?
5. Is the resource ARN correct?
6. Is there an explicit deny?
7. Are there additional policies affecting the request?

This approach is much safer than simply adding:

AdministratorAccess

21. Common IAM Mistakes

Mistake 1: Giving AdministratorAccess to applications

An application usually does not need administrative access to the AWS account.

If the application only uploads files:

s3:PutObject

may be enough.

Mistake 2: Storing credentials in source code

Bad:

const secret = "real-secret";

Never commit real credentials.

Mistake 3: Using * everywhere

This:

"Action": "*",
"Resource": "*"

is extremely broad.

Prefer specific actions and resources.

Mistake 4: Creating permanent credentials unnecessarily

If AWS can provide temporary credentials through a role or another supported identity mechanism, prefer that approach.

Mistake 5: Fixing every AccessDenied error with more permissions

An access error should trigger investigation.

More permissions are not automatically the correct solution.

22. IAM for CI/CD

CI/CD systems may also need AWS permissions.

For example:

A deployment workflow might need permission to:

• upload an artifact
• push an image
• update a service
• deploy infrastructure

It should not automatically receive full administrator permissions.

The deployment identity should have only the permissions required for that pipeline.

23. IAM and Developer Jobs

AWS IAM appears frequently in real cloud and DevOps work.

Developers working with AWS should understand:

• IAM users
• IAM roles
• IAM policies
• AWS CLI credentials
• temporary credentials
• resource-based permissions
• least privilege
• access-denied troubleshooting
• service roles
• CI/CD identities

For cloud-focused roles, IAM is not an optional security topic.

It is part of everyday AWS architecture.

24. A Practical IAM Project

A useful beginner project is to build a small application that uploads files to S3.

Architecture:

Step 1

Create an S3 bucket for application assets.

Step 2

Create an IAM role for the application.

Step 3

Give the role only the required S3 permissions.

Step 4

Run the backend using the AWS-supported credential mechanism for that environment.

Step 5

Upload an object.

Step 6

Remove one required permission and reproduce the access error.

Step 7

Inspect the identity and policy to understand why the request failed.

This teaches much more than simply memorizing IAM terminology.

25. A Simple IAM Mental Model

Think about IAM as a permission decision:

WHO
 |
 v
Identity
 |
 v
WHAT
 |
 v
Action
 |
 v
WHERE
 |
 v
Resource
 |
 v
ALLOWED?

For example:

EC2 Application
     |
     v
s3:GetObject
     |
     v
my-app-assets/*
     |
     v
Allowed

That mental model is useful when debugging almost any IAM problem.

26. Best Practices for Developers

Use these principles when working with AWS:

• Prefer IAM roles for AWS workloads where supported.
• Use temporary credentials where practical.
• Avoid hard-coded secrets.
• Avoid committing credentials to Git.
• Follow least privilege.
• Restrict actions to what the application needs.
• Restrict resources where practical.
• Review unused permissions.
• Separate development and production access.
• Avoid using administrator permissions for applications.
• Investigate AccessDenied instead of blindly adding permissions.
• Use centralized identity and appropriate MFA for human access.

AWS IAM Cheat Sheet

Interview Questions

1. What is AWS IAM?

IAM is AWS's identity and access-management service for controlling access to AWS resources.

2. What is an IAM role?

A role is an identity with permissions that can be assumed by trusted principals such as AWS services, workloads, or users.

3. What is an IAM policy?

A policy defines permissions through statements describing actions, resources, and effects.

4. Why should applications use roles instead of hard-coded AWS credentials?

Roles can provide temporary credentials and avoid embedding long-lived secrets directly into application code.

5. What is least privilege?

Giving an identity only the permissions necessary to perform its required tasks.

6. What should you check when receiving AccessDenied?

Check the caller identity, requested action, resource, applicable policies, and any explicit deny.

7. What is the difference between authentication and authorization?

Authentication establishes identity. Authorization determines what that identity is allowed to do.

Final Takeaway

AWS IAM is fundamentally about answering one question:

Who or what is allowed to do what, on which AWS resource?

Once you understand that model, the rest of IAM becomes easier.

Remember the core concepts:

User
Role
Policy
Action
Resource
Permission
Least Privilege

For developers, the most important practical lesson is to design applications so they receive only the AWS access they actually need.

Do not start with:

"How can I give this application access to everything?"

Start with:

"What exact AWS operation does this application need?"

Then give it that permission and nothing more.

That mindset leads to safer cloud applications and is one of the most important foundations for working with AWS professionally.