AWS IAM

As more teammates and automation touch AWS, reusing the same access keys everywhere makes it hard to trace who did what when something goes wrong. If you cannot narrow permissions to exactly what each service needs, one small script can expand into account-wide risk.

Early on, sharing root accounts or static keys across teams was common, but this approach made tracking and revoking access difficult after incidents. This is why IAM, centered on role-based access control and temporary credentials, became the default security model.

IAM combines users, groups, roles, and policies to define permissions. People receive console and CLI access, while services assume roles to access other AWS resources with temporary credentials. In multi-account setups, IAM Identity Center can centrally manage access across accounts.

IAM and Cognito both look like authentication, but they serve different audiences. IAM handles permissions for people and services within an AWS account, while Cognito handles login and token issuance for application end users. If the problem is console, CLI, or service-role access, look at IAM; if the problem is sign-up and login for app users, look at Cognito.

Well-suited for separating team permissions, controlling service-to-service calls, assigning deployment pipeline access, designing least-privilege policies, and governing multi-account AWS access. It is not the layer that directly provides end-user sign-in flows or manages encryption keys themselves.