Why Minifying Your IAM Policy Usually Doesn't Help

AWS rejects a policy for being too large, and the obvious fix looks obvious: strip the indentation, collapse it to one line, try again. For four of the five places IAM enforces a size limit, that fix does precisely nothing — the quota was never measuring the pretty-printed document in the first place.

Most size limits are measured after whitespace is already gone

Per AWS's own published IAM and STS character limits, every attached policy type — a customer-managed policy, and the combined size of every inline policy on a user, group, or role — is measured against its length with whitespace stripped, regardless of how the document is actually formatted when you save it. One policy type breaks that pattern:

A policy that's 370 characters formatted with full indentation might be 184 characters once whitespace is gone — and every attached-policy quota above checks that 184, not the 370, whether you paste in the pretty version or the minified one. Minifying before you save it doesn't change what AWS was already going to measure.

So why does "too large" happen at all?

If whitespace was never counted, the only way a policy hits one of these four quotas is that its actual content — the Sids, actions, resources, condition keys, and (especially) long lists of explicit resource ARNs instead of wildcards — is genuinely too much JSON. That's a real constraint, and it has real fixes: consolidate repeated statements, replace long literal lists with a pattern or a condition, or split the policy and attach more than one. None of those fixes is "remove the newlines," because the newlines were never part of what was being measured.

The one case where minifying is the actual fix

A session policy — the inline policy you can optionally pass directly to sts:AssumeRole to further restrict a role's permissions for just that one session — has its own 2,048-character limit, and this one genuinely is measured against the plaintext you pass, whitespace included. Pad the exact same policy with enough indentation and it can cross 2,048 characters in its pretty-printed form while the underlying JSON content is only a couple hundred characters minified — comfortably under the limit the instant the whitespace is gone:

same policy, same content, two different outcomes:
  pretty-printed:  2,479 characters → over the 2,048 limit
  minified:          119 characters → well under it

For this one policy type, and only this one, minifying is a legitimate, complete fix for exactly the kind of "too large" error that minifying can't touch anywhere else.

Knowing which bucket you're in is the whole trick

The error message AWS gives you doesn't distinguish these cases — "policy document exceeds the maximum length" reads the same whether whitespace is the problem or isn't. The only way to know which fix actually applies is knowing which of the five quotas you're up against, and that depends entirely on how the policy is being attached — directly to an identity or resource versus passed inline to an AssumeRole call — not on anything visible in the policy document itself.

Try it yourself

IAM Policy Minifier checks a pasted policy against all five real quotas at once, computing both the plaintext and minified length so you can see immediately which limit (if any) is actually the one in play, rather than guessing from an opaque error message. Runs entirely in your browser.