The comprehensive playbook for Identity, Resource, and Billing Separation

Part 1/3: The three permission systems everyone must understand

Azure is a powerful cloud platform, but its governance model is widely misunderstood, especially in fast-moving, engineering-led organizations and digital-native startups.

Three entirely different permission systems coexist:

1. Microsoft Entra Directory Roles: Identity and security administration for the tenant

2. Azure RBAC (Resource-Based Access Control): Permissions for deploying and managing cloud resources

3. Azure Billing/Commerce Roles: Permissions for invoices, credits, commitments, Marketplace purchases

These systems share no overlap. A role in one plane provides zero access in the others.

Once startups understand this separation, everything from Marketplace governance to MACC visibility to least-privilege access becomes dramatically clearer.

This guide breaks down the entire model, provides deep insight, and offers practical patterns used across digital natives running large-scale AI, Kubernetes, and SaaS workloads on Azure.

Introduction: The visibility problem no one talks about

If you’re a startup moving fast on Azure, you’ve likely heard variations of the same questions:

• “Why can’t my engineering Owner see MACC credits?”
• “Why can’t a Billing Contributor deploy a VM?”
• “Why doesn’t Global Admin let me access subscriptions?”
• “Why can a Contributor deploy AKS but not buy Snowflake?”
• “Why does Cost Management Reader show cost but not credit balance?”

These questions appear in nearly every customer I work with: AI companies consuming Azure OpenAI at scale, SaaS companies running global AKS footprints, and digital natives under Microsoft Azure Consumption Commitments (MACC).

The cause is simple, but rarely understood:

Azure is governed by three distinct permission systems, operating on three different planes, built for different purposes.

Once organizations understand which system controls what, governance becomes significantly easier to design.

This guide exists to make that understanding finally clear.

The heart of the problem: Azure does not have one single permission system

Azure has three completely separate systems that never overlap:

Why the separation exists

• Entra Global Admin can’t access subscriptions.
• Subscription Owner can’t see the MACC balance.
• Billing Account Owner can’t deploy resources.
• Cost Management Reader can see usage but not credits, invoices, or commitments.
• Engineers can deploy VMs but not purchase Snowflake SaaS.
• Finance can view MACC credits but can’t modify AKS clusters.

This separation is by design. Once a startup understands that these planes never intersect, governance becomes dramatically more predictable.

The three-plane model (Conceptual diagram)

Plane 1: Microsoft Entra Identity Roles (Identity Plane)

Microsoft Entra (formerly Azure AD) governs:

• Identity
• Authentication
• Authorization
• Conditional Access
• PIM (Privileged Identity Management)
• Group membership
• Tenant-wide administrative policies

Entra is the security boundary for the entire tenant.

Common misunderstanding:

"I’m Global Admin — why can’t I access subscriptions?"

Because Entra roles do not grant Azure RBAC permissions by default. This behavior is intentional and foundational.

What Entra roles can do

✔ Create and manage users
✔ Manage MFA & Conditional Access
✔ Approve PIM requests
✔ Manage security settings
✔ Create/assign groups (which then can hold RBAC roles)
✔ Manage enterprise applications, OIDC apps, etc.

What Entra roles cannot do

• Deploy VMs
• Change RBAC roles
• Access billing
• View invoices
• View MACC credits
• Modify subscriptions
• Create resource groups
• Access data or storage accounts

Plane 2: Azure RBAC (Resource Plane)

Azure RBAC controls everything related to resources:

• VMs
• AKS
• Azure OpenAI deployments
• Storage accounts
• Networking
• Managed identities
• Workloads
• Monitoring
• Logs
• Automation
• Policies
• DevOps flows
• IaC

It is the cloud operations plane.

RBAC scopes

RBAC can be assigned at:

• Tenant root
• Management group
• Subscription
• Resource group
• Individual resource
• Sub-resource (e.g., Key Vault secret)

Common RBAC roles

• Owner: full control including role assignment
• Contributor: can deploy and modify resources
• Reader: read-only
• Cost Management Reader: can see usage-based cost only
• User Access Administrator: can assign RBAC roles
• Custom roles

The critical point

RBAC cannot see billing.
RBAC cannot view MACC.
RBAC cannot read invoices.
RBAC cannot approve Marketplace purchases.

Even Subscription Owner is blind to billing.

Plane 3: Azure Billing/Commerce Roles (Financial Plane)

