If you take away one idea from the entire security chapter, let it be this: the principle of least privilege. It is the golden rule of cloud security (and all of computing). Understanding and applying it will save you from serious incidents and is what distinguishes a professional from a careless beginner.

The principle of least privilege says:

Give each user, service, or application ONLY the permissions they need to do their job, and not one more.

No extra permissions “for convenience,” nor more “just in case.” Exactly what’s needed, nothing extra.

Analogy: Imagine a hotel. You give the cleaning staff a card that opens the rooms, but not the safe or the manager’s office. The cook gets access to the kitchen, but not to the rooms. Each person has access only to what they need for their job. You don’t give everyone a master key “to simplify,” because that would be a huge risk.

The reason is simple: reduce the damage when something goes wrong. And something, sooner or later, will go wrong.

Imagine two scenarios with a user whose credentials are stolen by an attacker:

Least privilege limits the blast radius. If a credential is compromised (and it happens more than you think), the attacker can only do the little that identity could do.

Real example (common pattern): A developer accidentally uploads their access keys to a public GitHub repository. Automated bots detect them in seconds and use them. If those keys had administrator permissions, the attacker launches dozens of expensive servers to mine cryptocurrency and the victim receives a bill for thousands of euros. If the keys had minimum permissions (only read a bucket), the attacker can do almost nothing. Least privilege turns a disaster into a scare.

Applying least privilege is a mindset more than a button. Here are the guidelines:

In AWS, by default, everything is denied until you explicitly allow it. Take advantage of this: start from zero and add only the permissions that are proven necessary, instead of giving a lot and then taking away.

Don’t give permission over “all buckets” if only one is needed. Don’t give permission over “all actions” if only reading is needed.

Bad (too broad): “Can do anything with any S3 bucket.” Good (minimum): “Can read objects only from the informes-2026 bucket.”

Giving AdministratorAccess (full permission) is convenient but dangerous. Reserve it for the very few identities that truly need it. Most users and services need much less.

As we saw in subchapter 7.1, give each service (an EC2 instance, a Lambda function) a role with exactly the permissions it needs, no more.

Permissions tend to accumulate (“permission creep”). Review them periodically and remove what is no longer used. AWS has tools (IAM Access Analyzer, which we’ll see in subchapter 7.5) that tell you which permissions are granted but never used.

Let’s be honest: least privilege takes more work than giving broad permissions. It’s tempting to just hand out an AdministratorAccess and forget about it. But that shortcut is exactly the source of most serious security incidents.

Correct mindset: a bit of inconvenience now (setting up tight permissions) in exchange for avoiding a disaster later. Professionals accept that small friction as a normal part of a job well done.

A practical trick to find the balance: start with the permissions you think are needed, run the application, and if it fails due to lack of permissions, add exactly the one that’s missing. That way you reach the real minimum without going overboard.

This principle is not just for IAM; you’ve already seen it throughout the book:

• Security Groups (Chapter 4): open only the necessary ports.
• Private subnets (Chapter 6): don’t expose to the internet what doesn’t need it.
• S3 bucket policies (Chapter 5): give access only to those who should have it.

It’s a cross-cutting philosophy for all cloud security.

• Least privilege: give each identity only the permissions it needs, not one more.
• Its goal is to limit the damage if a credential is compromised (reduce the “blast radius”).
• In practice: start from zero, be specific with actions and resources, avoid administrator permissions, use roles for services, and review periodically.
• It takes a bit more work than giving broad permissions, but that small effort prevents disasters.
• It’s a cross-cutting philosophy: it also applies to networks, Security Groups, and S3 policies.

In the next subchapter, we’ll dive deeper into how permissions are written: identity-based vs resource-based policies.