Quotas and limits

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 300 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 500
Deny rules per resource 500
Domains and Google groups in all of a resource's deny policies4 500
Total number of principals (including domains and Google groups) in all of a resource's deny policies4 2500
Deny rules in a single deny policy 500
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 200
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 don't 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 all of the deny policies attached to a resource. It does not deduplicate principals that appear in more than one deny rule or deny policy. For example, if the deny policies attached to a resource contain only deny rules for the principal user:alice@example.com, and this principal appears in 20 deny rules, then you could add another 2,480 principals to the resource's deny policies.

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.allowServiceAccountCredentialLifetimeExtension list constraint.