IAM

AWS Identity and Access Management is the authorization engine for AWS. Every other identity mechanism — Amazon Cognito, IAM Identity Center, federation from a corporate directory — ends by handing the caller an IAM role, so this is where a permission question is ultimately answered.

Two sentences carry most of the practical weight:

Use AWS IAM Identity Center (formerly AWS SSO) for workforce access and Amazon Cognito for application end users. Neither replaces IAM; both resolve to it.

Resource-based policies control access to a resource; roles control access from a workload to other services. When access is denied, that distinction usually says which policy to look at.

flowchart TB subgraph IAM["AWS IAM"] direction TB subgraph Principals["Principals"] Users["IAM users<br/>long-term credentials"] Roles["IAM roles<br/>temporary credentials"] end subgraph Groups["IAM groups"] AdminGroup["Admins"] DevGroup["Developers"] ReadGroup["Read-only"] end subgraph Policies["IAM policies"] ManagedPol["AWS managed policies"] CustomPol["Customer managed policies"] InlinePol["Inline policies"] end Users -->|belongs to| Groups Users -->|can assume| Roles Groups -->|attached| ManagedPol Groups -->|attached| CustomPol Groups -->|embedded| InlinePol Roles -->|trust policy| TrustRel["Trust relationship<br/>who may assume the role"] Roles -->|permission policy| ManagedPol Roles -->|permission policy| CustomPol EC2["EC2 instances"] -->|instance profile| Roles Lambda["Lambda functions"] -->|execution role| Roles FedUsers["Federated users"] -->|assume with SAML or OIDC| Roles end

Identity types

1. IAM users — individual identities within an account, with long-term credentials (console password, access keys). Suitable only where federation genuinely is not possible.
2. IAM groups — collections of users, used to manage permissions for several people at once. A user can belong to several groups and inherits the permissions of all of them. Groups are not principals: nothing assumes a group and a group cannot be named in a policy as a principal.
3. IAM roles — identities with permissions but no long-term credentials, assumed by users, applications or AWS services. Credentials are issued per session by AWS STS and expire, so there is nothing to rotate.
4. Federated users — identities managed outside AWS, in a corporate directory or a social provider, granted temporary access through SAML 2.0 or OIDC federation.
5. Root user — created with the account, holds unrestricted access, and cannot be constrained by an SCP in the management account. Secure it with MFA, remove its access keys, and use it only for the handful of tasks that require it.
6. Service-linked roles — predefined roles that an AWS service uses to act on your behalf. They cannot be restricted by service control policies.

Groups

Create groups by function, attach policies to the group, and add users to it. Permissions flow to the members automatically, and removing someone from the group removes the access — which is what makes joiner/leaver handling tractable.

Roles

Roles are the preferred mechanism from a security standpoint, and the reasons are practical rather than doctrinal:

• No credentials are hard-coded — no access key ID or secret access key in code, configuration or an environment variable
• A policy attached to a role takes effect immediately when it is updated
• Roles can be attached to and detached from running EC2 instances without stopping or replacing them
• Every assumption is recorded in CloudTrail, so there is an audit trail of who acted as what

A role carries two policies with different jobs: a trust policy naming who may assume it, and one or more permission policies defining what it may do. See Identity, permission, trust and resource policies.

Roles for EC2

An EC2 instance receives credentials through an instance profile — a container for a single role that is attached to the instance.

• Credentials are delivered to the instance metadata service and rotated automatically; the SDK picks them up without configuration
• Nothing is stored on the instance, so an image or a snapshot carries no secret
• Attaching or replacing the profile changes the instance’s permissions with no restart
• New instances launched from the same launch template inherit the profile automatically

Two things that are not possible, and are regularly attempted: an IAM policy cannot be attached directly to an EC2 instance — policies attach to users, groups and roles — and an IAM group cannot be attached to an instance, because groups organise users and nothing else. See EC2 instance profiles and trust policies.

Federating a corporate directory

To let employees use their existing corporate credentials:

1. Set up an identity provider in the corporate environment — Active Directory Federation Services, Microsoft Entra ID, Okta or another SAML 2.0 provider.
2. Register that provider with AWS: create a SAML identity provider in IAM and upload the provider’s metadata document.
3. Create IAM roles that correspond to the corporate groups.
4. Configure the provider to send SAML assertions to AWS with the claims those roles expect.
5. For anything beyond a single account, use AWS IAM Identity Center rather than per-account SAML providers: it centralises the mapping, issues short-lived credentials and gives one portal across every account.
6. Test that a member of each group reaches exactly the access intended, and no more.

See IAM Identity Center integration with Active Directory and AWS identity sources.

Identity mechanisms ranked

Ranked by the exposure each one creates, strongest first. The ordering reflects one criterion: how long a compromised credential remains useful, and how much it reaches.

1. IAM roles with AWS STS — temporary credentials, rotated automatically, scoped to a single purpose. Nothing long-lived exists to steal.
2. IAM instance profiles and service roles — the same model for EC2, Lambda, ECS tasks and other workloads. Credentials never touch the filesystem.
3. IAM Identity Center — workforce access through an external directory, with short-lived session credentials and central revocation.
4. Federation with an external identity provider — OIDC or SAML, exchanged for temporary credentials. Strength depends on the provider’s own controls.
5. IAM users with MFA — a long-term credential, but a stolen password alone is not enough.
6. IAM users with access keys — long-lived secrets that must be rotated by hand and are the most common cause of an AWS breach.
7. IAM users with console access only — long-lived, and exposed to phishing and password reuse without MFA.
8. The root user — unrestricted, unconstrained by SCPs in the management account, and the worst possible thing to lose. Protect it with hardware MFA and use it almost never.

The break in that list is between 4 and 5: everything above it issues credentials that expire on their own.