This plane governs the relationship between the customer and Microsoft:

• Credits (MACC, Azure credits, grants)
• Commitments
• Invoices
• Payments
• Billing profiles
• Marketplace SaaS purchases
• Private offers
• RI / Savings Plan purchases

Commerce roles

• Billing Account Owner
• Billing Account Contributor
• Billing Reader
• Invoice Section Owner

What Billing roles can see

✔ MACC balance
✔ Credits
✔ Invoices
✔ Payment history
✔ Reservations & Savings Plans (financial side)
✔ Marketplace purchase capabilities

What Billing roles cannot do

• Deploy anything
• Modify RBAC
• Access resources
• See workloads
• Change policy
• Access cost analysis at resource group level

Summary table: The three permission systems

Why customers struggle with this model

Digital natives customers scale quickly and often assume cloud governance is linear. It’s not.

The three-plane model creates friction when misunderstood:

• Engineers expect to see billing
• Finance expects to see workloads
• Security expects Global Admin to have universal access
• Procurement expects to manage Marketplace purchases
• Leaders expect visibility without exposing commercial negotiations

The result is:

• Over-permission
• Misalignment
• Accidental governance gaps
• Confusion around cost, credit, and usage visibility
• Marketplace purchases occurring without oversight
• Engineering blind to MACC, leading to incorrect cost assumptions
• Finance blind to deployments, impairing budget forecasting

Part 2/3: Deep Dives - Identity, Resource, and Billing Planes 

Deep Dive #1 - Identity Plane (Microsoft Entra)

Security, Authentication, Authorization, Administrative Boundaries

Microsoft Entra (formerly Azure AD) is the authoritative identity provider for Azure. It controls:

• Who you are
• How you authenticate
• What directory-level permissions you hold
• How you elevate privileges
• Which groups you belong to
• Conditional Access
• PIM (Privileged Identity Management)
• Security policies

Key insight: Entra governs identity and security, not cloud resources or billing.

This model ensures:

• A compromised Global Admin cannot delete all subscriptions
• A compromised Subscription Owner cannot compromise directory security
• Identity and infrastructure operate independently for resiliency

Most relevant Entra roles in startups

What Entra cannot do

What Entra can indirectly influence

Because Entra manages groups, and groups are often used for RBAC assignments:

Entra is the root of who can be given access, but not what access they have.

This is where many organizations misunderstand the boundary.

Deep Dive #2 - Resource Plane (Azure RBAC) 

Everything engineering touches: workloads, clusters, deployments, pipelines, resources.

Azure RBAC is the backbone of the Azure operational model.

What Azure RBAC controls

• All deployments (IaC, CLI, Portal, API)
• Resource creation & modification
• Monitoring & diagnostics
• Logging & observability
• Key Vault, Storage, Networking
• AKS cluster operations
• Azure OpenAI deployments
• Workspaces, pipelines, data flows
• Everything under Azure Resource Manager (ARM)

RBAC Roles ≠ Billing Roles

The single biggest misconception in digital-native companies is believing RBAC can access billing.

RBAC cannot access:

• MACC credits
• Discounts
• Prepayment balance
• Payment methods
• Invoices
• Commitments
• Purchase history
• Marketplace SaaS purchases

RBAC Role examples & their behaviors

Even Owner, the highest role in the resource plane, is blind to billing.

Deep Dive #3 - Billing/Commerce Plane

Governed by Microsoft Commerce Platform (not Azure Resource Manager).

This plane governs:

• Billing accounts
• Invoices
• Credits
• Discounts
• Commitments
• Payment methods
• Invoice sections
• Marketplace SaaS purchases
• Reservations
• Savings Plans
• Private Offers

Commerce roles live in an entirely different system from RBAC.

Common billing roles

Billing is where MACC lives

MACC (Azure Consumption Commitment) visibility is tied to:

• Billing Account Owner
• Billing Account Contributor
• Billing Reader

RBAC roles do not have access here.

This means:

Even a subscription Owner cannot see MACC burn rate.

This single point causes confusion in almost every startup onboarding Azure.

Cost Visibility vs Billing Visibility

The #1 source of misunderstanding in governance.

Cost visibility (usage-based cost) comes from RBAC. Billing visibility (credits, invoices, MACC) comes from commerce.

These are two completely different datasets.

Cost Management Reader (RBAC) can see:

