Amazon AWS SCS-C03: Permission Boundaries in AWS

IAM permissions boundaries are delegation controls. A boundary is a managed policy attached to an IAM user or role that defines the maximum permissions identity-based policies can grant to that entity. The boundary does not grant permissions by itself. A bounded role can have an identity policy that says “Allow everything” and still be limited to the intersection between that identity policy and the boundary, subject to explicit denies and other organization or session controls.

This makes permissions boundaries valuable when central security teams want developers or platform administrators to create IAM roles without allowing those delegated administrators to create roles more powerful than the enterprise baseline. The design still requires careful trust policies, resource policies, SCPs, and delegation permissions; a boundary is one layer in the authorization system rather than a universal sandbox.

Permissions-boundary design belongs inside AWS Security Engineering.

Use boundaries as maximums, not grants

A permissions boundary says what a user or role may never exceed through its identity permissions.

IAM mental models are easier when teams separate “grant” policies from “maximum” policies.

If the identity policy does not allow an action, the boundary cannot create that permission.

Use boundaries for delegated role creation

A common pattern lets developers create application roles only when the new role has an approved permissions boundary.

The administrator’s own IAM policy can require the iam:PermissionsBoundary condition on CreateRole or related operations.

This lets teams self-service role creation while central security controls the upper permission limit.

Prevent boundary removal

Delegation is ineffective if the same developer can remove or replace the boundary with a weaker one.

Restrict DeleteRolePermissionsBoundary and PutRolePermissionsBoundary so only approved boundary policies can be used.

Use conditions, SCPs, and role separation to keep the delegation ceiling outside the control of the delegated principal.

Keep trust policies separate

A boundary limits what a role can do after assumption; the role trust policy controls who can assume the role.

A narrowly bounded role can still be risky if an unintended external account, service, or federated principal can assume it.

Review trust and permission policy together when evaluating the role’s effective security boundary.

Account for resource policies

Resource-based policies can participate in IAM evaluation differently depending on the principal type and context.

IAM policy evaluation should be reviewed before assuming a boundary automatically constrains every possible resource-policy grant.

High-risk services such as S3, KMS, SQS, and SNS need resource-side policy review as well as role-side boundaries.

Combine boundaries with SCPs

SCPs set organization-level maximum permissions for member accounts, while boundaries constrain selected users and roles inside an account.

Security governance can use both layers: SCPs for non-negotiable enterprise guardrails and boundaries for local delegated administration.

An action must still survive all applicable explicit denies and maximum-permission layers.

Keep boundaries simple and reusable

One huge boundary full of application-specific exceptions becomes difficult to reason about.

Create boundaries around durable job or workload classes such as serverless application, data pipeline, or platform automation where those classes share a meaningful maximum.

Version and review the policies because AWS adds services and permissions over time.

Test both allowed and denied actions

Delegation tests should prove that a developer can create the intended role and cannot create an unbounded role, remove the boundary, attach a prohibited policy, or use an alternate service path to escape the intended maximum.

Negative tests are the strongest evidence that the boundary pattern actually limits privilege.

Automate these tests in policy validation or sandbox accounts before changing enterprise delegation.

Use boundaries where they reduce administrative bottlenecks

For SCS-C03, the durable pattern is approved maximum → delegated create policy → enforced boundary ARN → protected boundary mutation → trust-policy review → SCP/resource-policy context → negative test.

Permissions boundaries are successful when teams can create roles quickly without central security reviewing every individual permission statement.

The control scales authority by constraining what delegated administrators are capable of granting.

Boundaries are attached only to IAM users and roles; they are not attached to groups. If a delegated model relies on groups for administrators, the boundary still must be enforced on every user/role that those administrators create or manage. Automation is usually safer than expecting humans to remember the required boundary ARN.

The boundary itself should live in a location and namespace that delegated administrators cannot edit. A boundary policy whose JSON can be changed by the same principal it constrains offers little security. Keep policy ownership in a central platform/security path and allow delegation only to attach approved versions.

