本页面上的部分或全部信息可能不适用于 Trusted Cloud by S3NS。
配额和限制
本页面列出了适用于身份和访问权限管理 (IAM) 的配额和限制。配额和限制都能限制您可以发送的请求数量或可以创建的资源数量。限制还可能会约束资源的特性，例如资源标识符的长度。
如果配额太低，无法满足您的需求，您可以使用 Trusted Cloud 控制台为您的项目申请调整配额。如果Trusted Cloud 控制台不允许您申请更改特定配额，请与 Trusted Cloud by S3NS 支持团队联系。
限制不能更改。
配额
默认情况下，以下 IAM 配额适用于每个Trusted Cloud 项目，员工身份联合和 Privileged Access Manager 配额除外。员工身份联合配额适用于组织。
Privileged Access Manager 配额适用于项目和组织，并根据调用的目标按以下方式收费：
- 对于不属于组织的项目，系统会针对调用收取一个单位的项目配额。
- 对于属于某个组织的项目，系统会针对每个项目和组织配额收取一个单位的配额。如果这两项配额中的任一项用尽，系统会拒绝调用。
- 对于对文件夹或组织的调用，系统会收取一个单位的组织配额。
| 默认配额 |
| IAM v1 API |
| 读取请求数（例如获取允许政策） |
每个项目每分钟 6,000 次 |
| 写入请求数（例如更新允许政策） |
每个项目每分钟 600 次 |
| IAM v2 API |
| 读取请求数（例如获取拒绝政策） |
每个项目每分钟 5 次 |
| 写入请求数（例如更新拒绝政策） |
每个项目每分钟 5 次 |
| IAM v3 API |
| 读取请求数（例如获取主账号访问权限边界政策） |
每个项目每分钟 5 次 |
| 写入请求（例如更新主账号访问权限边界政策） |
每个项目每分钟 5 次 |
| 工作负载身份联合 |
| 读取请求数（例如获取工作负载身份池） |
每个项目每分钟 600
每个客户端每分钟 6000 |
| 写入请求数（例如更新工作负载身份池） |
每个项目每分钟 60
每个客户端每分钟 600 |
| 员工身份联合 |
| 创建/删除/恢复删除请求数 |
每个组织每分钟 60 次 |
| 读取请求数（例如获取员工身份池） |
每个组织每分钟 120 次 |
| 更新请求数（例如更新员工身份池） |
每个组织每分钟 120 次 |
| 主题删除/恢复删除请求数（例如删除员工身份池主题） |
每个组织每分钟 60 次 |
| 员工身份池数量 |
每个组织 100 个 |
| 员工 OAuth 应用 |
| 创建/读取/更新/删除/恢复删除请求数 |
每个项目每分钟 60 次 |
| Service Account Credentials API |
| 要求生成凭据的请求数 |
每个项目每分钟 60,000 次 |
| 要求对 JSON Web 令牌 (JWT) 或 blob 签名的请求数 |
每个项目每分钟 60,000 次 |
| Security Token Service API |
| 交换令牌请求数（非员工身份联合） |
每个项目每分钟 6,000 次 |
| 交换令牌请求数（员工身份联合） |
每个组织每分钟 1,000 次 |
| 服务账号 |
| 服务账号数 |
每个项目 100 次 |
CreateServiceAccount 请求 |
因项目而异。如需查看项目的配额，请在 Trusted Cloud 控制台中查看项目的配额，然后搜索每分钟按凭证创建服务账号的请求数。
|
| Privileged Access Manager API |
| 使用权写入请求（例如，创建、更新或删除使用权） |
每个项目每分钟 100 次
每个组织每分钟 100 次 |
CheckOnboardingStatus 请求 |
每个项目每分钟 300 次
每个组织每分钟 900 次 |
ListEntitlements 请求 |
每个项目每分钟 600 次
每个组织每分钟 1800 次 |
SearchEntitlements 请求 |
每个项目每分钟 600 次
每个组织每分钟 1800 次 |
GetEntitlement 请求 |
每个项目每分钟 3000 次
每个组织每分钟 9000 次 |
ListGrants 请求 |
每个项目每分钟 600 次
每个组织每分钟 1800 次 |
SearchGrants 请求 |
每个项目每分钟 600 次
每个组织每分钟 1800 次 |
GetGrant 请求 |
每个项目每分钟 3000 次
每个组织每分钟 9000 次 |
CreateGrant 请求 |
每个项目每分钟 200 次
每个组织每分钟 600 次 |
ApproveGrant 请求 |
每个项目每分钟 200 次
每个组织每分钟 600 次 |
DenyGrant 请求 |
每个项目每分钟 200 次
每个组织每分钟 600 次 |
RevokeGrant 请求 |
每个项目每分钟 300 次
每个组织每分钟 900 次 |
GetOperation 请求 |
每个项目每分钟 600 次
每个组织每分钟 1800 次 |
ListOperations 请求 |
每个项目每分钟 300 次
每个组织每分钟 900 次 |
限制
IAM 对资源实施以下限制。这些限制无法更改。
| 限制 |
| 自定义角色 |
| 一个组织的自定义角色数1 |
300 |
| 一个项目的自定义角色数1 |
300 |
| 自定义角色的 ID |
64 字节 |
| 自定义角色的名称 |
100 个字节 |
| 自定义角色的描述 |
300 个字节 |
| 自定义角色中的权限 |
3000 |
| 自定义角色的名称、描述和权限名称的总大小
|
64 KB |
| 允许政策和角色绑定 |
| 每项资源允许的政策数量 |
1 |
| 单项政策中的所有角色绑定和审核日志记录豁免的主账号 总数2 |
1,500 |
| 角色绑定的条件表达式中的逻辑运算符数 |
12 |
|
允许政策中包括同一角色和同一主账号但条件表达式不同的角色绑定数 |
20 |
| 拒绝政策和拒绝规则 |
| 每项资源的拒绝政策数 |
500 |
| 每项资源的拒绝规则数 |
500 |
| 资源的所有拒绝政策中的主账号 总数
3
|
2500 |
| 单个拒绝政策中的拒绝规则数 |
500 |
| 拒绝规则的条件表达式中的逻辑运算符数 |
12 |
| Principal Access Boundary Policy |
| 单个主账号访问权限边界政策中的规则 |
500 |
| 单个主账号访问权限边界政策中所有规则中的资源 |
500 |
|
可绑定到资源的主账号访问权限边界政策数量 |
10 |
| 每个组织的主账号访问权限边界政策 |
1000 |
| 政策绑定的条件表达式中的逻辑运算符数 |
10 |
| 服务账号 |
| 服务账号 ID |
30 个字节 |
| 服务账号显示名 |
100 个字节 |
| 服务账号的服务账号密钥数 |
10 |
| 员工身份联合 |
| 每个池的员工身份池提供方数量 |
200 |
| 每个池的已删除员工身份池主题数 |
100000 |
| 员工 OAuth 应用 |
| 每个项目的员工 OAuth 客户端 |
100 |
| 每个客户端的员工 OAuth 客户端凭据 |
10 |
| 工作负载身份联合和员工身份联合属性映射 |
| 映射的主题 |
127 个字节 |
| 映射的员工身份池用户显示名 |
100 个字节 |
| 映射属性的总大小 |
8192 个字节 |
| 自定义属性映射的数量 |
50 |
| 短期凭据 |
| 访问令牌的最长有效期
4
|
3600 秒（1 小时）
|
1 如果您在项目级别创建自定义角色，这些自定义角色不会计入组织级别的限额。
2 对于此限制而言，IAM 会统计
允许政策的角色绑定中每个主账号的所有出现次数，以及允许政策
从数据访问审核日志中排除的主账号，而不会去除重复出现在多个绑定中的主账号。
例如，如果允许政策仅包含主账号
principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com 的角色绑定，并且此主账号出现在 50 个角色绑定中，则您可以向允许政策中的角色绑定添加另外 1,450 个主账号。
此外，对于此限制而言，无论主账号集中的单个成员数量是多少，只要主账号集出现一次，就算作一个主账号。
如果您使用 IAM Conditions，或者为具有异常长的标识符的多个主账号授予角色，则 IAM 可能允许的允许政策中的主账号较少。
3
IAM 会统计每个主账号在附加到某个资源的所有拒绝政策中的所有出现次数。但不会去除重复出现在多个拒绝规则或拒绝政策中的主账号。例如，如果附加到某个资源的拒绝政策仅包含主账号 principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com 的拒绝规则，并且此主账号出现在 20 个拒绝规则中，则您可以再将 2,480 个主账号添加到该资源的拒绝政策中。
4
对于 OAuth 2.0 访问令牌，您可以将最长有效期延长至 12 小时（43200 秒）。如需延长最长有效期，请确定需要延长令牌有效期的服务账号，然后将这些服务账号添加到包含 constraints/iam.allowServiceAccountCredentialLifetimeExtension 列表限制条件的组织政策。
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-08-21。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-21。"],[[["\u003cp\u003eThis document outlines the quotas and limits for Identity and Access Management (IAM) in Google Cloud, which govern the number of requests and resources allowed.\u003c/p\u003e\n"],["\u003cp\u003eQuotas are adjustable, allowing users to request increases through the Google Cloud console or by contacting Google Cloud support, whereas limits are fixed and cannot be changed.\u003c/p\u003e\n"],["\u003cp\u003eDifferent API versions (v1, v2, v3), along with features like Workload/Workforce Identity Federation and Privileged Access Manager, each have their own specific quotas for read and write requests, as detailed in the document.\u003c/p\u003e\n"],["\u003cp\u003eIAM enforces various limits on resources, such as the number of custom roles, allow/deny policies, principals, service accounts, and the size and number of attributes.\u003c/p\u003e\n"],["\u003cp\u003eThe document contains specific limitations for allow policies that contain principals, domains and Google groups, as well as deny policies that have a different scope, alongside principal access boundary policies.\u003c/p\u003e\n"]]],[],null,["# Quotas and limits\n\n\u003cbr /\u003e\n\nThis page lists the quotas and limits that apply to Identity and Access Management\n(IAM). Both quotas and limits can restrict the number of\nrequests that you can send or the number of resources that you can create.\nLimits can also restrict a resource's attributes, such as the length of the\nresource's identifier.\n\nIf a quota is too low to meet your needs, you can use the Google Cloud console to\n[request a quota adjustment](/docs/quotas/help/request_increase) for your project. If the\nGoogle Cloud console does not let you request a change for a specific quota,\n[contact Google Cloud support](/support/docs).\n\nLimits cannot be changed.\n\nQuotas\n------\n\nBy default, the following IAM quotas apply to every\nGoogle Cloud project, with the exception of Workforce Identity Federation and\nPrivileged Access Manager quotas. Workforce Identity Federation quotas apply to\n[organizations](/resource-manager/docs/cloud-platform-resource-hierarchy#organizations).\n\n\nPrivileged Access Manager quotas are applicable on both projects and organizations, and are\ncharged as follows depending on the target of the call:\n\n- For projects that don't belong to an organization, one unit of project quota is charged for a call.\n- 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.\n- For calls to folders or organizations, one unit of organization quota is charged.\n\n\u003cbr /\u003e\n\nLimits\n------\n\nIAM enforces the following limits on resources. These limits\ncannot be changed.\n\n^1^ If you create custom roles at the project level, those custom roles\ndon't count towards the limit at the organization level.\n^2^ 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\naudit logging](/logging/docs/audit/configure-data-access#config-console-exempt). 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 `user:my-user@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.\n\n\u003cbr /\u003e\n\n\nAlso, for the purposes of this limit, each appearance of a domain or Google group is counted as a\nsingle principal, regardless of the number of individual members in the domain or group.\n\n\nIf you use IAM Conditions, or if you grant roles to many principals with unusually\nlong identifiers, then IAM might allow fewer principals in the allow policy.\n\n\n^3^\n\nFor the purposes of this limit, Cloud Identity domains, Google Workspace accounts, and Google\ngroups are counted as follows:\n\n- 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.\n- 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.\n\n\nFor example, if your allow policy contains only one group,\n`group:my-group@example.com`, and the group appears in the allow policy\n10 times, then you can add another 249\nCloud Identity domains, Google Workspace accounts, or unique groups before you reach the\nlimit.\n\n\nAlternatively, if your allow policy contains only one domain, `domain:example.com`, and\nthe domain appears in the allow policy\n10 times, then you can add another\n240 Cloud Identity domains, Google Workspace accounts, or unique\ngroups before you reach the limit.\n\n\n^4^\n\n\nIAM counts *all* appearances of each principal in all\nof the deny policies attached to a resource. It does *not* deduplicate principals that appear\nin more than one deny rule or deny policy. For example, if the deny policies attached to a resource\ncontain only deny rules for the principal `user:my-user@example.com`, and this principal appears in\n20 deny rules, then you could add another\n2,480 principals to the resource's deny\npolicies.\n\n\n^5^\n\nFor OAuth 2.0 access tokens, you can extend the maximum lifetime to\n12 hours\n(43,200 seconds). To extend the maximum lifetime,\nidentify the service accounts that need an extended lifetime for tokens, then\n[add these service accounts to an organization policy](/resource-manager/docs/organization-policy/restricting-service-accounts#setting_a_list_constraint) that\nincludes the\n`constraints/iam.allowServiceAccountCredential``LifetimeExtension`\nlist constraint."]]