• Usage-based resource cost
• Cost by tags
• Cost by resource
• Cost forecast
• Budgets & alerts

But cannot see:

• Credits
• Invoices
• Payments
• MACC
• Private offers
• Contract terms

Billing Reader (Commerce) can see:

• Invoices
• Credits
• Payments
• MACC balance
• Marketplace transaction history

But cannot see:

• Resource-level cost breakdown
• Cost by tags
• Subscription usage trends
• Resource inventory

Visibility matrix (Reference table)

Marketplace Governance: The most misunderstood topic

Marketplace is the intersection between the resource and billing planes.

Deploying Azure resources ≠ Purchasing Marketplace SaaS

A Contributor can deploy:

• VMs
• Storage
• AKS
• Networking
• Databases
• Azure OpenAI
• Any native Azure service

But cannot purchase:

• Datadog
• Snowflake
• Elastic
• Confluent
• MongoDB Atlas
• Any SaaS offer with a price
• Private offers

Why?

Because SaaS purchases are commercial transactions, not resource deployments.

• Deploying → RBAC
• Purchasing → Commerce

Marketplace Permission Model

This is why Engineers often ask:

“Why can’t I buy Snowflake? I’m an Owner.”

Because Owner has no financial authority.

ABAC (Attribute-Based Access Control)

Advanced, Conditional, Resource-Aware Authorization

ABAC extends RBAC with conditions based on:

• Resource attributes (tags)
• Principal attributes
• Request context

Examples

• Allow Contributor access only to resources tagged Environment = Dev
• Allow read access only to storage blobs under a certain prefix
• Allow VM modification only if the VM has Owner = JohnDoe
• Restrict access during certain times (with CA integration)
• Enforce tenant isolation for multi-tenant SaaS applications

What ABAC is NOT

ABAC is not a separate permission system.

It is an enhancement to RBAC.

It cannot:

• Grant billing access
• Override Entra roles
• Access MACC
• Purchase Marketplace

ABAC improves resource-plane governance only.

Diagram (Governance separation model)

The recommended governance model for Startups

Based on experience with dozens of digital natives:

Engineering Plane

• 2–3 subscription Owners
• Platform/SRE team as Contributors
• Developers as RG-scoped Contributors or Readers
• Cost Management Reader for budget ownership
• ABAC for multi-tenant or regulated workloads
• Azure Policy for guardrails (VM SKUs, regions, encryption, tags)
• Management groups for structure

Finance Plane

• Billing Account Owner = CFO / Finance Director
• Billing Contributor = Finance Ops
• Billing Reader = FP&A
• All Marketplace-paid offers require finance approval
• MACC visibility restricted to finance

Identity/Security Plane

• 2–4 Global Admins
• PIM enforced
• Conditional Access for all admin roles
• Groups used for RBAC assignment
• Workload identities (Managed Identity) preferred over service principals

Part 3/3: Best practices for a clean, scalable Azure Governance Model

These recommendations are based on real-world experience with digital-native customers, AI startups, SaaS platforms, and global engineering teams operating at scale.

1. Use Entra ID Groups for all RBAC assignments

Never assign RBAC directly to individual users.
Use groups instead.

Benefits:

• Clear separation of identity plane and resource plane
• Easy onboarding/offboarding
• RBAC inheritance becomes predictable
• Enables PIM for group-based elevation
• Reduces misconfigurations
• Supports least-privilege roles at scale

Pattern:

• grp-sub-<SubscriptionName>-Owner
• grp-sub-<SubscriptionName>-Contributor
• grp-rg-<WorkloadName>-Reader

Then assign the group to the role.

2. Structure Azure with Management Groups

Every startup that scales beyond a single subscription eventually regrets not using management groups.

Recommended hierarchy:

Tenant Root (top-level, protected)
└── Contoso (name of org)
    ├── Platform
    ├── Production
    ├── NonProduction
    ├── Sandbox
    └── Shared Services

Benefits:

• Consistent guardrails
• Easier policy enforcement
• Cleaner RBAC assignment
• Clear environment separation

3. Enforce governance with Azure Policy

Azure Policy prevents:

• Deployment of disallowed VM SKUs
• Unencrypted storage accounts
• Wrong regions
• Wrong VM families (e.g., no GPU in nonprod)
• Missing tags
• Public IP misuse
• Specific Marketplace SKUs

Critical policy examples:

