IAM Policy Patterns

Amazon Web Services (AWS)

TL;DR: I designed two policy patterns that structure how customers define and verify permissions in AWS. One is guiding customers to generate policies from common real-world scenarios, another one is enabling them to simulate and validate effective access before deployment, reducing configuration errors, ambiguity, and “access denied” incidents across services.

Industry:

Cloud Identity and Permissions

Role:

UX Designer

Year:

2021 - 2025

Pattern 1 - Use Case Builder

Policy authoring in AWS is powerful but complex. Many customers struggle to translate business intent into valid IAM policies, especially when navigating unfamiliar services or condition keys. The Use Case Builder pattern addresses this by structuring policy creation around the most common real-world access scenarios (for example, read-only access, cross-account sharing, or limited administrative roles).


Rather than beginning with an empty editor, users select a predefined use case, configure scoped inputs (resources, actions, principals), and generate a validated policy foundation. This approach communicates intent first, then exposes underlying policy structure. The pattern has been adopted across multiple AWS surfaces where policy writing is required, improving consistency, reducing configuration errors, and shortening time to completion for common permission tasks.

Pattern 2 - Policy Simulator

Authorization failures are difficult to diagnose because effective permissions in AWS are the result of multiple intersecting policies (identity policies, resource policies, SCPs, boundaries, etc.). Customers often deploy changes without full certainty of the outcome, leading to “access denied” incidents or unintended over-permissioning.


The Policy Simulator pattern enables users to simulate real requests against selected identities, actions, and resources. It evaluates effective permissions and clearly explains whether access is allowed or denied, including which policy statements contribute to the result. This pattern shifts policy validation from reactive troubleshooting to proactive verification.