Skip to content
ENExplore Calculators

GCP IAM Calculator

Size a Google Cloud allow policy against the 1500-principal cap, the 250-group sub-limit and 300 custom roles per project.

About GCP IAM Calculator

Google Cloud caps the total principals in one allow policy at 1500, and separately caps how many of those may be groups at 250. Because policies inherit downward and cannot deny, the access that applies to a project is the union of its own policy with every ancestor policy. Hitting the principal cap breaks setIamPolicy for the whole resource, so a single over-populated project policy blocks every subsequent access change until someone refactors it into groups.

Formulas

GCP IAM

utilisation = principals in the allow policy ÷ 1500, with a nested cap of 250 Google groups among those principals.

250
How many of those principals may be Google groups
300
Custom roles per project
1500
Principals allowed in a single allow policy

Inherited access

effective principals = principals bound here + principals inherited from ancestor folders and the organisation.

inheritance
GCP allow policies are additive down the resource hierarchy and cannot be subtracted

Worked example

With the default values below, GCP IAM Calculator returns Principal Utilisation vs 1500 of 42.7%. Change any input above and every figure here is recalculated in your browser.

Inputs used

Principals in the project allow policyaccepts 0–3,000 principals
640 principals
Of those, Google groupsaccepts 0–1,000 groups
120 groups
Role bindings in the policyaccepts 1–3,000 bindings
180 bindings
Custom roles in the projectaccepts 0–600 roles
95 roles
Principals inherited from folder and organisationaccepts 0–3,000 principals
60 principals

Results

Principal Utilisation vs 1500
42.7%
Principals Remaining
860 of 1500
Groups vs the 250 Sub-Limit
48.0%
Custom Roles vs 300 per Project
31.7%
Effective Principals Including Inheritance
700
Average Principals per Binding
3.6
Assessment
Within Google Cloud IAM limits

Step by step

  1. 1Values used
  2. 2GCP IAM
  3. 3Inherited access
  4. 4Principal Utilisation vs 1500= 42.7
  5. 5Principals Remaining= 860 of 1500
  6. 6Groups vs the 250 Sub-Limit= 48.0
  7. 7Custom Roles vs 300 per Project= 31.7
  8. 8Effective Principals Including Inheritance= 700
  9. 9Average Principals per Binding= 3.6

Assumptions and limits

  • The result is derived only from the 5 inputs listed above. Anything not among them is not part of the calculation.
  • In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
  • Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is GCP IAM calculated?

utilisation = principals in the allow policy ÷ 1500, with a nested cap of 250 Google groups among those principals. Google Cloud caps the total principals in one allow policy at 1500, and separately caps how many of those may be groups at 250. Because policies inherit downward and cannot deny, the access that applies to a project is the union of its own policy with every ancestor policy.

Why does GCP IAM matter?

Hitting the principal cap breaks setIamPolicy for the whole resource, so a single over-populated project policy blocks every subsequent access change until someone refactors it into groups.

What values do I need to enter?

This calculator takes 5 inputs: Principals in the project allow policy, Of those, Google groups, Role bindings in the policy, Custom roles in the project, Principals inherited from folder and organisation. 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 reduce principals in a GCP allow policy?

Replace individual user bindings with Google group bindings, bind at folder or organisation level where the access is genuinely broad, remove bindings for deleted principals (they linger as deleted: entries), and use IAM Conditions so one binding covers cases that previously needed several.

Can a project policy take away access granted higher up?

Not with allow policies — they are purely additive, so a project cannot revoke what a folder granted. Restricting inherited access requires deny policies, which are evaluated before allow policies, or organisation policy constraints.

Related Calculators

GCP IAM Calculator – Calculate Principal Utilisation vs 1500