AWS IAM: Users, Roles, and the $190 Million Misconfiguration

The Identity Perimeter

Most AWS architectures start with IAM, even if they don't realize it. In a world without a network perimeter, identity is the new edge. Every API call in AWS carries an identity, and IAM is the policy engine that says yes or no.

IAM Components: Users, Groups, and Roles

IAM users are the long-lived identities you might know. But they're the least interesting part. Users have passwords and access keys. Groups collect users and attach policies. Roles, though, are where the real power lives. A role is an identity with permissions, but no fixed credentials—it grants temporary tokens via STS. You can gate everything from cross-account access to federated SAML logins through a role.

> “Use roles instead of users. Always.” — a mantra you’ll hear from any AWS SA.

Why? Because roles force principle of least privilege and eliminate long-lived static keys that leak in GitHub repos.

Policies: The Language of Allow and Deny

IAM policies are JSON documents that describe what actions are allowed or denied on which resources, under which conditions. A simple policy snippet (with explicit allow):

{
  \"Version\": \"2012-10-17\",
  \"Statement\": [
    {
      \"Effect\": \"Allow\",
      \"Action\": [\"s3:GetObject\"],
      \"Resource\": \"arn:aws:s3:::my-bucket/*\",
      \"Condition\": {
        \"StringEquals\": {\"s3:x-amz-server-side-encryption\": \"AES256\"}
      }
    }
  ]
}

Every policy evaluation follows a simple algorithm: explicit deny always beats allow. This lets you build layered security with permission boundaries and SCPs.

The Role Revolution: Why You Should Ditch IAM Users

When an EC2 instance needs to call S3, you don't embed an access key. You attach an IAM role to the instance. The EC2 metadata service (IMDS) provides temporary credentials that rotate automatically. Modern workloads use IRSA (IAM roles for service accounts) on EKS to grant pods granular permissions without sharing worker-node roles.

Cross-account access? Create a role in the target account with a trust policy that allows the source account to assume it. No more duplicating IAM users.

Organizations and Service Control Policies: Guardrails at Scale

With AWS Organizations, you can apply Service Control Policies (SCPs) that act as a maximum-permission boundary across entire OUs. Even an admin can't exceed the SCP. Combine SCPs with permission boundaries on roles to build a true zero-trust posture that prevents lateral movement.

Least Privilege is Hard — Tools That Help

You can use IAM Access Analyzer to refine permissions, Access Advisor to see unused services, and CloudTrail to audit actual API usage. IAM policy generation tools analyze logs and suggest the minimum viable policy. At Sapior, we embed these practices into ephemeral environments: every preview branch gets a short-lived, least-privilege IAM role, so you never ship with `*:*`, even by accident.

Capital One: A $190M Lesson in IAM Misconfiguration

In 2019, an attacker exploited an SSRF vulnerability in a web application firewall. The misconfigured IAM role allowed the attacker to fetch the EC2 instance metadata (which included temporary credentials). Those credentials had broad S3 read permissions. The result: 100 million customer records exposed, and a $190 million fine. [Read the DoJ statement](https://www.justice.gov/opa/pr/capital-one-agrees-pay-190-million-resolve-data-breach-charges). The fix would have been a combination of IMDSv2 enforcement, a content-boundary SCP, and drastically tightening the role’s permissions down to only what the WAF strictly needed.

IAM Isn’t a One-Time Setup

Identity is a living, breathing thing. Teams change, services evolve, and permissions drift. Run continuous monitoring, use MFA everywhere, delete unused credentials, and treat IAM as code (think Terraform, CloudFormation). The investment pays back the first time a leaked key hits a log and your blast radius is a single S3 path, not the entire account.