AWS IAM Roles and Policies: Principle of Least Privilege in Practice

The IAM Mental Model

Three concepts cover most of IAM. Identity (a principal: user, role, or service) is who’s making the request. Permission (a policy: a JSON document granting or denying actions on resources) is what they can do. Trust (a trust policy on a role) is who can assume the role.

Almost every IAM problem traces back to confusing these three. A user can have permission to do X but no trust relationship with the role that has those permissions, and the operation fails for reasons that aren’t obvious from the error message.

Roles Over Users

IAM users have long-lived credentials. Roles have short-lived credentials issued via STS. In 2025, there’s almost no reason to create new IAM users for anything other than break-glass access.

For human access, federate from your identity provider (Okta, Entra, Google Workspace) into IAM Identity Center, which issues role credentials. For workloads, instance profiles, service-linked roles, or IRSA (IAM Roles for Service Accounts) on EKS keep credentials off disk entirely. The AWS IAM documentation covers the full model in detail.

Writing Policies That Work

A policy is a list of statements. Each statement has an Effect (Allow or Deny), Action (the API operations), Resource (the ARNs), and optional Condition (constraints). The IAM policy reference documents every available element.

Least privilege means scoping each statement narrowly. s3:GetObject on a specific bucket prefix is least privilege. s3:* on * is the opposite. Most policies start broad in development and never get narrowed; that’s the gap to close.

Permissions Boundaries and SCPs

Permissions boundaries cap what a role can do regardless of attached policies. They’re useful for delegating permission management — you let a team grant their own roles permissions, but the boundary ensures they can’t grant more than you allowed.

Service Control Policies (SCPs) operate at the AWS Organizations level. They’re guardrails: even an account admin can’t do something an SCP denies. Use them for org-wide rules like ‘deny actions outside approved regions’ or ‘deny CloudTrail disable’.

Tools and Discipline

IAM Access Analyzer surfaces overly permissive policies and external trust relationships. Run it regularly.

Policy generation tools (the IAM console’s generator, iamlive, or aws-iam-actions-list) help build narrowly-scoped policies from observed activity. They’re starting points, not final outputs.

The discipline matters more than the tools: every new policy gets reviewed, every existing policy gets audited periodically, and broad permissions get questions in code review.

Service Control Policies and Account Strategy

At organization scale, individual IAM policies are inadequate. Service Control Policies (SCPs) operate above IAM — they cap what any principal in an account can do, regardless of IAM grants.

Standard SCP patterns: deny actions in non-approved regions, deny disable of CloudTrail or Config, deny actions on production resources from non-production accounts, require MFA for sensitive operations. SCPs are coarse but enforceable; layer IAM policies underneath for fine-grained control.

Cross-Account Access Patterns

The modern multi-account architecture uses dedicated accounts per environment per workload. Cross-account access happens via role assumption: a principal in Account A assumes a role in Account B with appropriate trust policy.

For human access, IAM Identity Center centralizes this — users authenticate once, choose an account and role, and get temporary credentials. For workload access, IAM Roles Anywhere and tagged trust policies let workloads in one account assume roles in another without static credentials.

Policy Simulation and Testing

IAM Policy Simulator lets you test whether a specific principal can perform a specific action. Use it before changing policies in production — verify the change has the intended effect.

The simulator misses some real-world subtleties (session policies, permission boundaries, resource-based policies). For high-stakes changes, test in a non-production account first.

iamlive and similar tools record real API calls during a session and generate matching IAM policies. The starting point for least-privilege policies is what the workload actually does, not what the documentation suggests it might need.

Common IAM Anti-Patterns

AdministratorAccess granted broadly. The default safe pattern is no admin access, with break-glass roles assumed only when needed and audited.

Wildcard resources and actions throughout policies. s3:* on * is rarely necessary. Most policies can be narrowed to specific buckets, prefixes, and actions.

Long-lived access keys on developer laptops. Static credentials get leaked. SSO with short-lived role credentials via Identity Center is dramatically safer.

Service accounts using broad IAM roles. Each workload deserves its own role with narrow permissions, not a shared role that combines every permission anyone might need.

