IAM Access Analyzer
Amazon Web Services (AWS)
TL;DR: I am the lead designer behind IAM Access Analyzer at Amazon Web Services (AWS), a security service that answers a fundamental question for cloud: who can access what, and should they?
I led the end-to-end design across multiple re:Invent and re:Inforce launches, defining and evolving the product experience from technical workflows to polished visual. My scope covered early concept exploration and experiment, interaction and visual design, usability testing and validation, executive design reviews, and launch presentations. I partnered closely with engineering, security, and product to translate complex access control models into workflows that are understandable, actionable, and scalable.
The result was a cohesive experience that supports least-privilege governance while reducing operational friction for customers managing cloud security at scale.
Industry:
Cloud Security
Role:
Lead UX Designer
Year:
2021 - 2025
Problem
AWS customer stores valuable resources on cloud, such as financial data, intellectual property and customer records. They manage access to the resources through IAM policies, resource policies, roles, and organizational guardrails. As environments scale across hundreds of accounts, thousands of roles, and complex service integrations, permissions accumulate. People change roles. Vendors leave. Temporary access becomes permanent. These excessive permissions create security exposure, increase audit complexity, and weaken least-privilege posture in AWS environments.
Objective
The objective of IAM Access Analyzer at Amazon Web Services is to provide continuous, automated reasoning over access configurations so customers can confidently enforce least privilege at scale. It helps customers to answer 3 questions:
External access: Does any S3 bucket, KMS key, IAM role, or other resource allow access from outside my organization?
Internal access: Do identities inside my organization have broader access than intended to sensitive resources?
Unused access: Which roles or policies grant access that is no longer used, but still technically allowed?
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.
