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 adjustment 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 and Privileged Access Manager quotas. Workforce Identity Federation quotas apply to organizations .

Privileged Access Manager quotas are applicable on both projects and organizations, and are charged as follows depending on the target of the call:

• For projects that don't belong to an organization, one unit of project quota is charged for a call.
• For projects belonging to an organization, one unit each of project and organization quotas are charged for a call. A call is denied if either of the two quotas has been exhausted.
• For calls to folders or organizations, one unit of organization quota is charged.

Limits

IAM enforces the following limits on resources. These limits cannot be changed.

¹ If you create custom roles at the project level, those custom roles don't count towards the limit at the organization level.

Also, for the purposes of this limit, each appearance of a domain or Google group is counted as a single principal, regardless of the number of individual members in the domain or group.

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 allow policy.

³ For the purposes of this limit, Cloud Identity domains, Google Workspace accounts, and Google groups are counted as follows:

• For Google groups, each unique group is counted only once, regardless of how many times the group appears in the allow policy. This is different from how groups are counted for the limit on the total number of principals in an allow policy—for that limit, each appearance of a group counts towards the limit.
• For Cloud Identity domains or Google Workspace accounts, IAM counts all appearances of each domain or account in the allow policy's role bindings. It does not deduplicate domains or accounts that appear in more than one role binding.

For example, if your 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 Cloud Identity domains, Google Workspace accounts, or unique groups before you reach the limit.

Alternatively, if your 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 Cloud Identity domains, Google Workspace accounts, or unique groups before you reach the limit.

⁴ 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:my-user@example.com , and this principal appears in 20 deny rules, then you could add another 2,480 principals to the resource's deny policies.

⁵ 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 LifetimeExtension list constraint.