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

Why This Matters for Security Teams

AWS roles and policies are often discussed as if they are interchangeable, but they solve different parts of access control. Roles create an assumable identity for a workload, automation job, or temporary operator action. Policies define the exact actions that identity can take. That split matters because modern NHI estates are large, fast-changing, and frequently over-permissioned. NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.

The practical risk is not theoretical. Excess privilege, stale access, and unclear ownership tend to accumulate when teams define permissions once and never revisit them. NIST’s NIST Cybersecurity Framework 2.0 reinforces that identity governance must be managed continuously, not as a one-time configuration task. In AWS environments, this means treating the role as the trust boundary and the policy as the enforcement layer, then reviewing both against the workload’s real behavior, not the org chart.

Security teams often get this wrong when they attach broad policies to shared roles and later discover that the role has become a hidden privilege escalation path rather than a controlled access mechanism.

How It Works in Practice

Use the role to answer “who or what is allowed to assume this identity?” and use policies to answer “what can that identity do once assumed?” In AWS, that usually means a workload, CI/CD job, or automation service assumes a role through STS, then inherits permissions that are explicitly bounded by attached policies, permission boundaries, and session conditions. This is where good design starts to look like NHI lifecycle management rather than simple IAM administration. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful for framing assignment, rotation, review, and revocation as a single control loop.

In practice, the cleanest pattern is:

• assign one role per workload or task class, not one role for an entire application estate;
• keep policies narrow and action-specific, with resource scoping wherever possible;
• use conditions for environment, source, and session constraints rather than bloating the action list;
• review trust policies separately from permission policies, because they answer different questions;
• prefer short-lived sessions and explicit revocation paths over long-lived static credentials.

This approach aligns with the least-privilege direction highlighted in the OWASP Non-Human Identity Top 10, especially where service identities are reused across pipelines, applications, and support tooling. It also matters because secrets exposure is still common: 30.9% of organisations store long-term credentials directly in code, and 96% store secrets outside secrets managers in vulnerable locations, according to Ultimate Guide to NHIs. Policies should be written to constrain blast radius even if a role is misused, while roles should remain specific enough that access reviews can answer a simple question: what exact workload needs this identity, and for how long?

These controls tend to break down when a single role is shared by multiple pipelines, microservices, or teams because the policy becomes a compromise document instead of a precise authorization boundary.

Common Variations and Edge Cases

Tighter role scoping often increases operational overhead, requiring organisations to balance manageability against privilege reduction. That tradeoff is real, especially in legacy AWS estates where applications were built before workload-level identity was a design requirement. Current guidance suggests starting with role-per-workload for new systems, then progressively refactoring shared roles where auditability or blast-radius reduction is weak. There is no universal standard for how granular every role must be, but best practice is to avoid “platform umbrella” roles unless there is a documented exception.

Edge cases usually appear when teams confuse policy granularity with identity design. For example, adding more policy statements to a weak role does not fix the problem if the same role can be assumed by too many services. Likewise, a highly specific role becomes risky if the attached policies still allow broad resource access. This is why the trust policy, session duration, and conditions must be reviewed together.

In higher-risk environments, pair roles and policies with PAM, JIT access, and strong offboarding discipline, especially for admin and break-glass paths. If the workload behaves autonomously or can chain actions through tools, the team should also consider whether static RBAC is enough or whether context-aware approval is needed at request time. For broader governance context, see the Top 10 NHI Issues and the audit-focused guidance in Ultimate Guide to NHIs — Regulatory and Audit Perspectives.

Related resources from NHI Mgmt Group

• What is the difference between broken access control and security misconfiguration in NHI environments?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• What is the difference between reviewing human access and reviewing NHIs?