AWS Architecture Guide

Identity and Access with IAM

What This Chapter Is About

Explain AWS identity and access as a design of principals, permissions, trust, and operational safety rather than as a list of IAM features.

Keep one durable idea in view:

IAM design is how AWS turns access requests into controlled, reviewable trust decisions.

Sections

  1. IAM Mental Model

  2. Principals, Policies, and Policy Evaluation

  3. Roles, Trust, and Temporary Credentials

  4. Resource Policies, Permission Boundaries, and Cross-Account Access

  5. Multi-Account IAM Operating Model Scenario

How the Chapter Develops

The chapter develops in this order:

  1. Start with IAM as a system for deciding who can act, under what conditions, and with which blast radius.

  2. Explain principals, policies, and policy evaluation so the reader can reason about effective permissions.

  3. Show why AWS prefers roles and temporary credentials over long-lived credentials for both humans and workloads.

  4. Extend the model to resource policies, permission boundaries, and cross-account access patterns.

  5. Apply the design to a multi-account company that needs safe developer, platform, pipeline, and application access.

Together, these sections show that IAM is about trust design and operational safety, not a catalog of identity objects.

What You Will Be Able to Do

By the end of this chapter, the reader should be able to:

  • Explain how AWS evaluates identity and access requests at a practical level.

  • Distinguish IAM users, roles, identity-based policies, resource-based policies, trust policies, and permission boundaries.

  • Explain why temporary credentials and role assumption are central to modern AWS access design.

  • Describe how cross-account access works without defaulting to long-lived access keys.

  • Defend a practical IAM operating model for a multi-account AWS environment.

Key Ideas

  • IAM is about principals, permissions, trust relationships, and safe operational patterns.

  • The important design question is effective permission, not the number of policies created.

  • Roles and temporary credentials reduce long-lived secret risk and improve auditability.

  • Resource policies, SCPs, and permission boundaries work at different control layers and should not be conflated.

  • Good IAM design makes access understandable, reviewable, and revocable.