My AWS admin role could not see the billing page, and IAM was not the problem
An IAM Identity Center user with AdministratorAccess gets an access denied error on Billing preferences in a new AWS account. The permission set is not the cause, and editing IAM policies will not fix it. Here is what is actually blocking it and what it teaches about how AWS evaluates access.
I was setting up a new AWS account properly: MFA on the root user, no root access keys, and daily access through IAM Identity Center with an AdministratorAccess permission set. Then I went to enable Free Tier alerts and hit this:
You don't have permission to access billing information for this account. Contact your AWS administrator if you need help.
I was the administrator. The role had AdministratorAccess, which allows every action on every resource. The message pointed at IAM permissions, so my first instinct was to go and look at the policy.
That instinct was wrong, and the hour it could have cost me is the reason I am writing this.
What is actually blocking it
AWS treats billing data as a separate category. By default, IAM users and roles cannot reach it at all, no matter what their policies say. There is an account-level setting that controls this, and until it is switched on, every IAM principal is denied.
The setting lives in Account settings, under IAM user and role access to Billing information. Only the root user can change it.
So the fix is:
- Sign in as the root user.
- Open Account settings.
- Find IAM user and role access to Billing information and choose Edit.
- Activate IAM access, then save.
- Sign out of root and return to your normal admin identity.
Billing then works as expected.
Why this is worth more than a fix
The useful part is not the setting. It is what the denial reveals about how AWS decides whether an action is allowed.
It is tempting to picture one gate: does the IAM policy allow this action, yes or no. In reality there are several layers, and any one of them can refuse. An IAM policy can allow something while a service control policy at the organization level denies it. A permission boundary can cap what a role may do regardless of its attached policies. A resource-based policy, such as an S3 bucket policy, can deny a request that identity policies would otherwise permit. An account-level setting, as here, can place a whole category of data out of reach.
An explicit deny at any layer wins. Nothing further down can override it.
That turns "access denied" from a dead end into a diagnostic question. Instead of asking what permission is missing, ask which layer said no. The answer is often not the one the error message points at, because the message usually describes the symptom rather than the cause.
For what it is worth, this specific denial is also a reasonable design decision. Billing data reveals what an organization is building, how fast it is growing, and where its spending sits. Requiring a deliberate action from the account owner before exposing it to every administrative role is a sensible default, even if the error message could say so more clearly.
A note on the root user
This is one of a small number of tasks that genuinely require the root user. Most work should never need it, and the standard advice is sound: put MFA on root, delete any root access keys, and sign in with it only for the tasks that leave no alternative.
Worth knowing which those tasks are, so that the rare time you reach for root, you know it is not because you missed something simpler.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article