AWS Builder Center

Builder Center

AWS IAM: Understanding Identity, Roles, Policies, and Least-Privilege Security

When developers start working with AWS, they quickly encounter a common question: Who is allowed to access this AWS resource? Can a Lambda function read from an S3 bucket? Can an EC2 instance access DynamoDB? Can one AWS account access another account? Can a developer deploy resources but not delete production infrastructure? These questions are handled primarily through AWS Identity and Access Management (IAM).

AWS IAM: Understanding Identity, Roles, Policies, and Least-Privilege Security

AWS IAM: Understanding Identity, Roles, Policies, and Least-Privilege Security

When developers start working with AWS, they quickly encounter a common question:
Who is allowed to access this AWS resource?
Can a Lambda function read from an S3 bucket?
Can an EC2 instance access DynamoDB?
Can one AWS account access another account?
Can a developer deploy resources but not delete production infrastructure?
These questions are handled primarily through AWS Identity and Access Management (IAM).
IAM is one of the most fundamental services in AWS because it controls who can access AWS resources and what actions they are allowed to perform.
For developers, understanding IAM is not optional. Almost every production AWS architecture depends on correctly configured permissions.
This article explains IAM from a developer's perspective, starting with the basic concepts and moving toward production-ready security practices.

1. What is AWS IAM?

AWS Identity and Access Management (IAM) is an AWS service that lets you control access to AWS resources.
IAM answers two fundamental questions:

Who are you?

This is about identity and authentication.

What are you allowed to do?

This is about authorization.
For example:
1
2
3
4
5
6
7
8
9
Developer
↓
IAM Authentication
↓
AWS
↓
Authorization
↓
Can the developer access S3?
If the required permissions exist, the action is allowed.
If the permissions are missing or an explicit deny exists, the action is denied.

2. Authentication vs Authorization

These two concepts are often confused.

Authentication

Authentication answers:
Who are you?
Examples:
  • Username + password
  • MFA
  • IAM credentials
  • Federated identity
  • Temporary credentials

Authorization

Authorization answers:
What are you allowed to do?
For example:
1
2
3
4
5
6
7
8
9
User: Developer

Allowed:
✓ Read S3
✓ Deploy Lambda

Denied:
✗ Delete S3 buckets
✗ Modify IAM policies
So the basic flow is:
1
2
3
4
5
6
7
Authentication
↓
Who are you?
↓
Authorization
↓
What can you do?

3. Core IAM Components

The most important IAM concepts are:
  • Users
  • Groups
  • Roles
  • Policies
  • Permissions
Let's understand each one.

4. IAM Users

An IAM user represents a specific identity that can interact with AWS.
Historically, applications and developers often used long-lived access keys associated with IAM users.
For example:
1
2
3
4
5
IAM User
│
├── Console Access
│
└── Access Keys
However, creating individual IAM users for every application is generally not the preferred approach.
For human users, organizations increasingly use centralized identity and federation.
For AWS workloads, IAM roles are usually preferred over long-lived access keys.

5. IAM Groups

An IAM group is a collection of IAM users.
For example:
1
2
3
4
5
Developers
│
├── Himanshu
├── Developer A
└── Developer B
A policy can be attached to the group rather than individually configuring every user.
For example:
1
2
3
4
5
Developers Group
↓
Read S3
↓
All members inherit permission
Groups can simplify permission management when working with IAM users.

6. IAM Roles

IAM roles are one of the most important concepts for AWS developers.
A role provides permissions that can be assumed by a trusted principal.
For example:
1
2
3
4
5
6
7
Lambda Function
↓
Assume IAM Role
↓
Role Permissions
↓
Read S3
The Lambda function does not need to store an AWS access key inside the application.
This is a major security advantage.
Roles can be used by:
  • Lambda
  • EC2
  • ECS
  • EKS
  • SageMaker
  • Other AWS services
  • Federated users
  • Users from other AWS accounts

7. Why Roles Are Preferred for Applications

Consider two approaches.

Approach 1: Hardcoded Access Keys

