SkarpSkarp

Chapter 7 of 20

AWS Identity and Access Management: Controlling Who Can Do What

Dive into the heart of AWS security by seeing how identities, permissions, and access boundaries are defined and enforced across your AWS accounts.

27 min readen

Where IAM Fits in AWS Security

IAM in the Big Picture

IAM is a core part of your side of the AWS shared responsibility model: you control who can do what with your AWS resources.

Global, Foundational Service

IAM is a global AWS service used by almost every other service. It governs access across Regions and accounts.

Three Core Questions

Every request is evaluated as: Who are you (identity)? What action do you want? On which resources?

Policies and Decisions

Policies are JSON documents that allow or explicitly deny actions. If not explicitly allowed, a request is implicitly denied.

Module Focus

You will learn IAM’s purpose, users/groups/roles, how to read simple policies, and how to apply least privilege.

Core IAM Building Blocks: Identities and Policies

Identities: The Who

IAM identities are users, groups, and roles. They represent who is making a request to AWS.

IAM Users

IAM users represent individual people or applications that need long-term credentials, like passwords or access keys.

IAM Groups

Groups are collections of IAM users. You attach permissions to the group so all members inherit them.

IAM Roles

Roles have no long-term credentials. They are assumed temporarily by users, apps, or AWS services to get permissions.

Policies: The Permissions

Policies are JSON documents attached to identities or resources that specify allowed or denied actions on resources.

Effective Permissions

A user’s final permissions come from all attached policies: user, group, role, and any resource-based policies.

IAM Users, Groups, and Roles: When to Use Which

When to Use IAM Users

IAM users are for individual humans (or legacy apps) that need direct console or API access with long-term credentials.

Best Practices for Users

Give each person their own IAM user if you are not using SSO. Do not share users; it breaks auditing and least privilege.

IAM Groups in Practice

Attach permissions to groups like Developers or Billing-ViewOnly, then add/remove users as their job roles change.

What IAM Groups Cannot Do

Groups cannot contain other groups, and roles cannot be group members. Groups are only collections of users.

IAM Roles: No Long-Term Credentials

Roles are assumed temporarily and are ideal for applications, cross-account access, and SSO-style access for people.

Common Exam Signal: Temporary or Cross-Account

If a question mentions temporary, rotating, or cross-account access, think IAM role, not IAM user.

Real-World Scenarios: Choosing Users, Groups, or Roles

Scenario 1: New Developer

Alex joins your team and needs console access to manage dev EC2 instances. What IAM constructs should you use?

Solution: User + Group

Create IAM user alex.dev, put them in Developers-DevOnly group with EC2 dev permissions, and require MFA.

Scenario 2: EC2 to S3

A web app on EC2 must read objects from an S3 bucket. You do not want to hardcode keys on the server.

Solution: Role for EC2

Create an IAM role with s3:GetObject on the bucket and attach it as the instance profile for EC2.

Scenario 3: External Auditor

An external auditor needs read-only access for two weeks to review your AWS environment and logs.

Solution: Temporary Role

Create an Audit-ReadOnly role with ReadOnlyAccess and let the auditor assume it via their account or SSO.

Inside an IAM Policy: Actions, Resources, Effect, and Conditions

Policy Anatomy

Each IAM policy statement has Effect, Action, Resource, and optional Condition fields that define permissions.

Effect and Action

Effect is Allow or Deny. Action lists operations like s3:GetObject or ec2:StartInstances that are covered.

Resource

Resource specifies which AWS resources the actions apply to, often using ARNs like an S3 bucket or EC2 instance.

Conditions

Conditions add rules, such as requiring MFA or a specific IP range. They further narrow when access is granted.

Implicit vs Explicit Deny

Requests are denied unless explicitly allowed. Any explicit Deny in any policy always overrides Allows.

Identity vs Resource Policies

Identity-based policies attach to users, groups, or roles. Resource-based policies attach directly to resources.

Reading a Simple IAM Policy (Hands-On)

