# A pragmatic approach to AWS IAM policies
> Four rules we use to keep AWS IAM policies least-privilege without drowning in policy sprawl — conditions, boundaries, and versioning.
- Canonical: https://starcomputers.in/blog/a-pragmatic-approach-to-aws-iam-policies
- Published: 2026-04-12
- Tags: aws, iam, security
---
## The usual failure mode

Teams start with "developers get AdministratorAccess in dev," promise to tighten it later,
and then two years on have 400 inline policies they're scared to touch. Every audit turns
into an archaeology project.

## Four rules that hold up

### 1. Model access by workload, not by person

Grant permissions to the role a workload runs as, and let humans assume that role through
SSO. Policies attached directly to users become orphaned when someone leaves.

### 2. Prefer conditions over new policies

Before writing a new policy, see if an existing one plus a `Condition` block gets you
there. The set of *distinct* policies should grow slowly.

```json
{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "StringEquals": { "aws:PrincipalTag/team": "finance" }
  }
}
```

### 3. Boundaries for delegated role creation

If another team creates IAM roles in your account, attach a permissions boundary to the
role that does the creating. It caps what downstream roles can do, no matter what inline
policy gets attached.

### 4. Review on a cadence

Once a quarter, run Access Analyzer's unused-access findings. Delete what hasn't been used
in 90 days. The graph of "permissions granted" should trend down, not up.

## Takeaways

- IAM sprawl is a social problem more than a technical one. These rules give teams
  something to point at.
- You don't need fancy tooling to start — four rules and a quarterly review beat a
  homegrown policy generator every time.