Hybrid and Multi-Cloud Considerations

Few large organizations are purely single-cloud. Acquisitions, regulatory requirements, and specific service preferences all push toward multi-cloud reality. The challenge is operating consistently across the resulting environment.

Tools that help: Crossplane for multi-cloud infrastructure provisioning, Terraform for multi-provider IaC, Kubernetes as a consistent application platform across clouds. Each abstracts away some cloud-specific details at the cost of giving up some cloud-specific capabilities.

The pragmatic path is usually ‘primary cloud plus secondary’ — most workloads on one cloud with specific workloads or backup capacity on another. Pure multi-cloud parity is rarely worth the operational cost.

Tagging and Resource Governance

At any meaningful scale, cloud resource governance requires consistent tagging. Tags by team, environment, project, cost center, and compliance category enable cost attribution, security scoping, and operational filtering.

Enforcement is the hard part. IAM policies can deny resource creation without required tags. Cloud Custodian and similar policy engines can scan for non-compliant resources and remediate.

Without enforcement, tags drift. Engineers create resources for quick experiments and forget to tag. Within a quarter, untagged resources outnumber tagged ones. Build the enforcement early; retrofit is painful.

Documentation and Knowledge Management

Cloud infrastructure changes constantly. Documentation that captures architecture decisions, runbooks for common operations, and explanations of non-obvious choices preserves institutional knowledge through team turnover.

Architecture Decision Records (ADRs) are a lightweight pattern: a short document per significant decision capturing context, options considered, decision, and consequences. ADRs accumulate into a chronicle of why the architecture looks the way it does.

Living documentation beats one-time writeups. Tie documentation to code where possible — README files in repos, comments in Terraform, generated diagrams from infrastructure tools. Documentation that lives near the code it documents stays current.

Compliance and Audit Considerations

Cloud workloads often fall under compliance frameworks: SOC 2, ISO 27001, HIPAA, PCI DSS, FedRAMP. Each has specific control requirements affecting how you architect, configure, and operate.

Common cross-framework requirements: encryption at rest and in transit, access logging and review, incident response procedures, change management, vulnerability management. Building these in from the start is dramatically cheaper than retrofitting under audit pressure.

Tools that help: AWS Config and Audit Manager, GCP Security Command Center, Azure Policy. Each provides continuous compliance monitoring against defined rules. The configuration is upfront work; ongoing compliance becomes monitoring rather than periodic discovery.

Looking Ahead

Cloud infrastructure continues to evolve rapidly. The shifts most relevant to platform teams today: continued moves toward serverless and managed services that reduce operational overhead, growing importance of cost optimization as cloud spend matures into a major budget line, and the increasing role of compliance and data sovereignty in architecture decisions.

Teams that invest in transferable skills — Linux fundamentals, networking, distributed systems, observability — adapt to specific cloud changes more easily than teams that invest narrowly in vendor-specific certifications. The vendor-specific knowledge matters, but it’s a layer on top of broader engineering capability.

The cost of building infrastructure has dropped dramatically in two decades; the cost of operating it well has not. The teams that thrive long-term combine cloud-native tooling with the operational discipline that makes any infrastructure reliable.

Practical takeaway: don’t chase every new cloud service. Identify the gaps in your current architecture, evaluate options carefully against your requirements, and move deliberately. The pace of cloud announcements far exceeds the pace at which most organizations should adopt new technologies.

Frequently Asked Questions

How do I make IRSA work on EKS?

Associate an OIDC provider with the cluster, create an IAM role with a trust policy referencing the OIDC provider and a specific service account, annotate the service account with the role ARN. Pods using that service account get role credentials via the SDK chain.

Should I use customer-managed policies or inline policies?

Customer-managed for anything reused. Inline for one-off role-specific policies. Avoid AWS-managed broad policies (AdministratorAccess) outside of break-glass.

How do I audit who can do what?

IAM Access Analyzer for cross-account access. IAM Access Advisor (per-role last-used data) for unused permissions. CloudTrail for actual API call history.

What about Permissions Sets in IAM Identity Center?

Permission sets are the modern way to grant federated users access. Define the policy once, assign it to many accounts.