Study the policy below, then answer the reflection questions that follow (mentally or in notes). Focus on understanding, not memorizing JSON.

Principle of Least Privilege and Common Exam Traps

Least Privilege Defined

Principle of least privilege: give identities only the permissions they need to perform their tasks, and no more.

Scoping Permissions

Scope actions and resources narrowly: specific S3 buckets and needed actions, not wildcards like * for everything.

Using Conditions

Conditions help enforce least privilege by restricting access by IP, time, or requiring MFA for sensitive operations.

Root User Trap

The root user should be used only for rare account-level tasks, protected by MFA, and never for daily operations.

Roles vs Access Keys

For applications, prefer IAM roles with temporary credentials over long-term access keys stored in code or servers.

Choosing Best Answers

On exams, pick answers that use roles for apps, groups for people, and narrowly scoped policies that follow least privilege.

Multi-Account IAM: AWS Organizations, SCPs, and Cross-Account Access

Why Multiple Accounts?

Organizations often use separate AWS accounts for dev, test, prod, and security to isolate workloads and risks.

AWS Organizations Basics

AWS Organizations groups accounts and OUs so you can manage billing, guardrails, and policies centrally.

What SCPs Do

Service control policies set maximum permissions for accounts. They limit what IAM policies can grant.

SCPs Do Not Grant Access

SCPs alone never grant permissions. An allow in an SCP only means IAM policies are allowed to grant that access.

Cross-Account Roles

Create roles in one account that trusted principals in another account can assume, instead of sharing access keys.

Exam Clues

Central governance across many accounts: think Organizations + SCPs. Cross-account access: think IAM roles.

Design Exercise: Apply Least Privilege

Work through this thought exercise. There is no single perfect answer, but some designs are clearly more secure and aligned with AWS best practices.

Scenario

Your company has:

  • A `prod` account with an S3 bucket `customer-data-prod`.
  • A `dev` account where developers experiment.

Requirements:

  1. Developers should read from `customer-data-prod` for testing, but not write or delete.
  2. Only a small security team in `prod` should have full control over the bucket.
  3. No one in `dev` should be able to accidentally gain write access to the `prod` bucket.

Your task

Design, at a conceptual level:

  • What IAM identities you would create (users, groups, roles) and in which accounts.
  • What kind of policies you would attach (high level, not full JSON).
  • Any use of AWS Organizations or SCPs.

Think it through

Pause and sketch your design in notes, then compare with the sample approach below.

Sample approach (for self-check)

  • In `prod`:
  • Create an S3 bucket policy that allows read-only access to a cross-account role assumed by developers from `dev`.
  • Create a `Security-Team` IAM group with a policy that allows full S3 access to `customer-data-prod`.
  • In `dev`:
  • Create a role `Dev-ReadCustomerData` that developers can assume, which in turn assumes the cross-account role in `prod` (or is trusted by it).
  • In AWS Organizations:
  • Apply an SCP to the `dev` account that denies S3 write actions (`PutObject`, `DeleteObject`) on the `customer-data-prod` bucket ARN to guard against misconfigurations.

Notice how this uses roles, groups, bucket policies, and SCPs together to enforce least privilege.

Quick Check: Identities and Policies

Test your understanding of IAM users, groups, roles, and policies.

A data analytics team runs a scheduled ETL job on an EC2 instance that must read from and write to an S3 bucket. You want to avoid managing access keys. What is the MOST appropriate way to grant this access?

  1. Create an IAM user with access keys, store the keys on the EC2 instance, and attach an S3 access policy directly to the user.
  2. Create an IAM role with a policy allowing S3 read/write on the bucket, attach the role to the EC2 instance, and let the job use the instance role credentials.
  3. Attach the AmazonS3FullAccess managed policy directly to the S3 bucket so any EC2 instance can access it.
  4. Add the EC2 instance to an IAM group that has S3 permissions, so the instance inherits the group’s policies.
Show Answer

Answer: B) Create an IAM role with a policy allowing S3 read/write on the bucket, attach the role to the EC2 instance, and let the job use the instance role credentials.

