Enterprise Identity, Federation, and Workload Access
What This Chapter Is About
Extend core IAM concepts into enterprise access design across identity providers, multiple AWS accounts, and workload execution paths.
Keep one durable idea in view:
Enterprise AWS access scales when identity starts centrally and permissions are assumed locally through roles.
Sections
How the Chapter Develops
The chapter develops in this order:
Start with enterprise identity as a problem of lifecycle, ownership, and access consistency.
Explain IAM Identity Center and federation as the preferred human access model.
Distinguish human identity from workload identity and service-to-service access.
Extend the design to cross-account automation, auditability, and evidence collection.
Apply the model to an enterprise that wants consistent access across production and non-production environments.
Together, these sections show that enterprise identity is about access operating model and evidence, not only directory integration.
What You Will Be Able to Do
By the end of this chapter, the reader should be able to:
Explain why large AWS environments rely on federation and role assumption instead of many standalone IAM users.
Describe how IAM Identity Center fits into centralized human access.
Distinguish enterprise human access design from workload identity design.
Explain how cross-account automation and audit evidence should be planned together.
Recommend a practical enterprise access model for multi-account AWS estates.
Key Ideas
Enterprise identity begins with ownership of the person or workload identity, then maps to AWS roles.
IAM Identity Center and federation improve lifecycle control, consistency, and auditability.
Workload identity needs its own patterns and should not inherit human access assumptions.
Cross-account access should be deliberate, observable, and easy to review.
Access evidence matters because enterprise access is also a governance and compliance topic.