How Does AWS Control Who Can Access What? Understanding IAM Policies, Roles & Least Privilege

When I started learning AWS, I realized something important: creating cloud resources is only part of the job. We also need to control who can access those resources, what they can do, and which AWS services can communicate with each other.

Imagine deploying a MERN application on AWS. Your backend needs to read files from S3, retrieve database credentials, and write application logs. Should we give it full access to our AWS account?

Definitely not.

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

In this article, I'll explore IAM users, groups, roles, policies, trust policies, permission boundaries, and the principle of least privilege using practical examples.

Figure: Understanding AWS IAM through identities, permissions, and a real-world application example.

1. What Is AWS IAM?

AWS IAM is a service that helps control access to AWS resources.

It answers three fundamental questions:

• Who is making the request?
• What actions are they allowed to perform?
• Which resources can they access?

For example, a developer might be allowed to view EC2 instances but not delete production databases. Meanwhile, an application running on Amazon ECS might need permission to read a specific file from S3.

IAM lets us define these permissions instead of granting everyone unrestricted access.

2. Understanding the Main IAM Components

IAM users

An IAM user represents an identity with long-term credentials, when those credentials are configured.

For example, a developer may have an IAM user that can access specific development resources.

However, for people, AWS recommends federation and temporary credentials where practical rather than creating long-term IAM user credentials for everyday access.

Important: Avoid using the AWS root user for routine tasks. Protect it carefully and use it only when root-level access is specifically required.

IAM groups

An IAM group allows you to manage permissions for multiple IAM users together.

For example:

• Developers — access to development resources
• Auditors — read-only access for reviewing resources
• Administrators — broader administrative permissions

Groups simplify permission management, but they are not a replacement for carefully designed policies.

IAM roles

An IAM role is an identity that provides a set of permissions and can be assumed by an authorized principal.

Roles are especially useful when AWS services need to communicate securely.

Imagine an application running on Amazon EC2 that needs to read a file from S3.

Instead of placing AWS access keys inside the application code, we can attach an appropriate IAM role to the EC2 instance. The application can then obtain temporary credentials through the AWS-provided credential mechanism.

This reduces the need to store long-term credentials in the application.

IAM roles are also used with ECS tasks, Lambda functions, and many other AWS services.

IAM policies

An IAM policy is a document that defines permissions.

A policy can specify:

• Effect: Allow or Deny
• Action: The operation being requested
• Resource: The AWS resource involved
• Condition: Optional requirements that must be satisfied

For example, an application might need permission to download objects from one S3 bucket without being allowed to delete them.

A simplified policy could look like this:

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

This allows the specified GetObject operation on objects in the named bucket. It does not, by itself, grant permission to upload or delete objects.

Replace the example bucket name with your actual resource when implementing a policy.

3. Identity-Based vs. Resource-Based Policies

AWS supports different ways of defining access.

Identity-based policies attach to identities such as users, groups, and roles. They describe what those identities can do.

Resource-based policies attach to supported resources and describe which principals can access them.

For example, an IAM role may have permission to read objects from an S3 bucket, while the bucket policy may also restrict which principals are allowed to access that bucket.

Both sides can matter. An Allow in one policy does not automatically override an applicable explicit Deny or other access restrictions.

4. What Is a Trust Policy?

This is one of the most important distinctions when learning IAM roles.

An IAM role has two separate questions to answer:

1. Trust policy: Who is allowed to assume this role?
2. Permissions policy: What can the role do after it is assumed?

Imagine an ECS task that needs to access an S3 bucket.

The task role's trust policy establishes that the appropriate ECS tasks can assume the role. Its permissions policy grants only the required S3 actions.

These policies solve different problems. Allowing a service to assume a role does not automatically give that role permission to access S3.

5. How IAM Works in a Real Application

Let's use a simplified architecture for a web application deployed on AWS.

                Developer
                    |
                    v
              AWS Console / CLI
                    |
                    v
               IAM Identity
                    |
            IAM Policies
                    |
                    v
             AWS Resources


          Application Running on ECS
                    |
                    v
               ECS Task Role
                    |
            Permissions Policy
                    |
          +---------+----------+
          |                    |
          v                    v
      Amazon S3        AWS Secrets Manager

The developer accesses AWS using an authorized identity. The application accesses other AWS services through its task role.

These are separate identities with separate permissions.

For example:

• A developer can deploy a new application version.
• An ECS task can read specific S3 objects.
• The task can retrieve a particular secret if its role is authorized to do so.
• Neither identity automatically needs full administrator access.

