Awsviz.dev simplifying AWS IAM policies

Tool overview & reception

• Thread discusses a new tool, awsviz.dev, that visualizes AWS IAM policies as graphs to aid understanding and debugging.
• Several commenters find the idea useful, especially for teams that routinely produce incorrect or over‑permissive policies.
• Some ask how it differs from generic JSON visualizers; implication is that domain‑specific IAM analysis and “allowed actions” views are the value-add.

UX, features, and data handling

• Users initially find the UI confusing (where to paste JSON, what to upload); the author adds a JSON input and clarifies that zips of policy files are accepted.
• Feedback suggests surfacing “what the user is allowed to do” more prominently and making the policy details pane scrollable.
• Multiple commenters are wary of uploading sensitive IAM data; reassurance is given that processing is client‑side and the code is open source, but people want the GitHub link more visible.
• One commenter asks how security severity is rated and requests a documented list of checks and references to underlying guidance.

Product name concerns

• Several note the name visually and phonetically resembles “Auschwitz,” calling it a very bad choice.
• Suggestions include minor renames or hyphenation (e.g., “aws-viz”) to avoid the association.

IAM complexity and account design debates

• Long subthread on IAM being powerful but overly complex, especially for small teams and startups.
• Some argue IAM is conceptually simple (“who can do what on which resource”) and essential at AWS scale; others say its evolution (SCPs, resource policies, assumed roles, boundaries, conditions) makes real-world reasoning very hard.
• Debate on multi‑account strategies: one-account-per-env vs. more granular per-system or even per-component accounts, with discussion of VPC sharing, peering, Transit Gateway, and cost/complexity trade‑offs.

Developer pain, tools, and desired improvements

• Common complaints: hard-to-interpret permission errors, inconsistent condition key support, scattered documentation, nested API permission chains, poor IAM/UIs, and eventual consistency in policy updates.
• Many admit to resorting to overly broad/wildcard permissions or even root credentials to “get things working,” sometimes lingering in code for years.
• Suggested improvements: better simulators and recorders that infer needed permissions from actual API calls, “record mode” that logs minimal required access, clearer logs and error messages, easier “coarse-grained” starter roles, and simpler abstractions for small teams.
• Mention of other tools and data sets (e.g., IAM datasets, policy-checking tools, infrastructure-as-code choices) as complementary aids.