AWS IAM: Core Components

Jul 19, 2026

AWS IAM core components

#aws #iam #cloud #security

AWS Identity and Access Management (IAM) is the service that controls who can do what inside your AWS account. Before diving into policies, roles, or advanced security features, it's essential to understand the core building blocks IAM is made of. Here's a breakdown of each one.

Users

A user represents a single person or application that needs to interact with AWS. Each user has a unique identity within your account and can be assigned long term credentials, such as a password for console access or access keys for programmatic access. Users are meant for individual, persistent identities, not for shared or temporary access.

Groups

A group is simply a collection of users. Instead of attaching permissions to each user individually, you attach a policy to a group, and every user in that group inherits those permissions. This makes managing permissions at scale much easier. A few things to keep in mind: groups cannot be nested inside other groups, and you cannot log in as a group. Groups exist purely to organize users and simplify permission management.

Roles

A role is a temporary identity that can be assumed by users, applications, or AWS services. Unlike users, roles do not have long term credentials attached to them. Instead, when a role is assumed, AWS issues temporary security credentials through the Security Token Service (STS).

Roles are the recommended way to grant access in most situations, especially for:

  • EC2 instances that need to call other AWS services
  • Lambda functions that need execution permissions
  • Cross account access between separate AWS accounts
  • Federated users logging in through an external identity provider

Because roles rely on temporary credentials rather than long lived keys, they reduce the risk of credentials being leaked or misused.

Policies

A policy is a JSON document that defines permissions. It specifies what actions are allowed or denied, on which resources, and under what conditions. Policies are the mechanism that actually grants or restricts access in IAM.

There are a few different ways policies can be applied:

Identity based policies are attached directly to users, groups, or roles. This is the most common way permissions are assigned.

Resource based policies are attached to the resource itself rather than to an identity. A good example is an S3 bucket policy or a KMS key policy. These policies can grant access to a different AWS account directly, without needing a role.

Managed policies are reusable and can be attached to multiple identities. They come in two flavors: AWS managed policies, which are created and maintained by AWS, and customer managed policies, which you create and control yourself.

Inline policies are embedded directly into a single user, group, or role. They have a strict one to one relationship with that identity and are not reusable. These are useful when you need a very specific, one off policy that should never be attached to anything else.

Putting It Together

At a high level, IAM works like this: users and roles are identities, groups organize users, and policies define what those identities are allowed to do. Roles add a layer of flexibility by allowing temporary access without the need for permanent credentials, which is why AWS recommends them over long term access keys wherever possible.

Understanding these five components, users, groups, roles, policies, and the different policy types, gives you the foundation needed to understand everything else in IAM, from permission boundaries to cross account access to federation.

Applying IAM at Scale: Traceability, Multi Account, Security Standards, and Automation

Once you move beyond a single account, IAM is rarely managed manually. At scale, organizations lean on a handful of practices and related AWS services to keep things auditable, secure, and consistent. Here's how the core goals of a mature IAM setup map to real implementation.

Traceability

Traceability means being able to answer who did what, when, and from where. This is achieved by:

  • Enabling AWS CloudTrail across all accounts and regions to log every IAM related API call
  • Using IAM Access Analyzer to detect unintended or overly broad access
  • Reviewing Credential Reports and IAM Access Advisor to see which credentials and permissions are actually being used
  • Tagging IAM roles and users so activity can be traced back to a specific team or project

Multiple AWS Accounts

IAM itself is scoped to a single account, so managing access across many accounts requires a different approach:

  • Use roles, not users, for cross account access. A trust policy on the role defines which account or principal is allowed to assume it
  • Adopt AWS Organizations to centrally manage many accounts under one umbrella
  • Use AWS IAM Identity Center (formerly AWS SSO) to give people federated access across all accounts from a single sign in, rather than creating individual IAM users in every account
  • Under the hood, cross account access relies on STS AssumeRole to grant temporary credentials in the target account

Enforce Security Standards

Consistent security standards across accounts come from guardrails set above the individual account level:

  • Service Control Policies (SCPs) set at the AWS Organizations level restrict what any account in an organizational unit can do, for example denying the ability to disable CloudTrail or leave approved regions
  • Permissions boundaries cap the maximum permissions a single role or user can have, even if an overly broad policy is attached to it
  • Require MFA through policy conditions for sensitive actions
  • Continuously check policies against internal standards using IAM Access Analyzer and AWS Config rules

Automation

At scale, IAM should be provisioned and reviewed automatically rather than configured by hand:

  • Manage IAM resources as code using CloudFormation or Terraform
  • Use AWS Control Tower to automate new account creation with baseline guardrails and roles already in place
  • Automate credential rotation and periodic access reviews using Lambda combined with IAM APIs
  • Let CI/CD pipelines assume roles through OIDC federation, for example GitHub Actions to AWS, instead of relying on long lived access keys

The Common Thread

At multi account scale, IAM is rarely managed account by account. Access is centralized through Organizations and Identity Center, guardrails are enforced through SCPs and permissions boundaries, provisioning is automated through Control Tower or infrastructure as code, and CloudTrail combined with Access Analyzer provides the audit trail that ties it all together.

Kaveesha Nethruwan