このページには、Identity and Access Management（IAM）に適用される割り当てと上限の一覧が表示されています。割り当てと上限により、送信できるリクエストの数、または作成できるリソースの数が制限されます。上限では、リソースの属性（リソースの識別子の長さなど）が制限される場合もあります。
与えられた割り当てが少なすぎる場合は、Google Cloud コンソールを使用してプロジェクトの割り当ての増加をリクエストできます。Google Cloud コンソールで特定の割り当ての変更をリクエストできない場合は、Google Cloud サポートにお問い合わせください。
上限の変更はできません。
割り当て
デフォルトでは、Workforce Identity 連携と Privileged Access Manager の割り当てを除き、すべての Google 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 |
| 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 つのポリシー内のすべてのロール バインディングおよび監査ロギングの除外に含まれるプリンシパル（ドメインと Google グループを含む）2 | 1,500 |
| 1 つの許可ポリシー内のすべてのロール バインディングに含まれるドメインと Google グループ3 | 250 |
| 1 つのロール バインディングの条件式に含まれる論理演算子の数 | 12 |
| 同じロールと同じプリンシパルを含むが、条件式が異なる許可ポリシーのロール バインディング | 20 |
| 拒否ポリシーと拒否ルール | |
| リソースごとの拒否ポリシー | 500 |
| リソースあたりの拒否ルールの数 | 500 |
| リソースのすべての拒否ポリシーに含まれるドメインと Google グループ4 | 500 |
| リソースのすべての拒否ポリシーに含まれるプリンシパル（ドメインと Google グループを含む）の合計数4 | 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 |
| 有効時間が短い認証情報 | |
| 認証情報アクセス境界に含まれるアクセス境界ルールの数 | 10 |
| アクセス トークンの最大有効時間5 |
3,600 秒（1 時間） |
1 プロジェクト レベルでカスタムロールを作成した場合、それらのカスタムロールは組織レベルでの上限にカウントされません。
2 この上限においては、IAM は、許可ポリシーがデータアクセス監査ロギングから除外したプリンシパルと、許可ポリシーのロール バインディング内の各プリンシパルのすべての出現をカウントします複数のロール バインディングに出現するプリンシパルは重複除去されません。たとえば、許可ポリシーにプリンシパルuser:sample-user@example.com のロール バインディングのみが含まれ、このプリンシパルが 50 個のロール バインディングにある場合、別の 1,450 個のプリンシパルを許可ポリシーのロール バインディングに追加できます。
また、この上限において、ドメインまたは Google グループは、ドメインまたはグループ内の個々のメンバーの数に関係なく、1 つのプリンシパルとしてカウントされます。
IAM Conditions を使用するか、通常は識別子の長い多くのプリンシパルにロールを付与すると、許可ポリシー内のプリンシパルの数を減らすことができます。
3 この上限において、Cloud Identity ドメイン、Google Workspace アカウント、Google グループは次のようにカウントされます。
- Google グループの場合、許可ポリシーにグループが出現する回数に関係なく、一意の各グループは 1 回だけカウントされます。これは、許可ポリシーのプリンシパルの総数に対するグループのカウント方法とは異なります。この制限では、グループの出現回数に応じて制限が適用されます。
- Cloud Identity ドメインまたは Google Workspace アカウントの場合、IAM は許可ポリシーのロール バインディング内の各ドメインまたはアカウントのすべての出現をカウントします。複数のロール バインディングに出現するドメインまたはアカウントは重複除去されません。
たとえば、許可ポリシーに 1 つのグループ（group:my-group@example.com）のみが含まれ、そのグループが許可ポリシーに 10 回出現している場合、上限に達するまでにさらに 249 個の Cloud Identity ドメイン、Google Workspace アカウント、一意のグループを追加できます。
また、許可ポリシーに 1 つのドメイン（domain:example.com）のみが含まれていて、そのドメインが許可ポリシーに 10 回出現している場合、上限に達するまでにさらに 240 個の Cloud Identity ドメイン、Google Workspace アカウント、または一意のグループを追加できます。
4
IAM は、接続されたすべての拒否ポリシーで各プリンシパルの出現をすべてカウントします。複数の拒否ルールまたは拒否ポリシーに出現するプリンシパルは重複除去されません。たとえば、リソースに接続されている拒否ポリシーにプリンシパル user:alice@example.com の拒否ルールのみが含まれ、このプリンシパルが 20 個の拒否ルールに含まれている場合、さらに 2,480 個のプリンシパルをリソースの拒否ポリシーに追加できます。
5 OAuth 2.0 アクセス トークンの場合、最大有効時間を 12 時間（43,200 秒）まで延長できます。最大有効時間を延長するには、トークンの期限を延長する必要があるサービス アカウントを特定し、constraints/iam.allowServiceAccountCredential リスト制約を含む組織のポリシーに追加します。