AWS Identity and Access Management IAM: Users, Roles, Policies, and Security Basics

AWS Identity and Access Management IAM is the control plane for AWS access: who can sign in, what they can do, which resources they can touch, and under what conditions. If you build on AWS, you will deal with IAM before your first production deploy, and you will keep dealing with it after every audit, incident review, and architecture change.

The short version: use users sparingly, use groups for human permission management, use roles for workloads and cross-account access, and write policies that grant only what is needed. Sounds simple. It is not always simple in practice.

What is AWS Identity and Access Management IAM?

AWS describes IAM as a web service for securely controlling access to AWS resources. It handles two closely related jobs:

• Authentication: proving who the requester is, such as a human user, application, AWS service, or federated identity.
• Authorization: deciding whether that authenticated identity can perform an action on a specific resource.

IAM is included with every AWS account at no additional charge, along with AWS Security Token Service, commonly called STS. IAM Identity Center is also part of the AWS identity stack and is used for centralized workforce access across AWS accounts and applications.

One point trips up new cloud engineers: IAM is not only about logging into the AWS Management Console. It affects API calls from EC2, Lambda, ECS tasks, CI/CD runners, third-party tools, security scanners, and almost every service integration you will build.

IAM users, groups, and roles explained

IAM users

An IAM user is a long-term identity in an AWS account. A user can have a console password, access keys for programmatic access, or both.

Use IAM users carefully. For human access, many organizations now prefer IAM Identity Center with federation to an identity provider such as Microsoft Entra ID, Okta, or Google Workspace. Still, you will see IAM users in older accounts, automation scripts, break-glass procedures, and small lab environments.

Never use the root user for daily work. The root user has full account power, including actions that IAM administrators cannot always perform. Secure it with MFA, store the credentials offline, and use it only for account-level tasks.

IAM groups

An IAM group is a collection of IAM users. Attach a policy to the group, and every user in that group receives those permissions.

Groups are useful for human access patterns such as:

• Developers who need access to development resources
• Operations staff who need read and limited write permissions
• Auditors who need read-only visibility
• Security engineers who manage IAM, CloudTrail, GuardDuty, and related services

Do not attach dozens of one-off policies directly to individual users. That becomes impossible to review. Put users into groups and manage access there.

IAM roles

An IAM role is an identity with permissions, but it is not permanently tied to one person. A trusted principal assumes the role, and AWS STS issues temporary credentials.

This is the preferred pattern for workloads. An EC2 instance should use an instance profile role to read from S3. A Lambda function should use an execution role. A CI/CD pipeline should assume a deployment role. Do not bake access keys into AMIs, Docker images, GitHub repositories, or shell scripts. To be blunt, static AWS keys in code are still one of the most avoidable cloud security mistakes.

A common real-world error looks like this:

An error occurred (AccessDenied) when calling the PutObject operation: User: arn:aws:sts::123456789012:assumed-role/app-prod-role/i-0abc123 is not authorized to perform: s3:PutObject on resource: arn:aws:s3:::example-prod-bucket/logs/app.log because no identity-based policy allows the s3:PutObject action.

That message tells you two useful things. The caller is an assumed role, not a static user. And AWS found no applicable allow statement for the requested action and resource.

IAM policies: how permissions actually work

An IAM policy is a JSON document that defines permissions. It specifies actions, resources, effects, and optional conditions.

