Mirco Cloud Primer
Picture an office building where every employee carries a keycard. The receptionist's card opens the lobby and the mailroom, the accountant's card also opens the finance office, and only a handful of cards open the server room in the basement. Nobody hands out a master key just to save time, because a lost master key is a disaster, while a lost receptionist's card is a minor inconvenience. Identity and Access Management, usually shortened to IAM, is the cloud version of that keycard system: a set of tools and rules that decide who someone is and exactly which doors they are allowed to open.
For beginners, IAM can feel like an abstract piece of paperwork that gets in the way of getting things done. In practice, it is one of the most important ideas in cloud computing, because almost everything else — your data, your applications, your bills — sits behind whatever access rules you set up on day one.
What IAM actually controls
IAM is built around two separate questions that are easy to confuse. The first question is authentication: are you really who you say you are? This is usually answered with a password, and increasingly with a second proof such as a one-time code, a topic covered in more detail in our guide to multi-factor authentication. The second question is authorization: now that we know who you are, what are you allowed to do? Authorization is where the keycard analogy really shines, because two authenticated people can still have completely different levels of access.
Identities are not just people
In a cloud environment, an "identity" is not limited to a human being logging in from a laptop. A piece of software, an automated script, or one cloud service calling another service also needs an identity, because the system still has to decide what that script or service is allowed to touch. Beginners are sometimes surprised to learn that most of the identities inside a mature cloud account belong to machines and automated processes rather than people, which is exactly why IAM needs to be a deliberate system rather than an afterthought.
Groups, roles, and policies
Assigning permissions one person at a time quickly becomes unmanageable, so IAM systems usually let you organize access around roles or groups instead. A "billing viewer" role might be allowed to see invoices but not change anything, while an "administrator" role can change almost everything. Instead of editing each person's permissions individually, you place people into the role that matches their job, and the role carries the actual rules. This mirrors the office building, where new hires in the finance department are simply issued the finance keycard profile rather than having someone redesign the lock system for each new employee.
Why the principle of least privilege matters here
IAM works best when it is paired with a simple habit: give each identity the smallest set of permissions it needs to do its job, and nothing more. This idea has a name of its own, which we explore fully in our article on the principle of least privilege. Without that discipline, IAM still exists as a system, but it stops doing its job, because everyone ends up holding a master key "just in case," which defeats the entire point of having separate keycards.
A simple comparison of access levels
| Access level | Typical use | Risk if overused |
|---|---|---|
| Read-only viewer | Checking reports, dashboards, or status | Low — cannot change anything |
| Standard contributor | Day-to-day work within one project or service | Moderate — mistakes stay contained to that area |
| Administrator / owner | Setting up accounts, changing core settings | High — a mistake or stolen credential can affect everything |
Common mistakes beginners make
- Using one login for everything. Sharing a single administrator identity among several people or scripts makes it impossible to know who actually did what.
- Granting broad access "just to be safe." It feels convenient in the moment, but it quietly increases how much can go wrong from a single mistake or stolen password.
- Never reviewing who still has access. People change roles or leave projects, and old permissions are often simply forgotten rather than removed.
- Treating automated scripts as an afterthought. A script with excessive permissions is just as risky as a person with excessive permissions, even though nobody is typing at a keyboard.
How IAM fits into the bigger picture
IAM does not exist in isolation. It is one half of the shared responsibility model that defines cloud security: providers build strong identity tools, but configuring and maintaining sensible access rules inside your own account is squarely your job. Getting comfortable with IAM early, even for a small personal project, builds habits that scale naturally as a project — or a business — grows.
Frequently asked questions
Is IAM the same thing as a password?
No. A password is just one way of proving who you are. IAM is the whole system that decides who you are, what you are allowed to touch, and keeps a record of it — passwords, codes, and permission rules are all pieces of that larger system.
Do I need IAM if I'm the only person using my cloud account?
Yes. Even a single person benefits from IAM, because it separates your everyday login from a rarely used master login, and it limits damage if one password or device is ever compromised.
What is the difference between authentication and authorization?
Authentication proves who you are, usually with a password or a second code. Authorization decides what that confirmed identity is allowed to do once inside. IAM handles both halves together.
Does IAM cost extra money?
Setting up sensible identity and access rules is mostly a matter of configuration and habit, not a separate purchase. The real cost of skipping it shows up later, in the time it takes to clean up after a mistake.
Related reading
Sources
- NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations
- Documentation published by major public cloud providers (consulted October 2026)