AWS IAM Permission Boundaries Explained (With Examples)

A permission boundary is an advanced IAM feature that sets the maximum permissions an IAM role or user can ever have. It does not grant anything on its own. Instead it caps what the identity's other policies are allowed to do. The effective permissions of an identity with a boundary are the intersection of its permission policies and its boundary: an action is allowed only if both permit it. This single rule is the whole mental model, and it is the part teams most often get wrong.

Why Boundaries Exist

The classic problem is safe delegation. You want a team to create their own IAM roles for their own workloads, but you do not want them to be able to create a role with AdministratorAccess and assume it. A permission boundary lets you hand out iam:CreateRole while requiring that every role they create carries a boundary you control. No matter what permission policy they attach, the new role can never exceed the boundary. This is how platform teams delegate IAM without delegating account takeover.

How the Evaluation Actually Works

For an identity that has a boundary, an action is allowed only when it is allowed by the permission policies and allowed by the boundary, and not blocked by any explicit deny or service control policy. An Allow in the boundary grants nothing by itself — the permission policy still has to allow the action too. People frequently misread this and assume the boundary is a second grant. It is a ceiling, not a floor.

A common example: the permission policy grants s3:* and dynamodb:*, but the boundary only allows s3:*. The effective permission is s3:* only. The DynamoDB grant is silently capped away by the intersection.

A Boundary You Can Reuse

A boundary is just a managed policy you attach in the boundary slot. This one caps an identity to S3 and CloudWatch Logs and explicitly forbids it from touching IAM, so a delegated role can never grant itself more:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowedServices",
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "logs:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "NeverIam",
      "Effect": "Deny",
      "Action": "iam:*",
      "Resource": "*"
    }
  ]
}

To enforce that delegated roles must carry this boundary, the team's iam:CreateRole permission is granted with a condition requiring the boundary to be set:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:CreateRole",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/TeamBoundary"
        }
      }
    }
  ]
}

The Mistakes That Break Boundaries

• Treating the boundary as a grant. If the permission policy does not allow an action, adding it to the boundary does nothing. The action is still denied.
• Delegating iam:CreateRole without a boundary condition. If you let a team create roles but do not require iam:PermissionsBoundary, they can create an unbounded admin role and assume it. The boundary feature only helps when its use is enforced.
• Forgetting iam:PutRolePolicy and iam:AttachRolePolicy. A delegated role that can modify its own permission policies, but whose boundary still allows broad actions, can widen itself up to the boundary. Keep the boundary genuinely narrow.
• Confusing boundaries with SCPs. A service control policy applies to a whole account or organizational unit; a permission boundary applies to a single identity. Both are caps, but they operate at different scopes and you may need both.
• Leaving the boundary off entirely. An identity with no boundary is capped only by its policies and any SCPs. Boundaries are opt-in per identity, so a missing boundary is easy to overlook in review.

Boundaries Are Not a Substitute for Least Privilege

A boundary limits the blast radius of a delegated identity, but the permission policy still decides what is actually granted. The two work together: scope the permission policy to what the workload needs, and use the boundary as a hard ceiling that no future policy edit can exceed. A boundary alone, with a wide-open permission policy, still hands out everything the boundary allows.

Permission boundaries are powerful but easy to misconfigure precisely because the intersection logic is invisible in the console's per-policy view. If you are not sure whether a boundary actually caps what you think it caps, paste the boundary and the permission policy into Shieldly and let it spell out the effective permissions and any gap.

Amazon Web Services (AWS) is a trademark of Amazon.com, Inc. Shieldly is not affiliated with, endorsed by, or sponsored by Amazon Web Services.