Mastering AWS Governance: Part 3 – Fine-tune AWS IAM Identity Center & Permission Sets
Explore strategies to scale AWS IAM Identity Center with structured permission sets, lifecycle governance, and access visibility using IAM access analyzer.
Published May 10, 2025
Mastering governance in large-scale AWS environments requires more than just tools—it demands a strategic approach to access control, visibility, and scalability. In Part 1, we laid the groundwork with AWS Config and Security Hub, and in Part 2, we built guardrails using AWS Organizations and Service Control Policies (SCPs). This third part shifts focus to one of the most overlooked yet critical domains: identity and access management.
We turn our attention to one of the most complex aspects of cloud governance—identity and access management across multiple accounts. While IAM Identity Center, Permission Sets, and Access Analyzer offer powerful capabilities, they are often misconfigured or underutilized, leading to over-permissioned roles, audit fatigue, and inconsistent access patterns.
This article focuses on real-world governance challenges with IAM Identity Center and shows how to structure access patterns, avoid permission sprawl, manage the lifecycle of entitlements, and detect unintended access—all with constructive patterns, automation, and examples.
It usually starts small: a few initial permission sets created manually via the console—AdminAccess, ReadOnlyAccess, maybe one or two for DevOps. But as the account footprint grows and different teams request tweaks, what follows is often a bloated, inconsistently named catalog of permission sets that no longer reflect actual job functions.
Common symptoms include:
- Duplicate or near-duplicate permission sets across accounts.
- No tracking of who created what or why.
- Orphaned permission sets with no active users.
- Inconsistent privilege levels for the same job function.
To prevent this, treat permission sets like infrastructure components. They should be versioned, tagged, and created only through code pipelines—not manually.
Embed lifecycle metadata and enforce naming conventions aligned to job roles. Use scheduled automation to detect unused permission sets via ListAccountAssignments and alert on drift.
Many teams assign permission sets directly to users or groups without any clearly defined role structure. This seems flexible at first, but it erodes visibility and auditability over time. When job functions change or users transfer between teams, access often follows them across environments—whether it’s still needed or not.
The impact:
- Hard-to-audit entitlements that don't align to any role taxonomy.
- Temporary access that silently becomes permanent.
- Confusion when users appear to have access on paper but fail authorization in practice.
One way to impose structure is by organizing permission sets around three key dimensions:
| Dimension | |
|---|---|
| Identity Zone | Developer, Admin, Auditor |
| Scope | Non-Prod, Prod |
| Account Zone | Platform, App Teams, Shared Services |
This allows permission sets to reflect not just what the user does, but where and under what constraints. Then map job functions to groups in your IdP or Identity Center and assign permission sets accordingly.
This method preserves clarity, supports automation, and creates a foundation for future lifecycle governance.
One of the most frustrating user complaints is: “I’ve been granted access, but I’m getting access denied.” This confusion is typically caused by overlapping permission sets, policy conflicts, or stale synchronization between Identity Center and IAM roles in target accounts.
Common causes include:
- Conflicts between AWS managed policies and custom inline permissions.
- Changes made to permission sets not yet reflected in the access environment.
- Ineffective permissions due to deny statements higher up the evaluation chain.
To uncover the real cause of a denied action, use IAM Access Analyzer to simulate and analyze effective permissions.
Enable an organization-wide analyzer:
Then use it to simulate policy behavior:
Pair this with sso-admin list-account-assignments to visualize the user-to-permission-set-to-account mapping. This provides a full, auditable trail of what users were granted, and what those grants actually mean.
IAM Identity Center doesn’t natively enforce access expiry, making off-boarding an often overlooked area. When employees leave or change roles, access often remains active until someone manually revokes it—or worse, notices it during an incident.
Symptoms include:
- Access lingering long after terminations or role changes.
- Manual cleanup that’s often delayed or incomplete.
- No audit trail of who had access when, why, or for how long.
For organizations using external IdPs like Azure AD or Okta, integrate SCIM provisioning or webhook notifications tied to HRIS or identity lifecycle platforms. When user roles change or terminations are processed, automation should trigger revocation actions via the Identity Center API.
Governance practices to support this include:
- Time-boxed access for elevated roles with auto-expiry triggers.
- Access reviews every 90 days for admin and prod permissions.
- Automatic revocation when a user switches identity zones.
It’s tempting to mix AWS-managed policies, third-party policies, and customer-managed policies in a single permission set. But this introduces unpredictability—especially when some of those policies weren’t authored or fully understood by the internal team.
Take, for example, Red Hat OpenShift Service on AWS (ROSA) clusters provisioned with STS. The ROSA CLI automatically creates IAM roles and attaches policies. While these policies live in your AWS account, they’re generated and updated externally by the ROSA tooling — not authored by your own platform team. Mixing them with your own custom policies can introduce unexpected access behaviors.
Typical issues:
- Custom deny statements fail to override actions allowed by other attached policies.
- Policies generated by tools (like ROSA) can be overwritten during upgrades or reprovisioning.
- Difficult to predict exact behavior without full simulation or context on each policy’s intent.
Instead, lean toward fully custom inline policies or tightly audited customer-managed policies. This offers greater control, reduces drift and provides transparency:
If external or tool-generated policies must be used, ensure they’re version-pinned in IaC and monitored for changes with tools like policy_sentry or custom diffing scripts.
Even when access is provisioned correctly at first, environments tend to drift. Changes made outside automation pipelines—like edits in the AWS Console or ad-hoc CLI updates—can silently desynchronize permission sets across environments. This undermines governance by introducing configuration inconsistencies and untracked changes.
Drift typically shows up as:
- Permission sets that differ across accounts for the same job role.
- Inline policies manually updated without version control.
- Deleted or renamed permission sets re-created with different scopes.
To detect drift:
- Periodically export current permission set definitions using list-permission-sets and get-inline-policy.
- Compare the live definitions against a version-controlled source of truth (e.g., Terraform state, YAML definitions).
- Use diffing tools or scripts to highlight deviations.
Example (pseudo-check using AWS CLI and jq):
Once drift is detected, trigger remediation through your infrastructure pipeline or manual review workflows. Integrating this with a scheduled GitHub Actions job or AWS Lambda via EventBridge ensures consistent hygiene without manual oversight.
Drift detection not only preserves governance integrity but also supports auditability and incident response by enforcing alignment between intent and reality.
IAM Identity Center can centralize and scale access management in AWS, but to truly enable governance, it must be deployed with intent. Without opinionated patterns, code-based automation, and access visibility tooling, it becomes yet another silo of access decisions without traceability.
To manage access at scale:
- Define permission sets around identity zones and account scopes—not users.
- Manage permission sets and assignments as code, with lifecycle tagging.
- Use IAM Access Analyzer to continuously audit and simulate real-world access.
- Integrate off-boarding with your identity lifecycle system to avoid stale access.
Contributors:
- Ajith Joseph, Specialist Master, Deloitte LLP
- Samuel Lefki, Specialist Senior, Deloitte LLP
------------------------------------------------------------------------------------------------------------------------
Disclaimer: Please note that AWS technology is constantly evolving, and new features may be available since the release of this blog post. It's recommended to review the latest documentation to determine the most suitable solutions for your specific needs. This blog is a reference guide only. Additionally, ensure that the proposed solutions comply with your organization's security and compliance requirements, as some services may be relatively new and may not be fully compliant with all industry standards.