IAM

IAM is the security foundation of every AWS account. Before any piece of code, any user, or any AWS service can do anything in your account — create a server, read a file, send a message — IAM decides whether that action is allowed.

Think of IAM as the bouncer and key system for your entire AWS environment. It answers three questions for every action: Who are you? (authentication), What are you allowed to do? (authorization), and On which resources?

Why IAM Exists

Without IAM, you'd have two bad options: give everyone unrestricted access to everything, or give no one access to anything. Neither works in practice. Real applications have different components that need different levels of access — a web server needs to read from S3 but not delete databases, a CI/CD pipeline needs to deploy code but not modify billing, a data analyst needs to query but not write. IAM lets you express exactly these distinctions.

Core Concepts

Users represent a specific person or application. They have long-term credentials (a password or access keys). In practice you should avoid users for applications — they're mainly for human access.

Groups are collections of users. You attach permissions to the group, and every user in the group inherits those permissions. This is how you manage permissions at scale: instead of updating every user individually, you update the group.

Roles are the most important IAM concept. A role is a temporary identity that anything can assume — an EC2 server, a Lambda function, a user from another AWS account, or even a human. Roles issue short-lived credentials automatically, so there are no long-term secrets to leak or rotate.

Policies are JSON documents that list what actions are allowed or denied on which resources. A policy attached to a role or user defines that identity's permissions.

How It All Fits Together

When a Lambda function needs to write to DynamoDB, you create a role with a policy that allows dynamodb:PutItem, then tell Lambda to run as that role. Lambda automatically receives temporary credentials — no passwords, no access keys stored in code. When the function calls DynamoDB, IAM checks the role's policy and allows the write. The function never knows the credentials; IAM handles everything behind the scenes.

This pattern — roles instead of long-term credentials — is the single most important IAM best practice, and it applies everywhere: EC2, ECS, CodeBuild, and even on-premises servers via IAM Roles Anywhere.