AWS IAM — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about AWS IAM.
IAM launched four years after AWS itself¶
AWS Identity and Access Management did not exist at AWS launch. It was introduced in June 2010, meaning that for the first four years of AWS (2006-2010), there was essentially one set of credentials per account — the root account keys. Everyone on a team shared the same access.
IAM policies can be up to 10,240 characters long¶
Managed IAM policies have a maximum size of 6,144 characters for customer-managed policies, but inline policies embedded directly on a user, group, or role can be up to 10,240 characters. This limit has caused real production outages when teams hit the ceiling and cannot add new permissions.
The root account cannot be restricted by IAM policies¶
No IAM policy, service control policy, or permission boundary can deny the root user access to anything within its own account. The root user can always recover full control, which is why AWS strongly recommends enabling MFA, deleting root access keys, and never using root for daily operations.
AWS evaluates IAM policies in a specific 11-step order¶
Policy evaluation follows a precise chain: explicit deny in any policy wins first, then Organizations SCPs, then resource-based policies, then identity-based policies, then permission boundaries, then session policies. An implicit deny is the default — access must be explicitly granted and not explicitly denied at any level.
IAM roles assume identities using the Security Token Service¶
When a service or user assumes an IAM role, the underlying mechanism is AWS STS (Security Token Service), which issues temporary credentials valid for between 15 minutes and 36 hours. STS was originally a separate service launched in 2011 but is now tightly integrated with IAM role assumption.
There is a hard limit of 5,000 IAM users per account¶
Each AWS account can have at most 5,000 IAM users. This limit is not adjustable through support tickets. Organizations with more than 5,000 individuals must use federated access via SAML, OIDC, or AWS IAM Identity Center (formerly AWS SSO) instead of creating individual IAM users.
IAM Access Analyzer uses automated reasoning, not heuristics¶
Launched in 2019, IAM Access Analyzer uses Zelkova, an internal AWS tool based on automated mathematical reasoning (specifically, satisfiability modulo theories). It proves whether a resource policy can grant access to external principals, providing provably correct findings rather than probabilistic guesses.
Service-linked roles cannot be modified by customers¶
AWS introduced service-linked roles so that AWS services could maintain the exact permissions they need without customers accidentally breaking them. These roles are created by the service itself and have policies managed entirely by AWS. You can delete them (with restrictions), but you cannot edit their permissions.
The wildcard principal in S3 bucket policies caused countless data leaks¶
The principal "*" in a resource policy grants access to anyone on the internet. Between 2017 and 2019, misconfigured S3 bucket policies with wildcard principals exposed data from organizations including the US Department of Defense, Verizon, and Dow Jones. AWS responded with S3 Block Public Access in 2018.
IAM policy variables let you build self-service policies¶
Policy variables like ${aws:username} and ${aws:PrincipalTag/department} allow writing a single policy that dynamically scopes permissions per user. For example, one policy can restrict each user to their own home folder in S3 by referencing s3:prefix matching ${aws:username}/*.