IAM Users vs Roles vs Instance Profiles: Best Practices

AWS IAM has three core identity primitives, and confusing them leads to the single most common security mistake: using IAM users with static access keys for workloads.

IAM User — mostly obsolete in 2026

• Persistent identity with passwords or access keys; long-lived credentials
• Appropriate only for emergency break-glass access if SSO breaks, or legacy systems that can't federate
• Every other use case is better served by roles

IAM Role — the default for workloads and humans

• A set of permissions with no credentials of its own; principals assume the role to receive temporary credentials (15 minutes to 12 hours)
• No static keys to leak; trust policy defines who can assume
• Used for: EC2 instances via instance profile, Lambda execution role, ECS task role, EKS pods via IRSA, cross-account access, SSO users, CI/CD via OIDC

Instance Profile — the EC2-specific plumbing

• A container that attaches one IAM role to an EC2 instance
• The SDK finds credentials via the instance metadata service automatically; no config needed
• Rotating the role's permissions updates instantly with no credential distribution

The modern architecture

• Humans: IAM Identity Center (SSO); corporate IdP federates to AWS; users assume roles scoped to their team and environment; credentials are time-bounded
• Workloads: task/service roles; code reads credentials from the SDK's default chain; no static keys anywhere
• CI/CD: OIDC federation; GitHub Actions or GitLab CI present a signed token, AWS exchanges for role credentials; no access keys in secrets
• Break-glass: 1-2 IAM users for emergency only, strong passwords, MFA, keys stored offline

The decision rules

• EC2 workload: instance profile with role
• Lambda: execution role
• ECS: task role (app) + execution role (ECS agent)
• EKS pods: IRSA (service account annotation)
• Human access: IAM Identity Center
• CI/CD: OIDC federation
• Never: long-lived IAM user access keys for workloads

The best practices

• Never use IAM users for workloads — the cardinal sin; keys leak in logs, configs, repos
• Enforce IMDSv2 everywhere — v1 had an SSRF-exfiltration vulnerability; v2 requires session tokens
• Trust policies are the security boundary — who can assume the role matters more than permissions; overly permissive trust policies like Principal: * are critical bugs
• Deny overrides allow — use explicit deny in SCPs or policies for guardrails
• Permission boundaries cap what delegated roles can do — essential when letting teams create their own roles
• ABAC (tag-based) scales better than RBAC at large orgs — tag resources and principals, write policies matching tags
• IAM Access Analyzer finds overly broad permissions and external access; run monthly

The cultural piece

• Every team member logging in via SSO means offboarding happens automatically via the IdP
• Every workload on roles means no secrets to rotate, no keys to leak
• Every CI on OIDC means no AWS keys in GitHub/GitLab secrets
• The goal: zero long-lived AWS credentials in the entire organization; achievable in 2026