• Allowed locations
• Allowed SKU sizes
• Enforce HTTPS
• Enforce private endpoints
• Enforce customer-managed keys
• Enforce tagging

4. Apply conditional access + PIM for all admin roles

No permanent admin.
Use time-based elevation.

Key CA policies:

• MFA required for all admins
• Compliant device requirement (if feasible)
• Block legacy authentication
• Block sign-in from high-risk countries
• Require passwordless or phishing-resistant MFA

5. Use Infrastructure as Code for all deployments

Avoid manual deployments. Use:

• Bicep
• Terraform
• Pulumi
• ARM

IaC ensures:

• Repeatability
• Version control
• Deployment consistency
• Automated validation
• Security reviews
• Reproducible environments

6. Implement cost budgets and alerts

Budgets should exist at:

• MG level (global oversight)
• Subscription level (team ownership)
• Resource group level (environment-level tracking)

Alert channels:

• Email
• Teams
• Slack
• Automation (Logic App → PagerDuty/OpsGenie)

7. Lock down marketplace purchases

Marketplace is where financial risk appears.

Policy:

• Marketplace SaaS purchases allowed only for Billing roles
• All paid offers must go through Finance review
• Pre-approved list of third-party solutions
• Private Offers reviewed by Finance + Security

8. Separate Dev/Test/Prod workloads

Subscriptions are a security boundary.

Avoid mixing workloads.

Pattern:

• 1 subscription per environment per workload
• Platform teams get their own subscription
• Cross-subscription networking via Hub & Spoke or Landing Zones

9. Keep subscription owners to 2–3 people total

Subscription Owner is effectively "root" in the resource plane.

Too many Owners is a governance risk.

Limit to:

• Platform Lead
• SRE Lead
• Cloud Architect

10. Restrict billing visibility to Finance

Only Billing roles should see:

• Credits
• Commitments
• Discounts
• Invoices
• MACC balance

Engineers should never have access to commercial data.

Governance Anti-Patterns (What breaks organizations)

These patterns appear repeatedly in AI and SaaS startups. Avoid them at all costs.

❌ Anti-Pattern 1: Giving Engineers billing permissions

Symptoms:

• Engineers can see MACC and private offers
• Engineers can purchase Marketplace SaaS
• Procurement loses oversight
• Surprise invoices
• Increased financial risk

Fix:

• Restrict marketplace purchases to Billing roles only
• Remove Billing access from engineers immediately

❌ Anti-Pattern 2: Giving Finance subscription owner access

Result:

• Finance can accidentally delete production resources
• Over-permissioning
• Violation of least privilege
• Reduced segregation of duties

Fix:

• Finance roles belong in Billing plane, not resource plane

 

❌ Anti-Pattern 3: Too many subscription owners

Effects:

• No accountability
• High blast radius
• Hard to trace role assignments
• Risk of accidental modification/deletion

Fix:

• Maximum 2–3 owners per subscription

❌ Anti-Pattern 4: Believing Entra Global Admin = Azure Owner

This misunderstanding is extremely common.

Fix:

• Train leadership: Entra ≠ RBAC ≠ Billing

❌ Anti-Pattern 5: Deploying marketplace SaaS without Finance

Leads to:

• Incorrect MACC burn
• Unapproved costs
• Licensing duplicates
• Vendor lock-in without review

Fix:

• Require finance approval

❌ Anti-Pattern 6: Mixed Dev/Test/Prod in one subscription

This breaks:

• Cost analysis
• Access boundaries
• Policy enforcement
• Auditing
• Compliance

Fix:

• Separate subscriptions by environment

❌ Anti-Pattern 7: Not using Azure Policy

Symptoms:

• Inconsistent regions
• Wrong VM families deployed
• Missing tags
• Non-compliant configurations
• Public IP drift

Fix:

• Adopt Azure Policy early

RACI Model for Azure Governance

Adapted from Microsoft Cloud Adoption Framework.

Internal access guide template

You can include this template in your onboarding docs.

Finance

Engineering

Leadership

Operational Runbook: Marketplace purchase workflow

Step 1: Engineer requests a SaaS or Marketplace resource

Request includes:

• Why it’s needed
• Expected cost
• Impact on MACC
• Preferred vendor
• Alternatives

Step 2: Finance reviews commercial implications

Checks:

• MACC impact
• Budget alignment
• Discounts available
• Vendor validation
• Contract terms

