AWS Identity and Access Management

IAM

You need to control who or what is authorized to access and perform actions on your cloud resources.

Reach for it when

Configuring granular permissions for developers and deployment pipelines to access AWS resources.
Granting temporary credentials to application containers running on EC2, ECS, or Lambda.
Enforcing multi-factor authentication and IP restrictions on user logins to the console.

Managing application user registration, login, and profile storage — use Cognito instead.
Implementing database-level user permissions and query authorizations — use database-native grant systems instead.
Configuring fine-grained authorization policies within custom APIs — implement custom Auth0 or Cognito authorizers instead.

Service	Pick it instead when
Cognito	Choose it when you need to authenticate and authorize end users of a consumer-facing web or mobile application.
SSO (IAM Identity Center)	Choose it when managing workforce access across multiple AWS accounts from a central identity provider.

The model: Free to use as it is a core control plane service.
The line item that surprises people: No direct cost, but storing too many custom policy versions can hit limit errors that block deployments.

An explicit deny in any policy (resource, identity, or boundary) always overrides an allow, causing access denials; inspect the matching policy and request rather than adding more allows.
Prefer federation and temporary role credentials for human and workload access. For IAM users used in this lesson, group-based policies reduce repeated permission management.
The 2048-character limit on user policy size and 10240-character limit on roles can break automated deployment pipelines.

This page is a concept reference. Cost models are qualitative; confirm the current offering, Region and pricing before deploying.