This is the basic idea behind secure access control in cloud applications.

6. What Is the Principle of Least Privilege?

The principle of least privilege means granting only the permissions necessary to perform a task.

Suppose your application needs to read files from S3.

A poor approach would be to grant s3:* on every bucket in the account.

A better approach would be to grant only the necessary S3 actions on the specific bucket or objects the application needs.

Least privilege is not simply about writing smaller policies. It also means reviewing permissions regularly, removing unused access, and considering what could happen if an identity were compromised.

7. What Are Permission Boundaries?

Permission boundaries help set the maximum permissions that an IAM user or role can receive through identity-based policies.

Think of them as a permissions ceiling.

For example, an organization might allow a development team to create roles for its applications but require that those roles remain within a defined permissions boundary.

A boundary does not grant permissions by itself. The identity still needs applicable policies that allow the requested actions.

Also, a permissions boundary is not a universal restriction on every possible access path. Resource-based policies and other AWS authorization rules must be considered when evaluating effective access.

8. IAM Roles vs. Hardcoded Credentials

Consider two approaches for an application that accesses AWS services.

Approach A: Hardcoded credentials

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

This is unsafe. Credentials can accidentally enter Git repositories, logs, build artifacts, or shared files.

Approach B: IAM role and temporary credentials

Configure the application's execution environment with the appropriate IAM role. Use the AWS SDK's default credential provider chain to obtain credentials.

For example, with AWS SDK for JavaScript v3:

import { S3Client, ListObjectsV2Command } from "@aws-sdk/client-s3";

const s3 = new S3Client({
  region: "ap-south-1"
});

const response = await s3.send(
  new ListObjectsV2Command({
    Bucket: "my-app-documents"
  })
);

console.log(response.Contents);

The SDK can obtain credentials from the supported runtime credential provider chain, including the role credentials provided in an appropriately configured AWS environment.

The example still requires permission for s3:ListBucket on the bucket. If the application only needs to download a known object, grant s3:GetObject on that object instead.

Remember: Using an IAM role does not automatically make an application secure. The role must have the right trust relationship and narrowly scoped permissions.

9. IAM and AWS Secrets Manager

IAM and Secrets Manager work together, but they have different responsibilities.

• IAM controls whether an identity can perform an action.
• AWS Secrets Manager stores and manages sensitive values such as database credentials and API keys.

For example, an ECS task can use its task role to retrieve a particular database secret from Secrets Manager. The task role should not be allowed to retrieve every secret in the account unless that broader access is genuinely required.

Avoid embedding secrets in source code, Docker images, or GitHub repositories.

10. Common IAM Mistakes to Avoid

Here are a few mistakes worth watching for when building AWS projects:

1. Using the root user for everyday development.
2. Giving applications administrator permissions.
3. Hardcoding AWS access keys into source code.
4. Confusing a role's trust policy with its permissions policy.
5. Assuming a permissions boundary grants access.
6. Forgetting that an explicit Deny can override an Allow.
7. Granting access to every resource when only one resource is required.
8. Leaving unused users, access keys, or permissions in place.

IAM policies should be tested and reviewed carefully, particularly before making changes in production.

11. What Should You Remember for the AWS SAA-C03 Exam?

These are useful distinctions to remember:

• IAM user: An identity that can have long-term credentials.
• IAM group: Organizes IAM users for permission management.
• IAM role: An assumable identity commonly used for temporary credentials.
• IAM policy: Defines permissions.
• Trust policy: Defines who can assume a role.
• Permissions boundary: Sets a maximum permission boundary for an IAM identity.
• Least privilege: Grants only the access needed.
• Explicit Deny: Overrides an applicable Allow.
• Instance profile: A mechanism used to pass an IAM role to an EC2 instance.
• ECS task role: Grants permissions to application code running in an ECS task.
• ECS task execution role: Grants permissions needed by the ECS agent to perform tasks such as pulling images and sending logs, depending on configuration.

That last distinction matters: the task role is for the application; the execution role is for ECS task startup and management operations.

Final Thoughts

Learning IAM changed how I think about deploying applications on AWS. It is not enough for an application to work — it must also have the right permissions and nothing more than it needs.

Whether you're deploying a Lambda function, running containers on ECS, or building a larger cloud architecture, IAM is one of the foundations of secure AWS development.

My biggest takeaway is simple: don't ask only whether an application can access a resource. Ask whether it should have that access, and whether the permission can be made more specific.

That's the mindset behind least privilege.

I'm continuing my AWS learning journey and documenting the concepts that help me understand how real cloud systems are built and secured.