AWS IAM roles and policies: what practitioners need to know

At a glance

What this is: This is a practical explanation of how AWS IAM roles and policies differ, with examples of how each shapes permissions for users, groups, and resources.

Why it matters: For IAM and NHI practitioners, the key issue is whether access is granted through durable identities or through tightly scoped, policy-driven permissions that can be reviewed, rotated, and revoked.

👉 Read StrongDM's guide to AWS IAM roles vs policies

Context

In AWS, IAM controls often fail when teams treat roles and policies as interchangeable. A role is an identity that can take on permissions, while a policy is the rule set that defines what that identity or resource can do. For NHI governance, that distinction matters because service accounts, tokens, and workload access are governed more safely when permissions are explicit, reviewable, and time-bounded.

The article reflects a common cloud security pattern: practitioners understand the basic building blocks, but the operational challenge is turning them into least-privilege access at scale. That challenge becomes sharper as organisations rely on more service accounts, automation, and ephemeral workloads. For broader NHI lifecycle guidance, practitioners should compare this model with the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs.

Key questions

Q: How should teams decide between AWS roles and policies for access control?

A: Use roles when you need an assumable identity for a task, project, or workload, and use policies to define the exact permissions that identity can exercise. The clean rule is that roles represent who or what can act, while policies define what actions are allowed. That separation makes reviews, revocation, and audit trails much easier to manage.

Q: Why do AWS roles usually support least privilege better than static user permissions?

A: Roles support least privilege better because they let teams package only the permissions needed for a specific purpose, then assign or revoke that package without editing every identity individually. This reduces standing access and makes it easier to remove rights when a project ends or a workload changes.

Q: What is the difference between identity-based and resource-based policies?

A: Identity-based policies attach to a user, group, or role and define what that identity can do. Resource-based policies sit on the target resource and define which identities may access it. The practical difference is where the control lives, which affects governance, review scope, and how easily teams can detect overexposure.

Q: How can security teams reduce privilege drift in AWS IAM?

A: Security teams can reduce privilege drift by reviewing role assignments, group membership, and policy conditions on a fixed schedule, then removing access that no longer matches the business need. They should also tie access changes to lifecycle events such as onboarding, project completion, and offboarding so permissions do not linger.

Technical breakdown

How AWS policies constrain identity permissions

An AWS IAM policy is a permission document that allows or denies actions against resources. Identity-based policies attach to a user, group, or role and travel with that identity, while resource-based policies sit on the target resource and define who can access it. The practical power comes from policy statements, which combine service, action, resource, and condition elements. Conditions are where teams narrow access by date, network location, or other context, which is the difference between broad entitlement and task-scoped control.

Practical implication: Treat policies as the enforcement layer and review conditions first when access seems broader than intended.

Why IAM roles are a better fit for delegated access

A role is an AWS identity that can be assumed for a task, rather than a long-lived account tied to a single person or service. This makes roles especially useful for delegation, temporary project access, and shifting responsibilities. A role can collect multiple permissions into one package, then be assigned to many users or workloads without editing each entitlement separately. In NHI terms, this is closer to a governed access wrapper than a standing credential, which reduces the need to manage ad hoc permissions one by one.

Practical implication: Use roles to bundle task-based access and limit the spread of individually maintained permissions.

Where users, groups, and roles create governance drift

Users represent named human or service identities, groups collect users for shared policy assignment, and roles package permissions for delegated use. The risk appears when teams use groups or users as long-term entitlement stores instead of using roles and policies to express intent clearly. In practice, that creates hidden privilege growth, stale access, and review fatigue. For cloud governance, the question is not which construct is available, but which one creates the cleanest audit trail and the smallest blast radius when access changes.

Practical implication: Map each access pattern to the narrowest construct that supports it, then audit for entitlement drift on a fixed schedule.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Roles and policies are not interchangeable control types, and treating them that way weakens cloud governance. A role is an identity construct, while a policy is the permission logic attached to an identity or resource. Security teams that blur the two tend to over-assign access, then compensate with manual review. The better model is to use roles for delegation and policies for explicit constraint, because that creates clearer ownership and easier revocation.

