2 AWS Identity and Access Management

IAM access management

AWS Identity and Access Management (IAM) controls who can access AWS and what they can do. It provides authentication, which verifies an identity, and authorization, which decides whether a request is permitted. Customers are responsible for configuring identities, credentials, and permissions appropriately; AWS provides IAM and enforces the resulting access decisions.

The account root user has extensive access. Protect it and avoid using it for routine work.

IAM identities

IAM users are identities in one AWS account with credentials and permissions. They may represent people or workloads. AWS recommends using them only when a use case cannot use federation and temporary credentials.

IAM groups collect IAM users so shared permissions can be managed together. Groups are not principals and cannot be assumed as roles.

IAM roles are identities with permissions that a trusted principal can assume. They are commonly used by people, AWS services, applications, and users accessing another account.

Federated identities are managed by an external identity provider (IdP), such as a corporate identity system. They access AWS by obtaining temporary credentials through a role, avoiding the need for a separate long-term IAM user for each person. AWS IAM Identity Center is a common way to manage workforce access across AWS accounts.

Policies and permissions

A policy is a JSON document that describes permissions. Identity-based policies attach to users, groups, or roles. Resource-based policies attach to supported resources, such as an S3 bucket.

A policy statement commonly specifies:

• Effect: Allow or Deny.

• Action: the API operations covered.

• Resource: the resources covered.

• Condition (optional): circumstances required for the statement to apply.

This identity-based policy allows listing one bucket and reading its objects. It does not allow writing or deleting them.

How AWS evaluates access

AWS denies requests by default unless an applicable policy allows them. An explicit Deny overrides an Allow. Effective access can also be limited by controls such as permissions boundaries and AWS Organizations service control policies (SCPs).

A permissions boundary sets the maximum permissions an identity-based policy can grant. It does not grant permissions by itself.

Role trust and permissions

A role has two distinct policy concerns:

1. Its trust policy specifies which principals may assume the role, and under what conditions.

2. Its permissions policies specify what an assumed role session can do.

Both must be configured correctly: the principal must be trusted to assume the role, and the resulting session must have permission for the requested action.

Temporary credentials and federation

Roles support temporary access for workloads, cross-account use, and federated users. For example, an application running on an AWS compute service can use a role attached to that service to access a specific S3 bucket. The application receives temporary credentials instead of storing long-term access keys in its code.

A federated employee can sign in through an identity provider and assume a role associated with their job duties.

Least privilege in practice

Least privilege means granting only the permissions needed for a task, on only the required resources, for only as long as needed. Start with narrow permissions and expand them when justified.

Practical access-management patterns include:

• Use IAM Identity Center or another trusted identity provider for workforce access; prefer temporary role sessions over long-term user credentials.

• Give workloads roles rather than embedding access keys in application code, configuration files, or repositories.

• Organize permissions by job function, using groups or centrally managed permission sets where appropriate.

• Scope policies to specific actions and resource ARNs. Avoid broad wildcards such as "Action": "*" or "Resource": "*" unless there is a deliberate, reviewed need.

• Use separate roles for different tasks or environments, and require appropriate conditions for sensitive access.

• Review permissions regularly, remove unused access, and audit credential use and policy changes.

For example, a reporting analyst may need read access to a particular reports bucket, while a deployment role may need permission to update a defined set of application resources. Separate, narrowly scoped access makes mistakes and compromised credentials less damaging.