A minimal identity-based policy might allow a role to list one bucket and read objects from it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::example-reports-bucket"
    },
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-reports-bucket/*"
    }
  ]
}

Notice the two resource ARNs. s3:ListBucket applies to the bucket ARN. s3:GetObject applies to object ARNs under the bucket. Mixing those up is a small mistake that wastes a surprising amount of debugging time.

Identity-based policies

Identity-based policies attach to users, groups, or roles. They answer one question: what can this identity do?

Examples include allowing a developer role to read CloudWatch logs, allowing a deployment role to update ECS services, or allowing an auditor group to view AWS Config resources.

Resource-based policies

Resource-based policies attach directly to resources. S3 bucket policies, KMS key policies, SQS queue policies, and Lambda function resource policies are common examples.

They answer a slightly different question: who can access this resource?

This matters for cross-account access. If Account A needs to read an S3 bucket in Account B, you often need permissions on both sides: an identity policy in Account A and a resource policy in Account B. KMS adds another wrinkle, because the key policy must also allow the action if encrypted objects are involved.

Managed and inline policies

AWS supports several policy attachment models:

• AWS managed policies: maintained by AWS, such as AdministratorAccess and ReadOnlyAccess.
• Customer managed policies: created and maintained by your team, reusable across identities.
• Inline policies: embedded directly into one user, group, or role.

Use customer managed policies for most production patterns. Use AWS managed policies for learning, temporary access, or well-understood baseline roles. Avoid inline policies unless the permission is truly unique and must live with that identity.

How AWS evaluates IAM permissions

AWS starts with a default deny. A request is allowed only when an applicable policy allows it and no applicable policy explicitly denies it.

The practical rules are:

1. Default is deny. No matching allow means the request fails.
2. Explicit deny wins. A deny in any applicable policy overrides an allow.
3. Conditions matter. A policy can allow access only from a specific VPC endpoint, IP range, region, MFA state, tag, or principal attribute.
4. Multiple policy types can apply. IAM policies, resource policies, permissions boundaries, session policies, and AWS Organizations service control policies can all affect the final decision.

When candidates study AWS IAM for certification exams, they often miss the explicit deny rule or forget that service control policies do not grant access by themselves. SCPs set the maximum allowed permissions for accounts in an organization. They cap what is possible; they never hand out access.

AWS IAM security basics you should apply first

Use least privilege from the start

The principle of least privilege is not a slogan. It is how you reduce blast radius. Grant the minimum actions and resources required for a task, then expand only when there is evidence that more access is needed.

A bad early shortcut is attaching AdministratorAccess to a workload role because deployment is failing. Fix the missing permission instead. Use CloudTrail event history, IAM Access Analyzer policy generation, and service documentation to narrow the action set.

Enable MFA for privileged access

Use multi-factor authentication for root and privileged IAM users. If you still maintain IAM users for console access, enforce a strong password policy and require MFA for administrators.

For sensitive operations, you can also add policy conditions that require MFA. This is useful for actions such as deleting production backups or changing IAM permissions.

Prefer roles over access keys

Applications should assume roles and receive temporary STS credentials. Temporary credentials expire, which limits damage if they leak. Static access keys do not expire unless you rotate or delete them.

If you must use access keys, rotate them, monitor last-used timestamps, and alert on suspicious API calls through CloudTrail and security tooling.

Separate accounts for real isolation

Use multiple AWS accounts as security boundaries. Keep production separate from development and testing. Put logging and security tooling in dedicated accounts where possible.

AWS Organizations helps enforce guardrails with service control policies. For example, you can restrict regions, block disabling CloudTrail, or prevent public S3 bucket changes across member accounts. Pair this with IAM roles for controlled cross-account administration.

Validate policies before deployment

Use IAM Access Analyzer to identify resources shared outside your account or organization. Use the IAM Policy Simulator to test whether a policy allows or denies specific requests.

Do this before production rollout. A policy that looks correct in a pull request can still fail because of a missing resource ARN, a condition key mismatch, or an explicit deny from an organization-level control.

Common IAM mistakes to avoid

• Using the root user for normal administration. Create named identities and protect root with MFA.
• Sharing IAM users. Shared users break accountability and make audits painful.
• Putting access keys in code. Use roles for AWS services and OIDC-based federation for modern CI/CD platforms where supported.
• Granting wildcard permissions everywhere. s3:* on * is rarely acceptable in production.
• Ignoring resource policies. Identity access is only part of the picture for S3, KMS, Lambda, SQS, and similar services.
• Skipping reviews. Permissions that were correct six months ago may be excessive today.

How to build IAM skills for real AWS work

If you are learning AWS Identity and Access Management IAM for cloud engineering, security operations, or certification prep, do not stop at definitions. Build a small lab.

1. Create a read-only group and attach ReadOnlyAccess.
2. Create a role for an EC2 instance that can read one S3 bucket.
3. Add a bucket policy that allows access only from that role.
4. Test allowed and denied calls with the AWS CLI.
5. Run IAM Access Analyzer and inspect the findings.
6. Use the IAM Policy Simulator to verify one allowed action and one denied action.

For a structured path, pair hands-on AWS practice with related Global Tech Council learning in cloud computing, cybersecurity, DevOps, and cloud security. These topics connect directly to IAM design, especially when you move into multi-account governance, incident response, and secure automation.

Your next step: take one non-production AWS account, remove unused IAM users and keys, move one application to an IAM role, and test the policy with Access Analyzer. That small exercise teaches more than another hour of reading policy examples.