1
2
3
4
5
6
7
Application
↓
Access Key
↓
Secret Key
↓
S3
This creates security risks.
If the credentials are accidentally committed to GitHub, someone could potentially use them.

Approach 2: IAM Role

1
2
3
4
5
6
7
Application
↓
IAM Role
↓
Temporary Credentials
↓
S3
The application does not need to manage long-lived credentials directly.
This is generally a much better architecture.

8. IAM Policies

Policies define permissions.
A policy is usually represented as JSON.
A simplified policy looks like:
1
2
3
4
5
6
7
8
9
10
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}
Let's understand the important fields.

9. Understanding Policy Structure

A policy typically contains:
1
2
3
4
5
6
7
Version
Statement
↓
Effect
Action
Resource
Condition

Effect

Defines whether an action is allowed or denied.
1
2
Allow
Deny

Action

Defines what operation is being performed.
For example:
1
2
3
s3:GetObject
s3:PutObject
s3:DeleteObject

Resource

Defines which AWS resource the permission applies to.
For example:
1
arn:aws:s3:::my-bucket/*

Condition

Allows permissions to be restricted based on specific conditions.
For example:
1
2
3
Only from a specific IP
Only using MFA
Only when certain request conditions are satisfied
Conditions are particularly useful for advanced security policies.

10. Resource-Based vs Identity-Based Policies

AWS permissions can be expressed through different policy mechanisms.
Two important categories are:

Identity-based policies

Attached to identities such as:
  • Users
  • Groups
  • Roles
Example:
1
2
3
4
5
IAM Role
↓
Policy
↓
Allow S3 Read

Resource-based policies

Attached directly to supported resources.
For example:
1
2
3
4
5
S3 Bucket
↓
Bucket Policy
↓
Allow Specific Principal
This can be useful when controlling access to resources such as S3 buckets or other AWS services that support resource-based policies.

11. Allow vs Deny

IAM policy evaluation can become confusing because multiple policies may apply.
A useful rule is:
An explicit deny overrides an allow.
Conceptually:
1
2
3
4
5
Allow
+
Allow
=
Allowed
But:
1
2
3
4
5
Allow
+
Explicit Deny
=
Denied
This is why security policies should be designed carefully.

12. Example: S3 Access

Suppose an application should only read objects from an S3 bucket.
We don't need to give it full S3 access.
Instead, we can grant:
1
s3:GetObject
for the required bucket path.
Conceptually:
1
2
3
4
5
6
7
Application
↓
IAM Role
↓
GetObject
↓
S3 Bucket
The application can read objects but cannot automatically:
1
2
3
4
Delete bucket
Create bucket
Modify IAM
Delete unrelated resources
This is the basic idea behind least privilege.

13. The Principle of Least Privilege

Least privilege means:
Give an identity only the permissions it actually needs.
Suppose a Lambda function only needs to read from S3.
Bad:
1
2
s3:*
Resource: *
Better:
1
2
3
s3:GetObject
Resource:
arn:aws:s3:::application-data/*
The second approach significantly reduces the potential impact of a compromised application.

14. Why * Can Be Dangerous

You may see policies such as:
1
2
3
4
5
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
This effectively gives extremely broad permissions.
It may be convenient during development, but it is dangerous for production workloads.
If the credentials or role are compromised, the attacker may gain access to many AWS resources.
A better approach is:
1
2
3
4
5
Required Service
↓
Required Action
↓
Required Resource
Instead of:
1
2
3
Everything
↓
Everyone

15. IAM Roles for Lambda

Lambda functions commonly use IAM execution roles.
For example:
1
2
3
4
5
6
7
Lambda
↓
Execution Role
↓
CloudWatch Logs
S3 Read
DynamoDB Write
Suppose our Lambda function processes uploaded files.
It may need:
1
2
3
4
5
s3:GetObject
s3:PutObject
logs:CreateLogGroup
logs:CreateLogStream
logs:PutLogEvents
But it probably doesn't need:
1
2
3
ec2:*
iam:*
rds:*
Keeping permissions focused improves security.

16. IAM Roles for EC2

EC2 applications can also use IAM roles.
For example:
1
2
3
4
5
EC2 Instance
↓
Instance Role
↓
S3 Access
The application can obtain temporary credentials through the AWS environment rather than storing static credentials in:
1
2
3
4
application.properties
.env
source code
Git repository
This is much safer than embedding access keys in an application.

17. IAM Roles for SageMaker

Machine learning workloads also require permissions.
For example:
1
2
3
4
5
SageMaker Training Job
↓
IAM Role
↓
S3
The role might allow SageMaker to:
  • Read training data
  • Write model artifacts
  • Access required AWS services
Again, the goal should be minimum necessary permissions.

18. Temporary Credentials and AWS STS

AWS Security Token Service (STS) enables temporary security credentials.
Instead of using permanent credentials:
1
2
Access Key
Secret Key
a workload can obtain temporary credentials.
Conceptually:
1
2
3
4
5
6
7
8
9
Principal
↓
Assume Role
↓
STS
↓
Temporary Credentials
↓
AWS Resource
Temporary credentials generally have an expiration time.
This reduces the risk associated with long-lived credentials.

19. Cross-Account Access

Large organizations often use multiple AWS accounts.
For example:
1
2
3
4
Development Account
Production Account
Security Account
Data Account
Sometimes a user or workload in one account needs to access resources in another.
IAM roles can be used for controlled cross-account access.
Conceptually:
1
2
3
4
5
6
7
Account A
↓
Assume Role
↓
Account B
↓
AWS Resource
This is safer than sharing credentials between accounts.

20. Multi-Factor Authentication

MFA adds another security layer.
Instead of relying only on:
1
Password
the user also provides another authentication factor.
Conceptually:
1
2
3
4
5
Password
+
MFA
↓
Authenticated User
MFA is especially important for privileged identities.
For highly sensitive environments, organizations should also consider stronger centralized identity and access-management strategies rather than relying solely on individual IAM users.

21. Root User Security

Every AWS account has a root user.
The root user has extremely powerful permissions and should not be used for everyday AWS operations.
A secure account setup should include:
1
2
3
4
5
6
7
Root User
↓
Secure Credentials
↓
MFA
↓
Limited Usage
Daily development and administration should be performed through appropriately controlled identities.

22. IAM Access Analyzer

As AWS environments become larger, manually reviewing every permission becomes difficult.
IAM Access Analyzer can help identify access configurations and potential unintended access.
For example, it can help answer questions such as:
1
Who can access this resource?
or identify resource policies that allow access outside the intended boundary.
This is particularly useful when reviewing production environments.

23. IAM Policy Simulator

When debugging permissions, developers often face an issue like:
1
AccessDenied
The first instinct may be to give the role more permissions.
That is not always the correct solution.
Instead, investigate:
1
2
3
4
5
6
Which identity?
Which action?
Which resource?
Which policy?
Which condition?
Is there an explicit deny?
Policy simulation tools can help test whether a policy allows or denies specific actions.
This is a much better approach than blindly adding AdministratorAccess.

24. IAM and S3 Security

Consider a web application that allows users to upload documents.
A secure architecture could be:
1
2
3
4
5
Frontend
↓
Backend
↓
S3
The backend might use an IAM role with permission to:
1
2
s3:PutObject
s3:GetObject
for a specific bucket and prefix.
It does not necessarily need:
1
2
s3:DeleteBucket
s3:ListAllMyBuckets
This limits the application's capabilities.

25. IAM and DynamoDB

Suppose a Lambda function needs to store user activity.
Instead of:
1
dynamodb:*
the role could be restricted to operations such as:
1
2
3
dynamodb:GetItem
dynamodb:PutItem
dynamodb:UpdateItem
and ideally restricted to the specific table.
Architecture:
1
2
3
4
5
6
7
Lambda
↓
IAM Role
↓
Specific DynamoDB Actions
↓
Specific Table

26. IAM and API Gateway

API Gateway can work with several authentication and authorization mechanisms.
Depending on the application, authorization can involve:
  • IAM
  • Amazon Cognito
  • Lambda authorizers
  • Other application-level authorization mechanisms
The important distinction is that authentication and application authorization are separate design concerns.
For example:
1
2
3
4
5
6
7
8
9
User
↓
Authentication
↓
API
↓
Authorization
↓
Business Operation

27. IAM vs Amazon Cognito

Developers often confuse IAM with Cognito.
They solve different problems.

IAM

Primarily controls access to AWS resources and APIs.
1
2
3
Developer
↓
AWS Resource

Cognito

Provides capabilities for application user identity and authentication.
1
2
3
4
5
Application User
↓
Login
↓
Application
A web application might use Cognito for customer authentication while using IAM roles to control what AWS resources the backend can access.
They can therefore work together.

28. Developer vs Production Permissions

A common mistake is giving developers the same permissions in every environment.
Consider:
1
2
3
4
5
6
7
Development
↓
More flexibility

Production
↓
More restrictions
A developer might need permission to create resources in a development account.
Production access should generally be more controlled.
A mature organization may separate:
1
2
3
4
5
Developer Account
↓
Staging Account
↓
Production Account
and implement controlled access between them.

29. IAM for CI/CD Pipelines

CI/CD systems also need AWS permissions.
For example:
1
2
3
4
5
6
7
GitHub Actions
↓
AWS Authentication
↓
IAM Role
↓
Deployment
The pipeline may need permission to:
1
2
3
Deploy Lambda
Upload S3 artifacts
Update infrastructure
But it should not automatically receive unrestricted administrator permissions.
A better architecture is:
1
2
3
4
5
CI/CD
↓
Dedicated Deployment Role
↓
Only Required Permissions
This reduces the impact of a compromised pipeline.

30. Avoid Long-Lived Access Keys

One of the most important security practices is to avoid unnecessary long-lived credentials.
Avoid:
1
2
AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...
hardcoded inside:
1
2
3
4
Source Code
GitHub Repository
Docker Image
Frontend Code
Instead, use appropriate credential mechanisms such as:
  • IAM roles
  • Temporary credentials
  • AWS-managed identity mechanisms
  • Federated authentication
  • OIDC-based CI/CD authentication where appropriate
The exact approach depends on where the application runs.

31. Never Put AWS Credentials in Frontend Code

This is particularly important for web developers.
A frontend application runs in the user's browser.
Anything shipped to the browser should be treated as potentially visible to the user.
Therefore, never put AWS secret credentials directly into:
1
2
3
4
5
React
Angular
Vue
HTML
JavaScript
Instead:
1
2
3
4
5
6
7
Frontend
↓
Backend API
↓
IAM Role
↓
AWS Service
This keeps privileged credentials away from the client.

32. IAM Policy Design Strategy

When designing permissions, ask four questions:

1. Who?

1
2
3
4
User
Role
Service
External Identity

2. What action?

1
2
3
4
5
Get
Put
Update
Delete
Invoke

3. Which resource?

1
2
3
Specific Bucket
Specific Table
Specific Function

4. Under what conditions?

1
2
3
4
5
MFA
IP
Region
Tags
Request properties
Then construct the smallest permission set that satisfies the requirement.

33. A Practical Permission Design Example

Suppose a Lambda function generates reports and uploads them to S3.
Requirements:
1
2
3
Lambda needs:
- Read source files
- Write generated reports
Instead of:
1
s3:*
design permissions around the actual workflow:
1
2
3
4
5
6
7
Input Bucket
↓
s3:GetObject

Output Bucket
↓
s3:PutObject
Architecture:
1
2
3
4
5
6
Lambda
│
┌────────┴────────┐
↓ ↓
Input Bucket Output Bucket
GetObject PutObject
This is a much clearer security boundary.

34. IAM Tags and Attribute-Based Access

As organizations grow, managing individual resources can become difficult.
Tags can help organize resources and support more scalable permission strategies.
For example:
1
2
3
Environment = Production
Team = Payments
Project = Billing
Permissions can then be designed around resource attributes and organizational requirements.
This can be particularly useful in large AWS environments.

35. Common IAM Mistakes

Mistake 1: Using AdministratorAccess everywhere

It solves permission errors but creates unnecessary risk.

Mistake 2: Using Action: "*"

This provides much broader access than most applications require.

Mistake 3: Using Resource: "*" unnecessarily

Some permissions require broad resource scope, but where resource-level permissions are supported, scope them appropriately.

Mistake 4: Hardcoding access keys

Credentials should not be stored in source code.

Mistake 5: Sharing credentials

Each identity should have controlled access rather than sharing a common credential.

Mistake 6: Ignoring explicit denies

When debugging IAM, remember that an explicit deny can override an allow.

Mistake 7: Giving production the same permissions as development

Production environments generally need stronger controls.

Mistake 8: Forgetting unused permissions

Permissions should be reviewed periodically and reduced when they are no longer required.

36. A Production-Ready AWS Security Architecture

A mature AWS environment might look like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Organization
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Development Staging Production
│ │ │
↓ ↓ ↓
IAM Roles IAM Roles IAM Roles
│ │ │
└──────────────┼──────────────┘
↓
AWS Resources
│
┌────────┴────────┐
↓ ↓
Logging Monitoring
│ │
└────────┬────────┘
↓
Security Review
The exact architecture varies by organization, but the principle remains the same:
identity should be controlled, permissions should be limited, and access should be continuously reviewed.

37. A Developer's IAM Checklist

Before deploying an AWS application, ask:

Identity

  • Am I using roles where appropriate?
  • Are privileged accounts protected with MFA?
  • Are unnecessary IAM users removed?

Permissions

  • Does every role have only the required permissions?
  • Can * permissions be reduced?
  • Are resources scoped where possible?

Credentials

  • Are there any access keys in source code?
  • Are secrets stored securely?
  • Are temporary credentials being used where appropriate?

Production

  • Is production access restricted?
  • Are deployment permissions separated?
  • Are cross-account roles controlled?

Monitoring

  • Are AWS activities being logged?
  • Are suspicious activities reviewed?
  • Are IAM configurations periodically audited?

38. IAM and the AWS Services You Already Use

IAM becomes much easier to understand when you see how it connects with other AWS services.
For example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Lambda
↓
IAM Role
↓
S3 / DynamoDB

EC2
↓
IAM Role
↓
S3 / CloudWatch

SageMaker
↓
IAM Role
↓
S3 / Model Resources

CI/CD
↓
IAM Role
↓
AWS Deployment

Backend
↓
IAM Role
↓
AWS APIs
This means IAM is not an isolated AWS service.
It is a security layer across the entire AWS architecture.

39. The Bigger Picture

When learning AWS, developers often focus on services:
1
2
3
4
5
6
7
S3
Lambda
EC2
DynamoDB
SageMaker
Bedrock
CloudWatch
But every service needs to answer another question:
Who is allowed to use it?
That's where IAM becomes fundamental.
A strong AWS developer should therefore understand both:
1
2
3
AWS Services
+
AWS Security
rather than treating security as something added at the end.

Conclusion

AWS IAM is the foundation of access control in AWS.
The most important concepts to understand are:
1
2
3
4
5
6
7
Users
Groups
Roles
Policies
Permissions
Temporary Credentials
Least Privilege
A secure AWS architecture should follow a simple principle:
Give every identity exactly the access it needs—and nothing more.
Instead of building applications around permanent credentials and broad permissions, modern AWS architectures should favor:
1
2
3
4
5
6
7
8
9
IAM Roles
↓
Temporary Credentials
↓
Least-Privilege Policies
↓
Specific Resources
↓
Continuous Monitoring
Whether you are building a MERN application, Spring Boot backend, serverless API, CI/CD pipeline, machine learning platform, or Generative AI application, IAM will be part of the architecture.
Understanding IAM therefore doesn't just help you pass an AWS certification question.
It helps you build applications that are secure by design.
# aws-academy# aws-ai-chips# aws-ai-league# aws-ambassador# aws-amplify
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article