Step 3: Billing role executes purchase

Billing Account Owner or Contributor completes the transaction.

Step 4: Engineering deploys or configures the resource

• SaaS connector
• Private offer entitlement
• RBAC for workload
• Integration pipelines

Step 5: Cost monitoring activated

• Alerts
• Budgets
• Tagging
• Forecasting

Final recommendations

After years of working with digital natives, I can summarize Azure governance into these principles:

1. Separate identity, resources, and billing. Always.

Never mix roles or permissions across planes.

2. Engineering owns the resource plane.

Let them deploy, build, and ship.

3. Finance owns the billing plane.

Let them protect commercial data.

4. Security owns identity and governance.

Let them enforce PIM, CA, and policies.

5. Keep subscription owners scarce.

More Owners = more risk.

6. Lock down Marketplace.

Every SaaS purchase should be approved by Finance.

7. Use IaC.

Manual deployments don’t scale.

8. Use budgets early.

Startups fail because of unexpected cost spikes.

9. Use management groups and policies.

Do not wait until you have dozens of subscriptions.

10. Build governance before scale.

Scaling without governance is expensive and dangerous.

Official Microsoft References

To support every concept in this document, here are authoritative sources.

RBAC, Billing, and Entra

• Azure RBAC Overview: https://learn.microsoft.com/azure/role-based-access-control/overview 
• Entra Directory & Admin Roles: https://learn.microsoft.com/azure/role-based-access-control/rbac-and-directory-admin-roles 
• Billing Roles (Microsoft Customer Agreement): https://learn.microsoft.com/azure/cost-management-billing/manage/understand-mca-roles 
• Assign Access to Cost Management Data: https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/assign-access-acm-data 

Marketplace Governance

• Marketplace Purchases: https://learn.microsoft.com/en-us/marketplace/azure-purchasing-invoicing 
• Private Offers: https://learn.microsoft.com/azure/marketplace/private-offers 

ABAC

• Azure RBAC Conditions (ABAC): https://learn.microsoft.com/azure/role-based-access-control/conditions-overview 

Azure Policy

• Azure Policy Overview: https://learn.microsoft.com/azure/governance/policy/overview 

CAF RACI

• Cloud Adoption Framework RACI: https://learn.microsoft.com/azure/cloud-adoption-framework/organize/raci-alignment 

Closing Thoughts: Governance as an accelerator, not a constraint

Azure’s permission model can feel overwhelming at first: three planes, three sets of roles, and boundaries that don’t overlap. But once you understand the logic behind Entra (identity), Azure RBAC (resources), and Commerce (billing), everything falls into place.

In reality, Azure’s separation of concerns is not a burden. It’s a design feature that enables:

• safer engineering velocity
• tighter financial control
• cleaner auditability
• least-privilege access by default
• scalable governance as teams grow
• secure collaboration across Engineering, Finance, and Security

The confusion happens when teams try to treat Azure as if it has a single permission system. It doesn’t and it never will. Because identity, billing, and resource deployment are fundamentally different domains that must be operated and secured differently.

But when organizations understand these three planes and structure their roles accordingly, something powerful happens:

• Engineering moves faster.
• Finance gains real oversight.
• Security finally gets a clean, enforceable boundary model.
• Leadership sees clarity instead of chaos.

Good governance doesn’t slow down innovation. Bad governance does. 

The companies that scale successfully, whether AI-native, SaaS platforms, or global digital-first organizations, are the ones that adopt a clean, intentional model early. They treat Azure governance as infrastructure, not bureaucracy.

And the result is the same every time:

• fewer outages
• fewer billing surprises
• fewer permission escalations
• stronger compliance
• and dramatically smoother scaling

Azure’s three permission systems aren’t a problem to solve. They’re a framework to leverage. Once you embrace that model, identity for who, RBAC for what, billing for how you pay, then Azure becomes simpler, safer, and far more predictable.

In the end, the real outcome of good governance is not control. It’s confidence. Confidence to scale. Confidence to innovate. Confidence to grow without surprises. And that’s what this guide is ultimately about: giving your teams the clarity and confidence to build securely and operate effectively on Azure.

If your engineering, finance, or security teams need help applying this model in practice, designing role structures, or building a Landing Zone aligned to your organization’s goals, the next step is simple: start with the three-plane model and everything else becomes easier.