What is IAM?
AWS defines IAM as the web service that helps you securely control access to AWS resources. IAM provides the infrastructure necessary to control both authentication and authorization for your AWS account. :contentReference[oaicite:1]{index=1}
In practical terms, IAM decides whether a human user, an application, a workload, or an AWS service can perform an action like launching an EC2 instance, reading an S3 object, updating a DynamoDB table, or assuming a cross-account role.
Why IAM matters
Everything in AWS depends on access control
Every production action, console workflow, API call, automation run, and deployment pipeline depends on correct permissions.
Over-permissioning creates real risk
Broad wildcard permissions can turn a small compromise into a large blast radius. Least privilege is not optional in serious AWS environments.
IAM is both security and operations
IAM is not just a security topic. It directly affects developer productivity, CI/CD, incident response, and cross-account platform design.
Root user, IAM users, and IAM roles
AWS documents that every account starts with a root user identity that has complete access to all AWS services and resources in the account. IAM users are identities inside your AWS account with specific permissions, and IAM roles are assumable identities used by humans, workloads, or AWS services to obtain temporary credentials. :contentReference[oaicite:2]{index=2}
| Identity type | What it is | Best use |
|---|---|---|
| Root user | The original account identity with full control | Use rarely and protect heavily with MFA |
| IAM user | An identity within the AWS account | Legacy or specific cases; generally not the preferred workforce model now |
| IAM role | An assumable identity that provides temporary credentials | Preferred for workloads, services, federated users, and cross-account access |
Policies and policy types
IAM policies are JSON documents that define permissions. They answer the question of which actions are allowed or denied on which resources, under which conditions.
Identity-based policies
Attached to users, groups, or roles to define what they can do.
Resource-based policies
Attached directly to resources like S3 buckets or Lambda functions to define who can access them.
AWS managed policies
Created and maintained by AWS for common permission scenarios.
Customer managed policies
Created by your team for your own least-privilege and governance needs.
Simple policy structure mental model
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*"
}
Policy evaluation logic
Understanding IAM policy evaluation is one of the biggest differences between beginner and advanced AWS engineers. At a high level, AWS evaluates all applicable policies together. Explicit deny wins. If there is no explicit allow, the action is denied by default.
Default deny
If nothing explicitly allows an action, the action is denied.
Explicit allow
An allow can permit access if there is no stronger explicit deny blocking it.
Explicit deny
An explicit deny overrides allows and is one of the most important concepts in IAM.
STS and temporary credentials
IAM roles depend on AWS Security Token Service to issue temporary credentials. This is central to modern AWS security because temporary credentials reduce the need for long-lived secrets and support safer delegation patterns.
Why temporary credentials matter
They expire, reduce exposure from leaked secrets, and support better trust-based designs for workloads and users.
Where they are used
EC2 instance roles, Lambda execution roles, EKS service accounts, federated identities, and cross-account access all rely on temporary credentials.
Assume-role flow
User / service / workload ↓ Trusted to assume role ↓ AWS STS issues temporary credentials ↓ Temporary credentials call AWS APIs ↓ Credentials expire automatically
Federation and IAM Roles Anywhere
AWS highlights identity federation as a major IAM feature. IAM supports federation from external identity providers, and IAM Roles Anywhere extends IAM role usage to workloads running outside AWS by using X.509 certificates from your PKI. :contentReference[oaicite:4]{index=4}
Workforce federation
Let enterprise users sign in through existing identity providers instead of creating many standalone IAM users.
Hybrid and on-prem access
IAM Roles Anywhere gives workloads outside AWS temporary AWS credentials via certificates. :contentReference[oaicite:5]{index=5}
Outbound federation
AWS now supports outbound identity federation using JWTs so AWS workloads can securely authenticate to external services without long-term secrets. :contentReference[oaicite:6]{index=6}
MFA and least privilege
AWS best practices for IAM emphasize least privilege and MFA. AWS explicitly recommends using MFA for an extra layer of protection and using IAM carefully so only the required actions are granted. :contentReference[oaicite:7]{index=7}
MFA
Add MFA for privileged identities, especially the root user and administrative roles.
Least privilege
Grant only the actions required, on only the resources required, under only the required conditions.
Short-lived creds
Favor temporary credentials instead of static access keys where possible.
Review and refine
Least privilege is not a one-time setup; AWS describes it as a continuous cycle. :contentReference[oaicite:8]{index=8}
IAM Access Analyzer
AWS describes IAM Access Analyzer as a way to streamline permissions management as you set, verify, and refine permissions. It is a key service for finding overly broad or unintended access and for moving closer to least privilege. :contentReference[oaicite:9]{index=9}
Why it matters
IAM policies become complex quickly, and Analyzer helps identify overly permissive access patterns that are difficult to spot manually.
Where it helps most
Cross-account access, public access, shared resources, and large environments with many policies and roles.
Permission boundaries, guardrails, and SCPs
Advanced IAM design is not only about what a role can do, but also about which outer guardrails prevent permission escalation or unsafe actions. AWS highlights permissions guardrails in IAM features, and AWS Organizations now supports full IAM policy language for SCPs, making SCPs more expressive than before. :contentReference[oaicite:10]{index=10}
| Control | Main purpose |
|---|---|
| Identity policy | Grants or denies permissions for a user, group, or role |
| Permission boundary | Sets a maximum permission boundary for an IAM principal |
| SCP | Defines organization-level guardrails on what accounts can do |
| Resource policy | Controls access directly on the resource side |
Recent IAM updates worth knowing
IAM continues to evolve. AWS announced outbound identity federation using JWTs in November 2025, enabling AWS workloads to securely authenticate to external services without long-term secrets. AWS also announced IAM Policy Autopilot to help generate IAM policies from code, and later made it available as a Kiro power for agentic AI development. AWS additionally introduced a dual-stack IAM endpoint for IPv4 and IPv6 environments. :contentReference[oaicite:11]{index=11}
Outbound federation
Extends IAM into external-service authentication workflows using JWTs. :contentReference[oaicite:12]{index=12}
Policy Autopilot
Helps builders generate baseline IAM policies from code faster. :contentReference[oaicite:13]{index=13}
Dual-stack endpoint
Supports IAM access over IPv4, IPv6, or dual-stack clients. :contentReference[oaicite:14]{index=14}
Architecture diagram
This diagram follows the real IAM control-plane model rather than a vague login picture.
DevSecOps workflows
IAM is foundational to DevSecOps because deployment pipelines, build agents, runtime workloads, and human operators all need secure and minimal access. Weak IAM design can undermine otherwise strong infrastructure.
CI/CD roles
Use dedicated roles for build and deploy stages instead of sharing static keys broadly.
Workload roles
Use instance profiles, Lambda execution roles, and service roles for runtime access.
Cross-account access
Use trust policies and role assumption for multi-account platform operations.
Permission review
Use Access Analyzer and continuous review to refine toward least privilege.
Practical DevSecOps flow
Engineer or pipeline needs AWS access ↓ Authenticate through IdP / console / CLI / workload identity ↓ Assume IAM role ↓ Receive temporary STS credentials ↓ Call AWS services with least-privilege permissions ↓ Audit through logs and refine with Access Analyzer
Best practices
Protect the root user
Use the root identity sparingly and secure it strongly with MFA. :contentReference[oaicite:15]{index=15}
Prefer roles over long-term keys
Use temporary credentials for users, workloads, and services whenever possible. :contentReference[oaicite:16]{index=16}
Continuously refine permissions
Least privilege is an ongoing cycle, not a one-time project. :contentReference[oaicite:17]{index=17}
Use MFA broadly
AWS explicitly recommends MFA as an extra layer of protection. :contentReference[oaicite:18]{index=18}
Use guardrails
Combine IAM permissions with permission boundaries, SCPs, and analyzer-based review.
Audit and verify
Pair IAM design with logging, review, and analyzer workflows instead of trusting static assumptions forever.