AWS IAM

AWS IAM's core design prioritizes deterministic permission evaluation over security usability, resulting in a system where CRUD-style permissions cannot be implemented auditably. The architecture uses low-level API action lists with boolean logic complexity ('deny sandwich'), strict character limits forcing wildcard usage, and unpredictable new actions added without warning, making it impossible to implement basic security expectations.

Misconfigured IAM roles and permissions leave AWS environments vulnerable to unauthorized access. Developers must carefully manage user access and permissions to prevent security breaches.

IAM error messages are vague and don't clearly indicate what permissions are missing or what the actual issue is. Developers resort to support tickets to understand error messages, creating blocker dependencies.

AWS adding IPv6/AAAA support to endpoints breaks existing IAM policies that use v4-centric statements (like aws:SourceIp). This causes unexpected DENYs or, worse, unexpected ALLOWs that compromise access control, impacting customers in affected regions with limited workarounds.

When IAM permission errors occur, developers must manually add permissions rather than having AWS automatically generate the required policy. A simple 'Fix this' button that generates required IAM records would dramatically reduce friction, but this feature doesn't exist.

AWS's user and permission management system is convoluted, particularly the distinction between root accounts and IAM accounts. Adding users and accounts to organizations is non-intuitive, making it harder than competing platforms like GCP.