このページの一部またはすべての情報は、S3NS の Trusted Cloud に適用されない場合があります。
割り当てと上限
このページには、Identity and Access Management(IAM)に適用される割り当てと上限の一覧が表示されています。割り当てと上限により、送信できるリクエストの数、または作成できるリソースの数が制限されます。上限では、リソースの属性(リソースの識別子の長さなど)が制限される場合もあります。
割り当てがニーズを満たすには少なすぎる場合は、 Trusted Cloud コンソールを使用してプロジェクトの割り当ての調整をリクエストできます。Trusted Cloud コンソールで特定の割り当ての変更をリクエストできない場合は、 Trusted Cloud by S3NS サポートにお問い合わせください。
上限の変更はできません。
割り当て
デフォルトでは、Workforce Identity 連携と Privileged Access Manager の割り当てを除き、すべてのTrusted Cloud プロジェクトに次の IAM 割り当てが適用されます。Workload Identity 連携の割り当ては組織に適用されます。
Privileged Access Manager の割り当てはプロジェクトと組織の両方に適用され、呼び出しの対象に応じて次のように課金されます。
- 組織に属していないプロジェクトの場合、呼び出しごとに 1 ユニットのプロジェクト割り当てが課金されます。
- 組織に属するプロジェクトの場合、呼び出しごとにプロジェクトと組織の割り当てがそれぞれ 1 ユニット単位で課金されます。2 つの割り当てのいずれかがすべて消費されている場合、呼び出しは拒否されます。
- フォルダまたは組織への呼び出しの場合、組織の割り当て量が 1 ユニット分課金されます。
デフォルトの割り当て |
IAM v1 API |
読み取りリクエスト(例: 許可ポリシーの取得) |
プロジェクトあたり毎分 6,000 回 |
書き込みリクエスト(例: 許可ポリシーの更新) |
プロジェクトあたり毎分 600 回 |
IAM v2 API |
読み取りリクエスト(例: 拒否ポリシーの取得) |
プロジェクトあたり毎分 5 回 |
書き込みリクエスト(例: 拒否ポリシーの更新) |
プロジェクトあたり毎分 5 回 |
IAM v3 API |
読み取りリクエスト(例: プリンシパル アクセス境界ポリシーの取得) |
プロジェクトあたり毎分 5 回 |
書き込みリクエスト(例: プリンシパル アクセス境界ポリシーの更新) |
プロジェクトあたり毎分 5 回 |
Workload Identity 連携 |
読み取りリクエスト(例: Workload Identity プールの取得) |
プロジェクトあたり毎分 600 クライアントあたり毎分 6,000 |
書き込みリクエスト(例: Workload Identity プールの更新) |
プロジェクトあたり毎分 60 クライアントあたり毎分 600 |
Workforce Identity 連携 |
リクエストの作成、削除、削除の取り消し |
組織ごとに 60/分 |
読み取りリクエスト(例: Workforce Identity プールの取得) |
組織ごとに 120/分 |
更新リクエスト(Workload Identity プールの更新など) |
組織ごとに 120/分 |
サブジェクトの削除、削除取り消しリクエスト(Workload Identity プール サブジェクトの削除など) |
組織ごとに 60/分 |
Workforce Identity プールの数 |
組織ごとに 100 |
Workforce OAuth アプリケーション |
リクエストの作成、読み取り、更新、削除、削除の取り消し |
プロジェクトあたり毎分 60 回 |
Service Account Credentials API |
認証情報の生成リクエスト |
プロジェクトあたり毎分 60,000 回 |
JSON ウェブトークン(JWT)または blob の署名リクエスト |
プロジェクトあたり毎分 60,000 回 |
Security Token Service API |
Exchange トークン リクエスト(非 Workforce Identity 連携) |
プロジェクトあたり毎分 6,000 回 |
トークン交換リクエスト(Workforce Identity 連携) |
組織ごとに 1,000/分 |
サービス アカウント |
サービス アカウントの数 |
プロジェクトごとに 100 |
CreateServiceAccount リクエスト |
プロジェクトによって異なります。プロジェクトの割り当てを表示するには、 Trusted Cloud コンソールでプロジェクトの割り当てを表示し、認証情報あたりのサービス アカウント作成リクエスト(分)を検索します。 |
Privileged Access Manager API |
利用資格の書き込みリクエスト(例: 利用資格の作成、更新、削除) |
プロジェクトごとに 1 分あたり 100 回
組織ごとに 1 分あたり 100 回 |
CheckOnboardingStatus リクエスト |
プロジェクトごとに 1 分あたり 300 回
組織ごとに 1 分あたり 900 回 |
ListEntitlements リクエスト |
プロジェクトごとに 1 分あたり 600 回
組織ごとに 1 分あたり 1,800 回 |
SearchEntitlements リクエスト |
プロジェクトごとに 1 分あたり 600 回
組織ごとに 1 分あたり 1,800 回 |
GetEntitlement リクエスト |
プロジェクトごとに 1 分あたり 3,000 回
組織ごとに 1 分あたり 9,000 回 |
ListGrants リクエスト |
プロジェクトごとに 1 分あたり 600 回
組織ごとに 1 分あたり 1,800 回 |
SearchGrants リクエスト |
プロジェクトごとに 1 分あたり 600 回
組織ごとに 1 分あたり 1,800 回 |
GetGrant リクエスト |
プロジェクトごとに 1 分あたり 3,000 回
組織ごとに 1 分あたり 9,000 回 |
CreateGrant リクエスト |
プロジェクトごとに 1 分あたり 200 回
組織ごとに 1 分あたり 600 回 |
ApproveGrant リクエスト |
プロジェクトごとに 1 分あたり 200 回
組織ごとに 1 分あたり 600 回 |
DenyGrant リクエスト |
プロジェクトごとに 1 分あたり 200 回
組織ごとに 1 分あたり 600 回 |
RevokeGrant リクエスト |
プロジェクトごとに 1 分あたり 300 回
組織ごとに 1 分あたり 900 回 |
GetOperation リクエスト |
プロジェクトごとに 1 分あたり 600 回
組織ごとに 1 分あたり 1,800 回 |
ListOperations リクエスト |
プロジェクトごとに 1 分あたり 300 回
組織ごとに 1 分あたり 900 回 |
上限
IAM では、次の上限がリソースに適用されます。この上限を変更することはできません。
上限 |
カスタムロール |
組織のカスタムロールの数1 |
300 |
プロジェクトのカスタムロールの数1 |
300 |
カスタムロールの ID |
64 バイト |
カスタムロールのタイトル |
100 バイト |
カスタムロールの説明 |
300 バイト |
カスタムロールの権限 |
3,000 |
カスタムロールのタイトル、説明、権限名の合計サイズ |
64 KB |
許可ポリシーとロール バインディング |
リソースごとの許可ポリシー |
1 |
1 つのポリシー内のすべてのロール バインディングおよび監査ロギングの除外に含まれるプリンシパル 2 |
1,500 |
1 つのロール バインディングの条件式に含まれる論理演算子の数 |
12 |
同じロールと同じプリンシパルを含むが、条件式が異なる許可ポリシーのロール バインディング
|
20 |
拒否ポリシーと拒否ルール |
リソースごとの拒否ポリシー |
500 |
リソースあたりの拒否ルールの数 |
500 |
リソースのすべての拒否ポリシーに含まれるプリンシパル の合計数
3
|
2500 |
1 つの拒否ポリシーに含まれる拒否ルール |
500 |
1 つの拒否ルールの条件式に含まれる論理演算子 |
12 |
プリンシパル アクセス境界ポリシー |
単一のプリンシパル アクセス境界ポリシーのルール |
500 |
単一のプリンシパル アクセス境界ポリシーのすべてのルールのリソース |
500 |
リソースにバインドできるプリンシパル アクセス境界ポリシーの数 |
10 |
組織ごとのプリンシパル アクセス境界ポリシー |
1000 |
1 つのポリシー バインディングの条件式に含まれる論理演算子の数 |
10 |
サービス アカウント |
サービス アカウント ID |
30 バイト |
サービス アカウントの表示名 |
100 バイト |
1 つのサービス アカウントが持つサービス アカウント キーの数 |
10 |
Workforce Identity 連携 |
プールごとの Workload Identity プール プロバイダ |
200 |
プールごとの削除された Workload Identity プール サブジェクト |
100,000 |
Workforce OAuth アプリケーション |
プロジェクトあたりの Workforce OAuth クライアント |
100 |
クライアントあたりの Workforce OAuth クライアント認証情報 |
10 |
Workload Identity 連携と Workforce Identity 連携(プレビュー)属性のマッピング |
マッピングされたサブジェクト |
127 バイト |
マッピングされた Workforce identity プールユーザーの表示名 |
100 バイト |
マッピングされた属性の合計サイズ |
8,192 バイト |
カスタム属性マッピングの数 |
50 |
有効時間が短い認証情報 |
アクセス トークンの最大有効時間
4
|
3,600 秒(1 時間)
|
1 プロジェクト レベルでカスタムロールを作成した場合、それらのカスタムロールは組織レベルでの上限にカウントされません。
2
この上限においては、IAM は、許可ポリシーが
データアクセス監査ロギングから除外したプリンシパルと、許可ポリシーのロール バインディング内の各プリンシパルのすべての出現をカウントします
複数のロール バインディングに出現するプリンシパルは重複除去されません。
たとえば、許可ポリシーにプリンシパル
principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com
のロール バインディングのみが含まれ、このプリンシパルが 50 個のロール バインディングにある場合、別の 1,450 個のプリンシパルを許可ポリシーのロール バインディングに追加できます。
また、この上限において、プリンシパル セットは、セット内の個々のメンバーの数に関係なく、1 つのプリンシパルとしてカウントされます。
IAM Conditions を使用するか、通常は識別子の長い多くのプリンシパルにロールを付与すると、許可ポリシー内のプリンシパルの数を減らすことができます。
3
IAM は、接続されたすべての拒否ポリシーで各プリンシパルの出現をすべてカウントします。複数の拒否ルールまたは拒否ポリシーに出現するプリンシパルは重複除去されません。たとえば、リソースに接続されている拒否ポリシーにプリンシパル principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com
の拒否ルールのみが含まれ、このプリンシパルが 20 個の拒否ルールに含まれている場合、さらに 2,480 個のプリンシパルをリソースの拒否ポリシーに追加できます。
4
OAuth 2.0 アクセス トークンの場合、最大有効時間を 12 時間(43,200 秒)まで延長できます。最大有効時間を延長するには、トークンの期限を延長する必要があるサービス アカウントを特定し、constraints/iam.allowServiceAccountCredentialLifetimeExtension
リスト制約を含む組織のポリシーに追加します。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-08-23 UTC。
[[["わかりやすい","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"]],["最終更新日 2025-08-23 UTC。"],[[["\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."]]