IAM Done Right: A Practical Guide to Least-Privilege on AWS

Most AWS IAM setups are either too permissive or so tight they block engineers. How we get to least privilege without slowing anyone down.

IAM is the most consequential part of your AWS security posture, and the part most teams get wrong. The two failure modes are equally common: accounts with wildcard permissions everywhere because "it just works," and accounts so locked down that engineers can't get their jobs done.

Neither is acceptable. Here's the framework we use to build IAM architectures that are genuinely least-privilege without making your team miserable.

Start with roles, not users

IAM users with long-term access keys are a liability. They rotate slowly (or never), they leak into .env files and Git repositories, and they can't be scoped to specific conditions. Every human and service should authenticate via an IAM role — not a user with keys.

• Humans access AWS via SSO (IAM Identity Center) — roles are assumed via SAML federation, no keys issued

• CI/CD pipelines authenticate via GitHub Actions OIDC or CodeBuild IAM role — no long-term keys in secrets managers

• Applications use EC2 instance profiles, ECS task roles, or Lambda execution roles — credentials are auto-rotated by the runtime

• Cross-account access uses role assumption with external ID — no cross-account users

The three layers of IAM

1. Service Control Policies (account-level guardrails)

SCPs are applied at the AWS Organizations level and override everything below them — including administrator roles. Use SCPs for absolute prohibitions: preventing CloudTrail from being disabled, blocking root API calls, enforcing AWS region restrictions.

2. Permission boundaries (role-level guardrails)

Permission boundaries define the maximum set of permissions a role can have. They're particularly useful for delegated administration — allowing a team to create roles for their own services without being able to grant permissions beyond a defined ceiling.

3. Identity policies (the actual permissions)

The policies attached to roles. This is where most IAM work happens. The goal is the smallest set of permissions needed for the specific function of the role, with conditions wherever possible.

Practical patterns for service roles

• One role per service, per environment — a Lambda reading from S3 in staging has a different role than the same Lambda in production

• Resource-level permissions wherever possible (arn:aws:s3:::bucket-name/* instead of *)

• Condition keys on sensitive actions (aws:RequestedRegion, aws:SourceIp, aws:MultiFactorAuthPresent)

• aws:ResourceTag conditions for environment segregation within a single account

• Deny statements for particularly dangerous actions (iam:CreateRole, iam:AttachRolePolicy) even if the allow doesn't exist

The access review cadence

IAM is not "set and forget." Use IAM Access Analyzer to identify policies that grant external access to your resources. Use credential reports to identify unused users (there shouldn't be any) and unused access keys. Use IAM Access Advisor to identify and trim permissions that haven't been used in 90 days.

A quarterly access review takes 2–3 hours for most accounts and dramatically reduces your standing attack surface. For SOC 2, this needs to be documented — we provide templates as part of our security engagements.