Overview
Cloud IAM controls who, and what, can do what, to which resources, across a cloud account. Every meaningful cloud security incident traces back to an identity having more access than it needed, so IAM isn't a one-time setup step but an ongoing discipline: grant the minimum permission required, prefer temporary credentials over long-lived ones, and continuously audit for drift as roles, services, and team membership change. The core mental model is the same across providers even though the exact terminology (roles, policies, service accounts) differs: identities get permissions through policies, and every request is checked against those policies before it's allowed to proceed.
Quick Reference
| Concept | What it is |
|---|---|
| Identity | A user, service account, or workload that can make requests |
| Policy | A document defining allowed/denied actions on resources |
| Role | An identity that policies attach to, assumable by users or workloads |
| Least privilege | Granting only the minimum permissions actually needed |
| Temporary credentials | Short-lived, auto-expiring access instead of permanent keys |
Syntax
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::my-app-uploads/*"
}
]
}Examples
# Assume a role for temporary, auto-expiring credentials instead
# of using a long-lived access key directly.
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/deploy-role \
--role-session-name ci-deployWildcard permissions are a standing liability
"Action": "*" or "Resource": "*" are easy to reach for during development and dangerous to leave in production; they grant far more than almost any real workload needs. Narrow them before shipping, not after an incident.
Visual Diagram
Common Mistakes
- Using long-lived static credentials (access keys) for workloads that could instead assume a temporary, auto-expiring role, a leaked static key is a standing liability until manually rotated.
- Granting broad or wildcard permissions during development and never narrowing them before production, because the narrower policy wasn't known yet and nobody circled back.
- Attaching permissions directly to individual users instead of to roles/groups, making access impossible to audit consistently as the team changes.
- Treating IAM as a one-time setup instead of an ongoing practice, permissions accumulate over time (drift toward more access) unless actively reviewed and pruned.
Performance
- IAM policy evaluation happens on every single request and is designed to be fast, but very large, deeply nested policy sets (thousands of statements) can measurably slow down evaluation and are also harder to audit correctly.
- Temporary credential issuance (assuming a role) adds a network round-trip compared to a static key, which is a negligible cost relative to the security benefit, but does mean credential-fetch logic needs to handle that latency and expiration/renewal correctly.
Best Practices
- Default to temporary, auto-expiring credentials (assumed roles) over long-lived static keys, everywhere the workflow allows it.
- Grant permissions to roles/groups, not individual users, so access can be audited and changed structurally rather than one person at a time.
- Start every new policy as narrow as possible and expand only when a real, specific need is hit, not the other way around.
- Schedule regular access reviews specifically looking for unused permissions and stale credentials, since drift toward over-permissioning is the default trajectory without active correction.