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.
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.
{
"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.