IAM Access Analyzer
Amazon Web Services (AWS)
TL;DR: I was the lead designer for the user experience of AWS Identity and Access Management Access Analyzer. I designed the end-to-end experience that helps developers and security administrators understand resource exposure and permission risks in complex cloud environments. The features launched publicly at AWS re:Inforce and re:Invent, and focused on making access analysis easier to interpret so cloud users could investigate and resolve permission issues more efficiently.
Industry:
Cloud Security
Role:
Lead UX Designer
Year:
2021 - 2025
Unused access
Unused access
re:Invent 2023 demo
Refine unused access
Refine unused access
re:Inforce 2024 demo
Internal access
Internal access
re:Inforce 2025 demo
Problem
When developers encounter access problems in cloud systems, understanding the cause is often difficult. Permissions can be defined across multiple policies, roles, and resource configurations. Users needed a clearer way to understand why access was allowed or denied and how to fix the issue without manually tracing policy logic.
Objective
The objective of this project was to make access analysis easier for developers and security administrators working with complex permission systems. Users needed a clearer way to understand why a resource was accessible, which policies contributed to that access, and what actions could resolve potential security risks.
My responsibility
Led interaction design for the setup, review, and remediation workflows.
Worked closely with TPMs, engineers, and security specialists to align product requirements with user needs.
Translated complex permission logic into clear and understandable interaction patterns.
Participated in usability testing and iterated on the design based on user feedback.
Results
Within the first week of each launch, hundreds of organization-level analyzers were created across AWS customer environments. The rapid activation translated into meaningful revenue impact, contributing millions of dollars through analyzer usage and related IAM governance capabilities. More importantly, adoption was driven by security necessity rather than experimentation. Customers were deploying organization analyzers at scale to gain visibility into cross-account access and enforce least-privilege posture across their AWS Organizations.
Challenge #1 - Configuration
Mental Model
Before customers can verify or refine permissions, they must first configure an analyzer. The core friction was conceptual. Security teams hesitated because enabling a governance control without understanding its output introduces operational risk, and cost.
Customers were expected to enable analyzers without fully understanding:
Scope (account vs. organization level)
Impact (what will be analyzed)
Signal (what findings they should expect)
In my design approach, I focused on three principles:
Clarify intent before configuration
Introduced clear, plain-language explanations that framed each analyzer in terms of risk outcomes rather than policy mechanics.
Reduce cognitive load during setup
Streamlined setup flows, emphasized scope selection, and surfaced contextual help at decision points rather than in documentation.
Communicate structures visually
Display AWS Organizations structure which define trust boundaries, account hierarchy, and blast radius.
Challenge #2 - Presentation
After enabling analyzers, customers are presented with findings. The challenge at this point is about presentation and comprehension. The UX responsibility was to translate complex access issues into digestible data presentation.
Dashboard
The dashboard surfaces counts by severity and analyzer type before exposing detailed rows.
This establishes risk posture at a glance. It helps security teams get to the most critical tasks first.
Structure findings
Users can zoom from a dashboard overview to specific resource and access path without losing context. We also tested several iterations of how the consolidation should be presented.
Challenge #3 - Action
Findings alone do not reduce risk. Security posture improves only when policies are tightened. The challenge is that IAM policies are JSON documents, often lengthy, nested, and difficult to interpret. The UX goal in Refine was to transform policy modification from a high-risk editing task into a guided, confidence-building workflow.
Recommendations
Taking actions towards a finding is challenge because it requires manually reviewing current permissions and refine it to narrow it down. Most of the time security team need to review multiple layers and think about the works multiply by different resources and teams. We present policy recommendation generated by automatic reasoning to help customers understand what actions they need to take.
What I learned
Designing for identity and access management reinforced how important clarity is in security tools. Users interact with permission systems in different contexts. Some findings require immediate investigation when a resource may be unintentionally exposed, while others are reviewed as part of regular security audits or compliance checks. In both situations, the interface needs to clearly explain why access exists and what action may be required, without forcing users to interpret complex policy syntax.
This project also highlighted the importance of balancing accuracy with simplicity. Security systems require precise representations of how permissions are evaluated, but presenting all technical details at once can overwhelm users. Effective design requires structuring information so that users see the most relevant insight first, with deeper details available when needed.
In this project we tracked product metrics and usability feedback to understand how the design improved the investigation experience. However, after leaving the company I no longer have access to those internal measurements. Looking back, I would make sure to document and retain high-level impact metrics earlier so they could be referenced more easily when sharing the work externally.