In a traditional office, physical presence naturally limits what a person can do — someone cannot delete a filing cabinet they cannot physically reach. In the cloud, every single action, no matter how destructive, is available to anyone from anywhere, the instant they know how to send the right request. Without some system standing guard, a single leaked password could allow a stranger halfway across the world to delete every server, every database, and every backup a company owns, in minutes. AWS IAM exists to make sure that never happens by accident, and to make it deliberately difficult for it to happen through malice either.

Formally, AWS IAM is a web service that helps securely control access to AWS resources by managing identities (who someone is) and permissions (what they are allowed to do), enforcing the answer to those questions on every single API request made to AWS.

It is worth spending real time on the distinction between a user and a role, since beginners very commonly confuse the two, and the difference matters enormously for security. A user is meant to represent a long-lived identity, something that logs in repeatedly over months or years, typically with its own persistent password or access keys. A role, by contrast, is not meant to be permanently “logged into” by anyone; instead, it is temporarily assumed by a trusted principal for a short window of time, after which the temporary credentials it grants automatically expire. This distinction is the foundation of a huge amount of good AWS security practice: wherever a role can be used instead of a long-lived user, the security exposure from a single leaked credential shrinks dramatically, since a leaked temporary credential naturally expires, while a leaked permanent one does not.

Another concept worth internalizing early is the difference between authentication and authorization, two words that sound similar but answer completely different questions. Authentication answers “who are you,” and is settled once, typically at login or when a role is assumed, by verifying a password, an access key, or a temporary security token. Authorization answers “are you allowed to do this specific thing,” and is checked fresh on every single subsequent request, regardless of how confidently the original authentication was proven. A person can be perfectly, confidently authenticated as themselves and still be correctly denied a specific action, because authentication only proves identity, while authorization separately governs what that identity is permitted to do.

flowchart TB
    subgraph Identities["Identities"]
        USER["IAM User"]
        GROUP["IAM Group"]
        ROLE["IAM Role"]
    end
    subgraph Policies["Permission Policies"]
        POL["JSON Policy Document"]
    end
    subgraph Resources["AWS Resources"]
        S3["S3 Bucket"]
        EC2["EC2 Instance"]
        DB["Database"]
    end

    USER -->|Member of| GROUP
    GROUP -->|Attached| POL
    USER -->|Attached directly| POL
    ROLE -->|Attached| POL
    USER -.->|Assumes| ROLE
    POL -->|Grants/denies access to| S3
    POL -->|Grants/denies access to| EC2
    POL -->|Grants/denies access to| DB
        

The diagram highlights a detail that trips up many beginners: a permission is never really “owned” by a resource. An S3 bucket does not decide who may read it; the policies attached to identities (and, in some cases, policies attached directly to the resource itself) decide that entirely. This is why two people can look at the exact same bucket and see completely different levels of access — the bucket itself has not changed at all, but each person’s identity carries a different set of attached permissions.

Every single request to AWS goes through the same evaluation logic before it is allowed or rejected, regardless of which service it targets.

This “explicit deny always wins” rule is not an accident; it is a deliberate safety design. It means an organization can safely add a single, centrally managed guardrail policy — for example, “never allow anyone to disable logging” — and trust that this single rule cannot accidentally be overridden later by some other, more permissive policy someone attaches elsewhere. Security teams rely heavily on this property to build layered defenses that remain effective even as many different individual teams manage their own day-to-day permissions.

It is also worth understanding the structure of the policy document itself, at least at a conceptual level, since it explains why the evaluation logic behaves the way it does. A policy is fundamentally a list of individual statements, and each statement specifies an effect (allow or deny), a set of actions (such as “read an object” or “delete a database”), and a set of resources those actions apply to. When IAM evaluates a request, it is really scanning through every applicable statement across every applicable policy, looking for any statement whose effect, action, and resource all genuinely match the request being made. This is why very small, seemingly unrelated wording differences in a policy — a wildcard included or omitted, a resource listed too broadly or too narrowly — can meaningfully change real-world behavior, even though the policy document as a whole might look almost identical to a slightly different version.

sequenceDiagram
    participant App as Application / User
    participant STS as AWS STS
    participant IAM as IAM Policy Engine
    participant Svc as AWS Service (e.g. S3)

    App->>STS: Assume role request
    STS-->>App: Temporary credentials (expiring)
    App->>Svc: API request with credentials
    Svc->>IAM: Evaluate policies for this request
    IAM-->>Svc: Allow or Deny decision
    Svc-->>App: Response (data or access denied)
        

An important detail in this flow is that the policy evaluation in step four happens on every single request, not just once when credentials are first issued. This means a permission change takes effect essentially immediately for future requests, even for a principal who is already holding valid, unexpired credentials — the credentials only prove identity, they do not lock in a fixed set of permissions that stays frozen for their entire lifetime.

