IAM controls who is allowed to access your AWS account and what they are allowed to do. It is the security gatekeeper for everything in AWS.
| Concept | What it is | Example |
|---|---|---|
| User | A person or application with a name and credentials | Alice the developer |
| Group | A collection of users sharing the same permissions | Developers group |
| Role | Temporary credentials for services or cross-account access | EC2 role to access S3 |
| Policy | A JSON document defining Allow or Deny rules | Allow s3:GetObject on my-bucket |
| Root Account | The master account — NEVER use for daily tasks | Enable MFA and lock away |
Always give the MINIMUM permissions needed. Never give AdministratorAccess unless absolutely required. This limits damage if credentials are stolen.
# Bad: Give admin access to a Lambda function
# {
# "Effect": "Allow",
# "Action": "*",
# "Resource": "*"
# }
# Good: Only what the Lambda actually needs
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"dynamodb:PutItem"
],
"Resource": [
"arn:aws:s3:::my-bucket/*",
"arn:aws:dynamodb:us-east-1:123456:table/orders"
]
}
| Method | Use For | Security Level |
|---|---|---|
| IAM Role | EC2, Lambda, ECS — any AWS service | BEST — auto-rotating temporary credentials |
| Access Keys | CLI, CI/CD pipelines (if no OIDC) | OK — rotate regularly, never commit to Git |
| Root Account Keys | NEVER | NEVER create or use these |