Developers often need iam:CreateRole, iam:PutRolePolicy, iam:AttachRolePolicy, and iam:PassRole. The delegation policy must constrain all of these operations. Requiring a boundary at role creation but allowing unrestricted PassRole to a central administrator role can bypass the intended ceiling.

Resource policies can create important caveats. AWS IAM documentation explains that some resource-based grants to IAM user ARNs or role-session ARNs are not limited in the same way as grants to the underlying role through identity policies. Security architects should avoid assuming “boundary attached = all permissions capped” without reviewing the exact principal used by the resource policy.

Session policies can further reduce a bounded role after assumption. This is useful for brokers that dynamically narrow a shared role to one ticket, project, or resource set. The final permissions remain constrained by role identity policies, boundary, session policy, SCPs, and any explicit deny.

SCPs can protect the permissions-boundary control itself. For example, an organization may deny deletion or modification of designated boundary policies outside a security account or prevent roles from being created without expected constraints. SCP design should remain simple enough not to break AWS services or emergency operations unintentionally.

Boundary policies should avoid NotAction patterns that are difficult to reason about unless the team fully understands the resulting permission surface. Explicit lists of approved service actions often make delegation intent clearer, especially when the boundary is supposed to constrain developers to a known platform.

Tags can support delegated role governance. Administrators can be allowed to manage roles tagged for their team while denied access to platform or security roles. Authorization-sensitive tags need protection so the delegated administrator cannot retag a privileged role into its own management scope.

Permission boundaries are especially useful in platform products that let teams deploy infrastructure independently. The platform can precreate the boundary and deployment role, then let each team define its application IAM roles within the approved maximum. This is faster than central review of every IAM statement and safer than giving each team unrestricted IAM administration.

Policy updates should have compatibility testing. Tightening a boundary can break existing applications immediately even though their identity policies did not change. Before organization-wide rollout, evaluate representative roles and CloudTrail access patterns to identify workloads that legitimately need a capability the new boundary removes.

Loosening a boundary is equally sensitive because permissions previously present in identity policies can suddenly become effective. A role might already have an old broad policy that was harmless only because the boundary blocked it. Review attached identity policies before expanding the boundary.

Access Analyzer and policy validation can help identify overly broad delegation policies. Use them before deployment, then verify with live negative tests in a sandbox. Static analysis cannot prove that a delegated administrator lacks every creative escalation path through PassRole, Lambda, CloudFormation, or another service.

Incident response should know how to distinguish boundary denial from SCP or identity-policy denial. CloudTrail and authorization messages can reduce time spent changing the wrong policy layer. Boundaries should be named and documented so support teams recognize when a denied action is intentional platform governance.

Boundaries should be reviewed after new AWS services are adopted. A developer platform that originally allowed EC2, S3, and RDS may later need Bedrock, EventBridge, or new serverless services. Extend the boundary deliberately with the minimum required actions rather than replacing it with a wildcard when the platform evolves.

The governance outcome is delegated autonomy with a provable upper limit. When teams can create their own roles, deploy quickly, and still cannot grant access to organization administration, security logs, billing controls, or unrelated data, the permissions-boundary pattern is doing its job.

Boundaries can also help managed platform teams publish safe self-service roles. A data platform might let product teams create roles that access only approved analytics services, while a serverless platform allows Lambda, EventBridge, SQS, and application data actions but not Organizations, IAM administration, or log-archive access. The boundary becomes a product contract for the platform.

Every exception to a boundary should be visible. If one workload needs an action outside the standard maximum, decide whether the platform class should evolve or whether the workload deserves a separately governed role. Replacing the boundary with a one-off broad policy undermines the delegation model and makes future access review harder.

Review boundaries during incident postmortems. If an attacker with a developer role was able to escalate through a service action allowed by the boundary, update the maximum and add a regression test. Delegation controls should evolve from real abuse paths just like network and application guardrails.