Somewhere in every Azure cost-tool onboarding, a security engineer is staring at two built-in roles with nearly identical names: Cost Management Reader and Billing Reader. Both sound like "can read the bill." They read different universes, live on different scope systems, and granting the wrong one produces a cost tool that either sees nothing useful or sees the one thing you didn't intend to share.
Azure's permission model is the most misunderstood of the three clouds in cost work, precisely because it looks familiar. So here is the exact map: what each role sees, which scopes they attach to, what a cost tool genuinely needs task by task, and the roles that should never appear in a read-only onboarding.
The two roles, decoded
Cost Management Reader is an Azure RBAC role. It attaches to management groups, subscriptions, and resource groups, and it reads cost and usage analysis: the Cost Analysis views, budgets, exports, and forecasts. This is consumption data: which resources generated which costs, amortized or actual. It does not read invoices, payment methods, or your billing relationship with Microsoft.
Billing Reader lives on the billing scope hierarchy, not the resource hierarchy: billing accounts, billing profiles, invoice sections (on Microsoft Customer Agreement), or the enrollment (on Enterprise Agreement). It reads invoices, billing account properties, and payment-side artifacts. It answers "what did Microsoft charge this legal entity" rather than "which workload spent what."
The one-line separation: Cost Management Reader reads where the money went; Billing Reader reads what the invoice says. A cost tool's daily job is the first. The second is only needed if the tool reconciles down to invoice PDFs and billing profiles, and many teams reasonably keep that visibility internal.
One more pair that gets confused with these: Reader (control-plane metadata of resources, no cost data at all) and Monitoring Reader (metrics via Microsoft.Insights/metrics/read). Neither shows a dollar; both are essential for the non-dollar half of cost work.
What a cost tool needs, task by task
- Spend analysis, budgets, showback: Cost Management Reader at the subscription (or one management group above all subscriptions in scope). This is the workhorse grant.
- Inventory (what exists, its size and config): Reader at the same scope. Without it, costs have no resource context: you see the spend line, not the VM behind it.
- Rightsizing and idle detection: Monitoring Reader, which unlocks the metrics that turn "this VM exists" into "this VM has averaged 3% CPU for a month." Worth knowing: Azure's Reader role is genuinely control-plane only (data actions are a separate category in Azure RBAC), so metadata grants here don't leak data access the way AWS's managed ReadOnlyAccess does.
- Reservation and savings-plan visibility: reservations have their own RBAC; Reservations Reader at the reservation order level, or rely on Cost Management's amortized views for the dollar side.
- Invoice-level reconciliation (optional): Billing Reader on the billing account or billing profile. Grant it deliberately, to the people or tool doing reconciliation, not as a default part of a bundle.
The assignments, as commands:
az role assignment create --assignee <APP_ID> \
--role "Cost Management Reader" --scope "/subscriptions/<SUB_ID>"
az role assignment create --assignee <APP_ID> \
--role "Reader" --scope "/subscriptions/<SUB_ID>"
az role assignment create --assignee <APP_ID> \
--role "Monitoring Reader" --scope "/subscriptions/<SUB_ID>"
Billing Reader is assigned on the billing scope instead: Cost Management + Billing, then Access management (IAM) on the billing account or billing profile. On an Enterprise Agreement the equivalent lives in enrollment roles; on MCA it's the billing-profile roles. If a vendor's docs don't distinguish EA from MCA here, they haven't onboarded many Azure enterprises.
Two practical notes that save a support ticket later. First, scope inheritance: one assignment at a management group beats twenty per-subscription assignments, and it automatically covers subscriptions added later. Second, exports: cost data at scale flows best through a scheduled Cost Management export (with the amortized dataset if commitments matter to you), which the same Cost Management Reader can configure visibility for.
What a read-only cost tool must never ask for
- Owner or Contributor, at any scope. There is no cost-visibility justification. A tool that requests Contributor "to simplify setup" is asking you to skip the review it should be passing.
- User Access Administrator. The ability to grant roles is the ability to escalate; it converts a read-only tool into a latent admin.
- Data actions. Storage blob readers, Key Vault access, database data roles: cost math needs sizes and meters, never contents.
- Standing write roles as a bundle. If the tool can also act (deallocating idle VMs, scheduling non-production), that's a legitimate second tier, granted separately and later: Virtual Machine Contributor scoped as tightly as possible, behind an explicit opt-in, never folded silently into onboarding.
The evaluation heuristic from the AWS version of this problem transfers cleanly: the vendor should publish the exact roles, the exact scopes, and the reason for each, and starting billing-only should be possible. As a live example of that shape, ZopNight's permission docs specify Azure access as Monitoring Reader at subscription scope as the minimum (or Reader for fuller inventory), Cost Management Reader with the amortized cost export for billing, and Virtual Machine Contributor only as the explicit opt-in write tier for start and deallocate actions, with a View Permissions screen that shows per-account Granted, Denied, or Unknown state per feature. That's the disclosure level to require from any vendor before the first role assignment.
FAQ
What's the difference between Cost Management Reader and Billing Reader in Azure?
Cost Management Reader is an Azure RBAC role on subscriptions or management groups that reads cost analysis, budgets, and exports: where the money went, per resource. Billing Reader lives on billing scopes (billing account, billing profile, or EA enrollment) and reads invoices and billing relationship data: what Microsoft charged the entity. A cost tool needs the first; the second only for invoice-level reconciliation.
Does the Reader role include cost data?
No. Reader grants control-plane metadata of resources, and Azure's Cost Analysis blade requires a cost-specific role for the data behind it. Conversely, Cost Management Reader doesn't grant resource metadata. Cost work needs both, which is why the pair (plus Monitoring Reader for metrics) is the standard read-only trio.
At what scope should I grant Cost Management Reader?
The highest scope that matches the tool's mandate: a management group covering the relevant subscriptions is one assignment instead of dozens and auto-covers new subscriptions. Grant at a single subscription only when the mandate is genuinely that narrow.
Is Monitoring Reader safe to give a third-party tool?
It reads metrics (CPU, memory, connections, network) via Microsoft.Insights/metrics/read: numbers about resources, not data inside them. That's the ingredient idle detection and rightsizing need. It doesn't read logs with application content; Log Analytics access is a separate, more sensitive grant that a cost tool shouldn't need.
Do EA and MCA handle these roles differently?
The Azure RBAC side (Cost Management Reader, Reader, Monitoring Reader) is identical. The billing side differs: EA uses enrollment roles managed in the enrollment hierarchy, MCA uses billing account and billing profile roles. If invoice reconciliation is in scope, confirm which agreement type you're on before promising the vendor a Billing Reader assignment, because the granting screen and the person who owns it differ.
Top comments (0)