Task-scoped access is the real security value of roles, not convenience. The strongest use of roles is ephemeral or bounded access for a specific workload, project, or operational task. That aligns well with NHI governance because machines, services, and automations should not rely on standing permissions when a narrower session can work. Practitioners should prefer role-based delegation wherever a long-lived identity would otherwise accumulate permanent rights.

Policy conditions are where least privilege either succeeds or fails. A policy without conditions often becomes a broad allow list, especially in fast-moving cloud environments. Conditions let teams bind access to time, resource, or context, which is essential when workloads and service accounts are changing faster than review cycles. The practitioner conclusion is simple: if conditions are absent, least privilege is usually only claimed, not enforced.

Identity sprawl in AWS should be treated as an NHI lifecycle problem, not just an IAM configuration problem. Users, groups, roles, and service identities accumulate over time unless provisioning, rotation, and offboarding are handled as a process. That is why cloud access design must be joined to lifecycle governance. Teams should assume that any role or policy not actively managed will eventually become excess access.

Named concept: identity-to-policy drift. This is the gap that appears when a role, user, or group keeps permissions long after its original purpose has changed. The drift is rarely visible in a single policy document, but it becomes obvious in audits, incident response, and access reviews. Practitioners should look for this drift continuously rather than waiting for a periodic recertification cycle.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing that remediation lag often outlasts the initial exposure window.
• For the broader lifecycle angle: Review the NHI Lifecycle Management Guide to connect role design to provisioning, rotation, and offboarding decisions.

What this signals

Identity-to-policy drift is the governance failure mode that matters here. AWS teams often start with clean role design, then accumulate ad hoc policy exceptions, broad groups, and unused identities. Over time, the access model becomes harder to explain than to use, which is exactly when audit gaps and privilege creep begin to widen.

If your environment already treats service accounts and automation as part of the access estate, the next step is to manage them with the same review rigor as human identities. That means role scoping, condition enforcement, and lifecycle controls should be linked to the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 functions for protect and govern.

For practitioners

• Separate delegation from authorization Use roles for assumable access and policies for the permission rules attached to that access. Document which control owns the identity, which control owns the permissions, and which team approves each change.
• Apply conditions to every high-risk policy Add time, resource, or context conditions wherever a policy can safely narrow access. This is especially important for production resources, administrative actions, and temporary project access.
• Review group membership as if it were privileged access Do not treat groups as a convenience layer only. Revalidate membership, remove stale users, and confirm that group-attached policies still match current job functions.
• Map AWS access to NHI lifecycle controls Tie role creation, rotation of credentials, and offboarding steps to a formal lifecycle process so that access does not outlive the workload or project it supports. The NHI Lifecycle Management Guide is a useful reference point for that discipline.

Key takeaways

• AWS roles and policies solve different problems, and confusing them weakens access governance.
• Least privilege depends on policy conditions, not just on assigning fewer permissions.
• For NHI and cloud access control, the real test is whether permissions can be reviewed, time-bounded, and removed cleanly.

Key terms

• AWS IAM Policy: An AWS IAM policy is a rule document that allows or denies specific actions on specific resources. It is the permission layer in AWS access control, and it can attach to identities or resources. In practice, policies are where teams encode least privilege, context limits, and explicit exceptions.
• AWS IAM Role: An AWS IAM role is an identity that can be assumed to gain a defined set of permissions. It is designed for delegation rather than long-lived ownership, which makes it well suited to temporary access, workload access, and task-based administration. Roles help reduce standing privilege when managed well.
• Identity-based Policy: An identity-based policy attaches to a user, group, or role and defines what that identity is allowed to do. It travels with the identity rather than the target resource, which makes it useful for central entitlement management. The main governance risk is allowing these policies to grow broader over time.
• Resource-based Policy: A resource-based policy lives on the resource itself and determines which identities can interact with it. It is useful when access control needs to be expressed from the perspective of the asset rather than the identity. For practitioners, it adds flexibility but also expands the places where exposure can hide.

Deepen your knowledge

AWS IAM role design, policy conditions, and lifecycle-aware access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is translating cloud IAM concepts into NHI governance, it is worth exploring.

This post draws on content published by StrongDM: AWS IAM roles vs policies and the differences between users, groups, roles, and policies. Read the original.