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.
Quotas
By default, the following IAM quotas apply to every Google Cloud project, with the exception of workforce identity federation quotas. Workforce identity federation quotas apply to organizations.
Default quotas | |
---|---|
IAM API | |
Read requests (for example, getting a policy) | 6,000 per minute |
Write requests (for example, updating a policy) | 600 per minute |
Workload identity federation | |
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 |
Workforce identity federation (Preview) | |
Create/delete/undelete requests | 60 per organization per minute |
Read requests (for example, getting a workforce identity pool) | 120 per organization per minute |
Update requests (for example, updating a workforce identity pool) | 120 per organization per minute |
Subject delete/undelete requests (for example, deleting a workforce identity pool subject) | 60 per organization per minute |
Workforce identity pools per organization | 100 |
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 (non-workforce identity federation) | 6,000 per minute |
Exchange token requests (workforce identity federation) (Preview) | 60,000 per organization per minute |
Service accounts | |
Number of service accounts | 100 |
Limits
IAM enforces the following limits on resources. These limits cannot be changed.
Limits | |
---|---|
Custom roles | |
Custom roles for an organization1 | 300 |
Custom roles for a project1 | 300 |
ID of a custom role | 64 bytes |
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 | |
Allow policies per resource | 1 |
Domains and Google groups in all role bindings within a single allow policy2 | 250 |
Total number of principals (including domains and Google groups) in all role bindings and audit-logging exemptions 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 accounts | |
Service account ID | 30 bytes |
Service account display name | 100 bytes |
Service account keys for a service account | 10 |
Workforce identity federation (Preview) | |
Workforce identity pool providers per pool | 25 |
Deleted workforce identity pool subjects per pool | 100,000 |
Workload identity federation and workforce identity federation (Preview) attribute mapping | |
Mapped subject | 127 bytes |
Mapped workforce identity pool user display name | 100 bytes |
Mapped attributes total size | 8,192 bytes |
Number of custom attribute mappings | 50 |
Short-lived credentials | |
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:my-group@example.com
, and the group appears in the allow policy 10 times, then you can add another 249 unique groups before you reach the limit.
3
For the purposes of this limit, IAM counts all appearances of each
principal in the allow policy's role bindings, as well as the principals that the allow policy
exempts from Data Access
audit logging. 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:my-group@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.
4
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:alice@example.com
, 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
12 hours
(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
includes the
constraints/iam.allowServiceAccountCredential
list constraint.