This page lists the quotas and limits that apply to Identity and Access Management (IAM). Both quotas and limits can restrict the number of requests that you can send or the number of resources that you can create. Limits can also restrict a resource's attributes, such as the length of the resource's identifier.
If a quota is too low to meet your needs, you can use the Google Cloud console to request a quota increase for your project. If the Google Cloud console does not let you request a change for a specific quota, contact Google Cloud support.
Limits cannot be changed.
By default, the following IAM quotas apply to each Google Cloud project:
|Read requests (for example, getting a policy)||6,000 per minute|
|Write requests (for example, updating a policy)||600 per minute|
|Workload identity pools|
|Read requests (for example, getting a workload identity pool)||600 per project per minute
6,000 per client per minute
|Write requests (for example, updating a workload identity pool)||60 per project per minute
600 per client per minute
|Service Account Credentials API|
|Requests to generate credentials||60,000 per minute|
|Requests to sign a JSON Web Token (JWT) or blob||60,000 per minute|
|Security Token Service API|
|Exchange token requests||6,000 per minute|
|Number of service accounts||100|
IAM enforces the following limits on resources. These limits cannot be changed.
|Custom roles for an organization1||300|
|Custom roles for a project1||300|
|Title of a custom role||100 bytes|
|Description of a custom role||256 bytes|
|Permissions in a custom role||3,000|
|Total size of the title, description, and permission names for a custom role||64 KB|
|Allow policies and role bindings|
|Domains and Google groups in all role bindings within a single allow policy2||250|
|Total number of principals (including Google groups) in all role bindings within a single policy3||1,500|
|Logic operators in a role binding's condition expression||12|
|Role bindings in an allow policy that include the same role and the same principal, but different condition expressions||20|
|Deny policies and deny rules|
|Deny policies per resource||5|
|Domains and Google groups in all deny rules within a single deny policy4||100|
|Total number of principals (including domains and Google groups) in all deny rules within a single deny policy4||500|
|Deny rules in a single deny policy||100|
|Logic operators in a deny rule's condition expression||12|
|Service account ID||30 bytes|
|Service account display name||100 bytes|
|Service account keys for a service account||10|
|Access boundary rules in a Credential Access Boundary||10|
|Maximum lifetime of an access token5||
3,600 seconds (1 hour)
1 If you create custom roles at the project level, those custom roles do not count towards the limit at the organization level.
2 For the purposes of this limit, domains and Google groups are counted as follows:
For domains, IAM counts all appearances of each domain in the allow
policy's role bindings. It does not deduplicate domains that appear in more than one
role binding. For example, if an allow policy contains only one domain,
domain:example.com, and the domain appears in the allow policy 10 times, then you can add another 240 domains before you reach the limit.
For Google groups, each unique group is counted only once, regardless of how many times the
group appears in the allow policy. For example, if an allow policy contains only one group,
group:firstname.lastname@example.org, and the group appears in the allow policy 10 times, then you can add another 249 unique groups before you reach the limit.
For the purposes of this limit, IAM counts all appearances of each
principal in the allow policy's role bindings. It does not deduplicate principals that
appear in more than one role binding. For example, if an allow policy contains only role bindings
for the principal
group:email@example.com, and this principal appears in
50 role bindings, then you can add another
1,450 principals to the role bindings in the allow policy.
If you use IAM Conditions, or if you grant roles to many principals with unusually long identifiers, then IAM might allow fewer principals in the policy.
IAM counts all appearances of each principal in the deny policy's deny
rules. It does not deduplicate principals that appear in more than one deny rule. For
example, if a deny policy contains only deny rules for the principal
user:firstname.lastname@example.org, and this principal appears in
20 deny rules, then you could add another
480 principals to the deny rules in the deny policy.
5 For OAuth 2.0 access tokens, you can extend the maximum lifetime to
(43,200 seconds). To extend the maximum lifetime,
identify the service accounts that need an extended lifetime for tokens, then
add these service accounts to an organization policy that