What is AWS IAM? A plain-English explainer
AWS IAM, short for Identity and Access Management, is AWS’s service for controlling who — and what — can do things inside your AWS account. It is where you create users, organise them into groups, define roles, and attach policies that spell out exactly which actions on which resources are allowed. IAM is not a single feature bolted onto AWS; it is the access-control layer that every other service checks before doing anything on your behalf. Getting it right, following the principle of least privilege, is widely considered the single most important security habit in AWS. Here is what IAM covers, how it fits into AWS security overall, and how it differs from a service with a deceptively similar-sounding job — Amazon Cognito.
The general idea: identity and access management
Identity and access management, as a concept, is about answering two questions for every request: who is making it, and are they allowed to do this? Our what-is-identity-and-access-management explainer covers that idea in general terms. AWS IAM is AWS’s own implementation of it, scoped specifically to controlling access within your AWS account — it is the service, not the general concept.
The core pieces: users, groups, roles and policies
IAM is built from a small set of building blocks that combine to control access:
- Users — an identity for a specific person or workload that needs long-term access to your AWS account.
- Groups — a way to collect users together so you can manage their permissions once, as a set, instead of one by one.
- Roles — an identity that anything (a user, an application, an AWS service) can temporarily assume to gain a defined set of permissions, without needing its own permanent credentials.
- Policies — documents that state, explicitly, what actions are allowed or denied on which resources; policies are attached to users, groups or roles to actually grant permissions.
Least privilege, and locking down the root user
The guiding principle behind good IAM practice is least privilege: give every user, role and application only the permissions it actually needs to do its job, and nothing more. A broad, convenient policy is also a broad attack surface — if those credentials are ever compromised, the damage is limited to whatever that identity could actually do.
One IAM habit is treated as especially important: protecting the account’s root user, the identity created when the AWS account itself was set up, which has unrestricted access to everything. Best practice is to avoid using the root user for day-to-day work, enable multi-factor authentication (MFA) on it, and instead create ordinary IAM users or roles with only the permissions each task requires.
Why IAM is the foundation of AWS security
Under the AWS shared-responsibility model, AWS secures the underlying cloud infrastructure, but the customer is responsible for security in the cloud — and access control is squarely the customer’s job. AWS cannot decide who inside your organisation should be able to delete a database or read a storage bucket; only your IAM configuration can. That is why IAM sits underneath almost every other AWS security topic rather than beside it.
IAM also supports roles and temporary security credentials as an alternative to long-lived access keys. Conceptually, a role grants short-lived credentials that expire automatically, which limits how much damage a leaked credential can do compared with a permanent key that keeps working until someone remembers to revoke it.
IAM vs Amazon Cognito — a distinction worth getting right
A common point of confusion: IAM and Amazon Cognito both deal with “identity”, but they manage entirely different populations. AWS IAM controls who can administer your AWS account and its resources — the people and systems running your infrastructure. Amazon Cognito, covered in our what-is-amazon-cognito explainer, manages sign-up, sign-in and access for your application’s end-users — the customers using the thing you built, who should never need an AWS account of their own.
Mixing the two up is a real mistake to avoid: giving an application’s end-users IAM identities to sign into your AWS account would be both the wrong tool and a serious security risk.
Where IAM appears in certification study
IAM is tested across virtually every AWS certification, because access control underpins almost every other service and scenario. AWS Cloud Practitioner introduces the concepts at a foundational level; Solutions Architect Associate expects you to design access patterns using users, groups, roles and policies; and Security Specialty goes deepest of all, treating IAM as central, load-bearing content rather than one topic among many.
This article covers what IAM is and why it matters — the syllabus detail on policy structure, permission boundaries and specific exam scenarios belongs in the exam guide itself, which our /revision study library breaks down lesson by lesson.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.