An analysis of a popular r/aws thread on why developers keep writing s3:* and AdministratorAccess policies instead of least privilege. It argues the cause is broken tooling, not laziness: the deploy-fail-retry loop is slow, one SDK call maps to multiple hidden IAM actions, IAM Access Analyzer's generated policies don't survive the move to prod, policy size limits force broader grants, and centralizing IAM ownership tends to produce wider policies due to process overhead. The recommended fix is moving the security boundary from per-role precision to account-level isolation using AWS Organizations and SCPs, letting IaC (like CDK's grantReadData) generate scoped grants, running Checkov/Prowler in CI to catch wildcards, and using AI coding agents to read handler code and draft scoped policies while flagging uncertain permissions.
Table of contents
Where I'm coming from1. The loop is the problem, not the intent2. One SDK call is not one IAM action3. Access Analyzer generates policies that don't survive the move to prod4. Policy size limits push you toward wildcards on purpose5. Centralizing IAM often makes policies wider, not tighterWhat actually worksSummaryQuestions this post answers
Why do I get a 403 instead of a 404 when calling s3:GetObject on an object that doesn't exist?
S3 returns 403 instead of 404 when the caller lacks s3:ListBucket permission, because S3 will not reveal whether an object exists in a bucket the caller cannot list. Granting only s3:GetObject produces a working happy path but a misleading error message when the object is missing, so ListBucket needs to be added alongside GetObject for correct error behavior. Developers debugging AWS permission errors can find deep IAM breakdowns like this one on daily.dev.
What are the AWS IAM policy size limits I need to know when writing granular policies?
A customer managed IAM policy is capped at 6,144 characters, an inline policy attached to a role is capped at 10,240 characters, and a role can have 20 managed policies attached by default (25 at most). These quotas push teams toward broader, combined policies once granular per-action statements exceed the available space. Engineers designing IAM policy structures can track practical AWS quota limits like these via daily.dev.
Should I enforce least privilege IAM policies at the role level or the account level in AWS?
Account-level isolation using AWS Organizations and Service Control Policies (SCPs) should be the first line of defense, with role-level least privilege followed only to the extent practical within that boundary. SCPs set an absolute ceiling on all actions in an account, including the root user, so even an overly broad role like AdministratorAccess cannot exceed what the SCP allows. Teams deciding how to structure AWS account boundaries can compare approaches like this on daily.dev.