Skip to content
Calcrivo

Azure RBAC Calculator

Track Azure role assignments against the 4000-per-subscription limit and custom roles against 500 per tenant.

Inputs

assignments
roles
subscriptions
users

Subscription Assignment Utilisation

65.0%

Assignments Remaining

1,400of 4000

Custom Roles vs 500 per Tenant

36.0%

Assignments if Made per User

104,000

Assignments Saved by Group Targeting

101,400

Assignments Across All Subscriptions

15,600

Assessment

Within Azure RBAC limits

Step by step

  1. Values used

    Role assignments in the subscription = 2,600 assignments; Custom roles in the tenant = 180 roles; Subscriptions in the tenant = 6 subscriptions; Assignments target groups rather than users = Yes; Average members per group = 40 users

  2. Azure RBAC

    utilisation = role assignments ÷ 4000 per subscription; a group assignment replaces one assignment per member, so savings = assignments × (members per group − 1).

  3. Tenant-wide assignment footprint

    assignments across the tenant = assignments per subscription × subscriptions.

  4. Subscription Assignment Utilisation

    = 65.0

  5. Assignments Remaining

    = 1,400 of 4000

  6. Custom Roles vs 500 per Tenant

    = 36.0

  7. Assignments if Made per User

    = 104,000

  8. Assignments Saved by Group Targeting

    = 101,400

  9. Assignments Across All Subscriptions

    = 15,600

How it works

Azure counts each role assignment object against a per-subscription limit, and that limit is reached surprisingly often because assignments are made at resource-group and resource scope as well as subscription scope. Targeting a group instead of a user collapses many assignments into one without changing effective access. When a subscription hits 4000 assignments, new access requests simply fail, and the fix — re-modelling hundreds of user assignments onto groups — is a project rather than a ticket.

Formulas

Azure RBAC

utilisation = role assignments ÷ 4000 per subscription; a group assignment replaces one assignment per member, so savings = assignments × (members per group − 1).

500
Custom role definitions per tenant
4000
Role assignments allowed per Azure subscription
members
Users behind a single group assignment

Tenant-wide assignment footprint

assignments across the tenant = assignments per subscription × subscriptions.

subscriptions
Each carries its own independent 4000-assignment budget

Frequently Asked Questions

How is Azure RBAC calculated?

utilisation = role assignments ÷ 4000 per subscription; a group assignment replaces one assignment per member, so savings = assignments × (members per group − 1). Azure counts each role assignment object against a per-subscription limit, and that limit is reached surprisingly often because assignments are made at resource-group and resource scope as well as subscription scope. Targeting a group instead of a user collapses many assignments into one without changing effective access.

Why does Azure RBAC matter?

When a subscription hits 4000 assignments, new access requests simply fail, and the fix — re-modelling hundreds of user assignments onto groups — is a project rather than a ticket.

What values do I need to enter?

This calculator takes 5 inputs: Role assignments in the subscription, Custom roles in the tenant, Subscriptions in the tenant, Assignments target groups rather than users, Average members per group. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

How do I stay under the Azure role assignment limit?

Assign roles to Microsoft Entra groups instead of individual users, prefer assignments at management-group or subscription scope over dozens of resource-scope assignments, remove assignments for deleted principals, and use Privileged Identity Management for eligible rather than permanent access so short-lived assignments do not accumulate.

Do inherited assignments count against the subscription limit?

No. An assignment created at management-group scope is counted against that management group, not against every subscription beneath it — which is exactly why moving broad access up the hierarchy is the fastest way to reclaim subscription headroom.

You might also need