The best answer is to use an IAM role attached to the EC2 instance. The instance role provides temporary credentials without managing access keys and can be scoped to the specific S3 bucket. IAM users with stored keys (A) are less secure, S3 bucket policies alone (C) do not identify the EC2 instance, and EC2 instances cannot be members of IAM groups (D).

Quick Check: Least Privilege and Organizations

Another short question to reinforce SCPs and least privilege.

Your company uses AWS Organizations with separate accounts for dev and prod. You want to ensure that no identity in any prod account can create IAM users, even if an administrator in that account tries to allow it. What should you use?

  1. Attach a customer-managed IAM policy with `Effect: Deny` for `iam:CreateUser` to all IAM users in prod accounts.
  2. Use a service control policy (SCP) attached to the prod organizational unit that denies `iam:CreateUser`.
  3. Enable MFA on the root user in each prod account, so IAM users cannot create other IAM users.
  4. Create an S3 bucket policy in each prod account that denies `iam:CreateUser` for all principals.
Show Answer

Answer: B) Use a service control policy (SCP) attached to the prod organizational unit that denies `iam:CreateUser`.

An SCP attached to the prod OU that denies `iam:CreateUser` sets a hard guardrail: no IAM policy in those accounts can grant that permission. Option A can be bypassed by admins creating new users without the deny. MFA on root (C) is good practice but does not enforce this restriction. S3 bucket policies (D) only affect S3 access, not IAM actions.

Key IAM Terms Review

Flip through these flashcards to reinforce core IAM concepts before moving on.

IAM user
An identity in AWS that represents a single person or application needing long-term credentials, such as a console password or access keys.
IAM group
A collection of IAM users. Permissions assigned to the group are inherited by all users in the group.
IAM role
An AWS identity with permissions that can be assumed by trusted entities. It does not have long-term credentials; instead, it provides temporary security credentials.
IAM policy
A JSON document that defines permissions. It specifies Effect (Allow or Deny), Actions, Resources, and optional Conditions.
Implicit deny
In IAM, any request that is not explicitly allowed by a matching policy is denied by default.
Explicit deny
A policy statement with Effect set to Deny. If it matches a request, it overrides any Allows and the request is denied.
Principle of least privilege
Give identities only the permissions they need to perform their tasks, and no more.
Service control policy (SCP)
A policy in AWS Organizations that sets the maximum permissions an account can have. It does not grant permissions by itself, but limits what IAM policies can grant.
Resource-based policy
A policy attached directly to an AWS resource (like an S3 bucket or SQS queue) that specifies who can access that resource and how.
AWS Organizations
A service that lets you centrally manage multiple AWS accounts, organize them into OUs, and apply policies such as SCPs across them.

Key Terms

IAM role
An AWS identity with permissions that can be assumed by trusted entities. It does not have long-term credentials; instead, it provides temporary security credentials.
IAM user
An identity in AWS that represents a single person or application needing long-term credentials, such as a console password or access keys.
IAM group
A collection of IAM users. Permissions assigned to the group are inherited by all users in the group.
IAM policy
A JSON document that defines permissions. It specifies Effect (Allow or Deny), Actions, Resources, and optional Conditions.
Explicit deny
A policy statement with Effect set to Deny. If it matches a request, it overrides any Allows and the request is denied.
Implicit deny
In IAM, any request that is not explicitly allowed by a matching policy is denied by default.
AWS Organizations
A service that lets you centrally manage multiple AWS accounts, organize them into organizational units (OUs), and apply policies such as SCPs across them.
Resource-based policy
A policy attached directly to an AWS resource (like an S3 bucket or SQS queue) that specifies who can access that resource and how.
Principle of least privilege
Give identities only the permissions they need to perform their tasks, and no more.
Service control policy (SCP)
A policy in AWS Organizations that sets the maximum permissions an account can have. It does not grant permissions by itself, but limits what IAM policies can grant.

Finished reading?

Test your understanding with a custom practice exam on this chapter.

Test yourself