Because policy evaluation happens on every request across every AWS service globally, IAM is engineered to answer allow-or-deny decisions with very low added latency, at a scale spanning millions of requests per second across all of AWS’s customers combined. From an individual account’s point of view, this means adding more users, more roles, or more granular policies does not meaningfully slow down request processing; the evaluation engine is designed to handle this volume as a baseline expectation, not as a special case.

Where scalability genuinely becomes a design concern is not performance, but manageability: as an organization grows from a handful of users to hundreds or thousands, individually managing policies per user quickly becomes unwieldy. This is precisely why groups, roles, and centrally managed policies exist — they are less about raw technical scalability and more about human, organizational scalability, letting a small security team confidently manage permissions for a much larger population of users and applications.

A related, often overlooked scalability question is how permissions scale across an entire organization made up of many separate AWS accounts rather than just one. Managing permissions individually inside dozens or hundreds of separate accounts, one account at a time, does not scale well at all as an organization grows. This is why larger organizations typically layer in organization-wide guardrails that apply automatically across every account at once, combined with roles that let a small number of trusted identities operate across many accounts as needed, rather than every person needing a separate identity duplicated inside every single account.

Because every AWS API call depends on IAM to authorize it, IAM itself is built as one of the most highly available services within AWS, since any disruption to it would ripple out and affect essentially everything else a customer tries to do. Identity and policy data is stored redundantly, and the evaluation engine operates across a globally resilient infrastructure so that authorization decisions remain available even during significant regional disruptions elsewhere.

It is worth separating the reliability of IAM’s decision-making engine from the reliability of an organization’s own policy design. IAM reliably enforcing whatever rules exist is guaranteed by AWS. Whether those rules actually reflect a sensible, well-thought-out security posture is entirely the customer’s own responsibility. A perfectly reliable system faithfully enforcing an accidentally overly permissive policy will faithfully, reliably allow exactly the mistake that policy contains — reliability of enforcement is not the same thing as correctness of the rules being enforced.

Least privilege deserves particular emphasis, because it is more a discipline than a single feature to switch on. In practice, it means starting every new role or user with essentially no permissions at all, then adding back only the specific actions that role genuinely needs to perform its job, rather than starting from a broad template and hoping nobody misuses the extra access left inside it. This approach requires more upfront thought than granting broad administrator access to everyone, but it means that if any single identity is ever compromised, the actual blast radius of that compromise is limited to only the narrow set of things that identity was ever allowed to touch in the first place.

Multi-factor authentication is worth understanding at a slightly deeper level as well. A password alone represents “something you know,” which can be guessed, phished, or leaked in a data breach elsewhere on the internet and then reused by an attacker. Multi-factor authentication adds “something you have,” such as a hardware security key or an authenticator app on a phone, meaning that even a fully correct, stolen password is not enough on its own to gain access. This single addition closes off the overwhelming majority of real-world account compromise attempts, which typically rely entirely on a password being known, and nothing more.

Permissions boundaries and service control policies both exist to solve a subtler problem than everyday least-privilege policy writing: preventing privilege escalation by administrators who are individually well-intentioned but collectively capable of accumulating too much power over time. Without a boundary in place, an administrator with permission to create new roles could, in principle, create a new role for themselves with far broader permissions than they were originally intended to have, effectively promoting their own access without anyone else’s explicit approval. A permissions boundary closes this gap by capping the maximum permissions any role or user they create can ever hold, regardless of how the underlying policy attached to that new identity is written, ensuring that delegated administrative convenience never quietly becomes unlimited administrative power.

AWS CloudTrail records every single API call made within an account, including exactly which identity made it, what action was requested, and whether it was allowed or denied, creating a complete, auditable history of activity across an entire AWS account. IAM Access Analyzer separately reviews existing policies and proactively flags access that may be broader than intended, such as a resource unintentionally left accessible from outside the organization.

These two tools answer genuinely different questions and are most powerful when used together. CloudTrail answers “what actually happened,” providing a factual, after-the-fact record useful for investigating an incident or satisfying an audit request. Access Analyzer answers a forward-looking question instead: “what could theoretically go wrong given the permissions currently configured,” surfacing risky configurations before they are ever actually exploited. A mature security practice reviews Access Analyzer findings proactively on a regular cadence, rather than only turning to CloudTrail reactively after something has already gone wrong.

CloudTrail’s value multiplies considerably once its logs are actually reviewed rather than simply collected and left sitting untouched. A very common, effective habit among security-conscious teams is watching specifically for unusual patterns rather than every individual log entry: an identity suddenly calling actions it has never called before, requests originating from an unfamiliar geographic location, or a spike in denied requests suggesting either a misconfigured application or an active attempt to probe for accessible permissions. None of these patterns are visible from a single log line in isolation; they only become meaningful once logs are aggregated and reviewed over a meaningful window of time, which is precisely why routing CloudTrail data into a dedicated log analysis or alerting system is considered a foundational security practice rather than an optional extra.