We arrive at one of the most important services in the entire cloud: IAM. It controls who can do what in your AWS account. If the VPC was your network security, IAM is the security of your identities and permissions. Mastering its four basic concepts—users, groups, roles, and policies—is essential for working securely with AWS.

IAM stands for Identity and Access Management. It is the service that manages:

• Who can access your AWS account (identities).
• What each one can do (permissions).

Two important facts to start with:

• IAM is free.
• IAM is global: it does not belong to a specific region; your users and permissions are valid throughout your account.

General analogy: IAM is the security system and access cards of an office building. It decides who has a card, which floors each person can enter, and which doors they can open. Without properly configured IAM, either no one can work, or anyone can go anywhere (dangerous).

An IAM user represents a specific person (or sometimes an application) that needs to access AWS. It has its own credentials:

• Username and password to log in to the web console.
• Access keys to use the command line or program against AWS.

Analogy: An IAM user is like an employee's ID card. It is individual and non-transferable: each employee has their own.

Best practice: each person should have their own user. Never share a user among several people, because then you wouldn't know who did what (traceability is lost).

A group is a set of users who share the same permissions. Instead of giving permissions one by one to each person, you give them to the group and add people to it.

Analogy: A group is like a department. Instead of giving keys to each person in the accounting department separately, you decide "everyone in accounting can enter the finance room" and then add or remove people from the department.

Example: You create a Developers group with permissions to manage test servers. When a new developer joins, you add them to the group and they inherit all permissions automatically. When they leave, you remove them and they lose access. Much easier than managing permissions person by person.

Groups do not have their own credentials; they only group users. And a user can be in several groups at once.

A role is an identity with permissions, but without fixed credentials: it does not belong to a specific person, but is assumed temporarily when needed. It can be assumed by people but, above all, by services and applications.

Analogy: A role is like an "authorized visitor" vest or a uniform that you put on temporarily to do a task. While you wear it, you have certain permissions; when you finish, you take it off. It is not yours: you use it while you need it.

This is probably the concept that is hardest at first, but it is the most important for security. Its typical use:

Key example: You have an EC2 instance that needs to read files from an S3 bucket. How do you give it permission? Bad idea: put access keys inside the server (if someone compromises it, they steal the keys). Good idea: assign a role to the EC2 instance. The instance "assumes" the role and obtains temporary permissions to read S3, without any key stored anywhere. AWS rotates those credentials automatically.

Roles are the foundation of modern security in AWS. We will see them in more detail in subchapter 7.4 (temporary credentials) and they are featured in many later chapters.

A policy is a document (in JSON format) that defines exactly what is allowed or denied. Policies are what actually contain the permissions; users, groups, and roles simply have policies attached.

Analogy: A policy is the detailed list of permissions written on paper: "can open doors A and B, but not C; can read archive documents, but not modify them."

A policy answers four questions:

• Effect: allow or deny?
• Action: what action? (read a bucket, launch an instance…)
• Resource: on which resource?
• (Optional) Condition: under what conditions?

We will see policies in detail in subchapter 7.3.

• Policies contain the permissions.
• They are attached to users (people), groups (sets of users), or roles (temporary identities).
• Groups make it easier to manage permissions for many people at once.
• Roles give temporary permissions without fixed credentials (ideal for services).

When you create an AWS account, you get the root user (the email you registered with). This user has absolute power over everything, including billing. It is so powerful that it is dangerous to use it daily.

Golden rule: Do not use the root user except for the very few tasks that require it. Create a normal IAM user (with administrator permissions if needed) for your daily work, and protect the root with MFA (subchapter 7.4). We will see this more in subchapter 7.5.

• IAM controls who can do what in your account. It is free and global.
• User: an identity for a person or app (with its credentials). One per person, never shared.
• Group: set of users who share permissions. Makes management easier.
• Role: identity with temporary permissions that is assumed (ideal for services like EC2, avoids storing keys).
• Policy: JSON document that defines permissions and is attached to users, groups, or roles.
• Do not use the root user for daily work.

In the next subchapter we will see the most important principle in all of cloud security: least privilege.