What is the difference between SCPs and permission boundaries in AWS governance?

Why This Matters for Security Teams

AWS governance often gets flattened into a single “least privilege” conversation, but SCPs and permission boundaries solve different control problems. SCPs are organisational guardrails: they define the ceiling for every principal in an account, OU, or organisation. Permission boundaries are narrower and operational: they constrain what a specific IAM role or user can ever receive, even if another policy tries to grant more. That distinction matters when teams delegate provisioning, run multi-account landing zones, or separate platform control from application ownership. For a broader NHI lens on why privilege sprawl becomes a recurring failure mode, see Top 10 NHI Issues and OWASP Non-Human Identity Top 10.

Security teams often misapply permission boundaries as if they were a substitute for organisational policy, then discover that one account or one role was still able to do too much because the broader governance layer was never enforced. In practice, many security teams encounter privilege drift only after a delegation model has already been used to provision access at scale, rather than through intentional policy design.

How It Works in Practice

Think of an SCP as the organisation’s hard ceiling and a permission boundary as a per-identity safety rail. An SCP can deny entire classes of actions across an OU, such as preventing the creation of unapproved IAM users, blocking dangerous regions, or stopping policy changes that weaken governance. A permission boundary, by contrast, is attached to one IAM entity and defines the maximum permissions that entity can ever exercise, even if an admin later attaches broader permissions. That makes boundaries useful for delegated role creation, self-service teams, and environments where platform admins want to let application owners move fast without letting them exceed a preset limit.

In operational terms, current guidance suggests using SCPs for org-wide invariants and permission boundaries for local delegation control. This aligns with broader identity governance principles described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Ultimate Guide to NHIs — Key Challenges and Risks, where lifecycle control and over-privilege are treated as separate problems. A practical review should also map to governance expectations in the NIST Cybersecurity Framework 2.0, especially access control and continuous oversight.

• Use SCPs to set non-negotiable organisational policy, such as denied services, denied regions, or denied privilege escalation.
• Use permission boundaries when teams need to create or delegate IAM entities but must stay within a fixed permission envelope.
• Remember that a boundary does not grant access by itself; it only limits what attached policies can ever allow.
• Review both layers together, because a permissive boundary is not a substitute for a restrictive SCP.

These controls tend to break down when organisations rely on them as a static replacement for continuous access review in large, fast-changing multi-account environments.

Common Variations and Edge Cases

Tighter policy layering often increases operational overhead, requiring organisations to balance guardrail strength against deployment speed. That tradeoff is real in AWS environments with many teams, many accounts, and frequent role creation. The best practice is evolving, but current guidance still favours SCPs for global constraints and boundaries for delegated administration. Teams should avoid treating a permission boundary as a universal “fix” for IAM sprawl, because it only constrains identities that have it attached and can leave other principals unaffected.

Edge cases matter. If a team uses cross-account access, service-linked roles, or automation that creates roles on demand, permission boundaries may be the right tool for delegated creation, but SCPs remain the better place to prevent unsafe services from existing anywhere in the organisation. The same applies when governance teams need auditability: Ultimate Guide to NHIs — Regulatory and Audit Perspectives is a useful reference for aligning controls to evidence and review expectations, while the 230M AWS environment compromise case underscores how quickly weak cloud governance can scale into exposure. For identity design patterns, Ultimate Guide to NHIs — What are Non-Human Identities remains a useful grounding point.

If the organisation is building policy around autonomous workloads or AI agents, the model gets more dynamic than classic IAM. Static role design may still be useful, but it will not replace runtime authorisation, JIT credentials, or workload identity. In those environments, governance should be treated as a real-time control problem, not just a policy attachment problem.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between human IAM controls and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?