AWS Identity and Access Management

AWS Identity and Access Management, or IAM, controls access to AWS resources. It answers two separate questions. Authentication establishes who or what is making a request. Authorization decides whether that principal may perform the requested action.

IAM matters because almost every AWS operation is an API request. A console click, command-line call, software development kit call, and service-to-service operation eventually asks an AWS service to do something. IAM supplies identities and policies that help AWS decide whether to accept that request.

Use one request model throughout this course:

A principal uses credentials to send a request.
The request names an action and usually a resource.
AWS builds a request context with details such as the principal, time, network path, tags, and requested Region.
AWS finds every policy that applies to that context.
AWS authorization logic returns allow or deny.

The model is compact. The policy combinations are not. A safe IAM design makes each layer's job explicit.

Identities and credentials

An AWS account begins with a root user. The root user has complete access to the account and can perform account-level tasks that other identities cannot. It is not an everyday administrator. Protect its sign-in and recovery paths, register multi-factor authentication, avoid root access keys, and use it only for tasks that require it.

An IAM user is an identity in one AWS account. It can have long-term credentials, including a console password or access keys. That persistence creates rotation, storage, removal, and exposure concerns. AWS recommends federation and temporary credentials for human users. IAM users remain appropriate for limited cases that cannot use federation or roles, including carefully controlled emergency access.

An IAM group collects IAM users so you can attach identity-based policies to the group. A group is not a principal. You cannot sign in as a group or name one as the principal in a resource-based policy.

An IAM role is an assumable identity with permission policies. It has no standard long-term password or access keys. A person, workload, AWS service, or principal in another account assumes the role and receives temporary credentials for a role session.

Temporary credentials come from AWS Security Token Service. They expire after a configured session period. They support roles, federation, delegation, and cross-account access. Expiration reduces the useful lifetime of exposed credentials, but it does not correct excessive permissions during an active session.

Workforce and workload access

Treat workforce identity and workload identity as separate designs.

For workforce access, IAM Identity Center connects or stores workforce users and groups. An organization instance can assign permission sets across multiple AWS accounts. Users authenticate through the selected identity source and receive account access through temporary role sessions. This centralizes assignment and avoids creating a separate IAM user for each person in each account.

For workloads running on AWS compute services, attach an IAM role through the service's supported mechanism. The platform delivers temporary role credentials to the workload. AWS software development kits can discover those credentials without an access key embedded in source code, an image, or a configuration file.

External workloads can use federation when the platform supports an identity standard and AWS trust configuration. Long-term IAM user access keys are the fallback, not the starting point.

Policies describe access

Most IAM policies are JSON documents. A policy statement commonly describes:

Effect: allow or deny.
Action: the AWS API operations covered by the statement.
Resource: the resources covered by the statement.
Condition: optional tests against the request context.
Principal: the identity trusted by a resource-based policy. Identity-based policies do not include this element.

The service authorization reference lists each service's actions, supported resource types, and condition keys. Check it while writing a policy. An action that does not support resource-level permissions may require a wildcard resource even when related actions accept specific Amazon Resource Names.

Prefer customer managed policies when several identities need the same controlled permission set. Use inline policies when the strict one-to-one relationship is intentional. AWS managed policies are useful to start, but AWS recommends moving toward permissions tailored to the workload or job.

Policy types have different jobs

An identity-based policy attaches to an IAM user, group, or role. It describes what that identity may do.

A resource-based policy attaches to a resource. It names the principal that may access the resource. S3 bucket policies and role trust policies are common examples.

A role therefore has two distinct policy surfaces. Its trust policy controls who may assume it. Its permissions policies control what an assumed role session may do. Granting one does not replace the other.

A permissions boundary sets the maximum permissions that identity-based policies can grant to an IAM user or role. It does not grant permissions. Use it when you delegate identity administration but need to cap the permissions that delegated administrators can assign.

A session policy narrows permissions for one temporary session. It does not grant permissions beyond the role or federated identity.

A service control policy, or SCP, sets organization-level permission guardrails for principals in member accounts. It does not grant permissions. An account administrator cannot escape an applicable SCP by attaching an administrator policy.

Other policy types can also affect a decision, including resource control policies and VPC endpoint policies. Always identify every policy layer before explaining an unexpected allow or deny.

How AWS evaluates a request

Start with three rules:

A request is implicitly denied unless the applicable policy evaluation produces an allow.
An applicable explicit deny overrides an allow.
Guardrails such as permissions boundaries, session policies, and SCPs limit permissions; they do not create permissions.

For a common same-account request, identity-based and resource-based policies can contribute permissions. Boundaries and organization policies can restrict the result. The exact behavior depends on the principal named by a resource-based policy. A role ARN and an assumed-role session ARN do not always behave the same way.

Do not reduce IAM evaluation to “identity policy plus resource policy.” That shortcut fails around cross-account access, role trust, session principals, boundaries, and organization policies. Use the AWS policy evaluation documentation when the principal or policy combination changes.

For cross-account role access, both sides participate. The role's trust policy must trust the external principal, and the external principal must have permission to call the role-assumption action. The resulting role session then operates under the role's permissions and every applicable limiting policy.

Least privilege is a process

Least privilege means granting only the permissions required for the task. You rarely know the final policy before observing the workload.

Use a controlled refinement loop:

Define the job, resource scope, and required session duration.
Start with the narrowest policy supported by current evidence.
Validate policy syntax and security findings before deployment.
Test successful and denied paths in a safe environment.
Observe API activity through CloudTrail and service-specific logs.
Review last-accessed data and Access Analyzer findings.
Remove unused actions, resources, identities, and credentials.

Conditions can narrow access by request context. Common designs restrict source networks, require multi-factor authentication, bind access to resource tags, or limit which Regions may receive requests. A condition only helps when the target action and context key support the intended evaluation.

Analyze and audit

IAM Access Analyzer supports several related jobs. It can identify public or cross-account access, analyze internal access to selected resources, identify unused access, validate policies, run custom policy checks, and generate policy templates from CloudTrail activity.

Generated policies are starting points. Access Analyzer policy generation has documented coverage limits. For example, it does not derive action-level permissions from CloudTrail data events, and the role-passing action is not tracked for policy generation. Review the generated policy against the workload's complete behavior.

CloudTrail records actions taken by users, roles, and AWS services as events. Use it to determine who or what made a request, which action occurred, which resource was involved, and when it happened. Event history provides recent management events, while trails and event data stores support longer retention and broader analysis.

IAM authorization explains whether a request should be allowed. CloudTrail provides evidence about requests that occurred. You need both for sound operations.

Limits and judgement

IAM controls AWS API authorization. It does not replace application authorization inside your software. A role allowed to read a database still needs an application design that limits which records an end user may see.

IAM also does not make a resource private by itself. Services can have resource policies, access control lists, public-access controls, network paths, encryption policies, and organization policies. Review the complete service authorization model.

Policy changes can take time to propagate because IAM is eventually consistent. Keep identity and policy changes out of critical high-availability request paths. Create and update them in setup or deployment stages that can tolerate propagation time.

Your practical goal is not the shortest policy. It is an access design that a reviewer can explain: who assumes which identity, which credentials exist, which actions are allowed, which guardrails apply, and where evidence is recorded.