このページには、Identity and Access Management（IAM）に適用される割り当てと上限の一覧が表示されています。割り当てと上限により、送信できるリクエストの数、または作成できるリソースの数が制限されます。上限では、リソースの属性（リソースの識別子の長さなど）が制限される場合もあります。
与えられた割り当てが少なすぎる場合は、Google Cloud コンソールを使用してプロジェクトの割り当ての増加をリクエストできます。Google Cloud コンソールで特定の割り当ての変更をリクエストできない場合は、Google Cloud サポートにお問い合わせください。
上限の変更はできません。
割り当て
デフォルトでは、Workforce Identity 連携の割り当てを除き、すべての Google Cloud プロジェクトに次の IAM 割り当てが適用されます。Workload Identity 連携の割り当ては組織に適用されます。
| デフォルトの割り当て | |
|---|---|
| IAM API | |
| 読み取りリクエスト（例: ポリシーの取得） | 6,000/分 |
| 書き込みリクエスト（例: ポリシーの更新） | 600/分 |
| 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 |
| Service Account Credentials API | |
| 認証情報の生成リクエスト | 60,000/分 |
| JSON ウェブトークン（JWT）または blob の署名リクエスト | 60,000/分 |
| Security Token Service API | |
| Exchange トークン リクエスト（非 Workforce Identity 連携） | 6,000/分 |
| Exchange トークン リクエスト（Workforce Identity 連携）（プレビュー） | 組織ごとに 60,000/分 |
| サービス アカウント | |
| サービス アカウントの数 | 100 |
上限
IAM では、次の上限がリソースに適用されます。この上限を変更することはできません。
| 上限 | |
|---|---|
| カスタムロール | |
| 組織のカスタムロールの数1 | 300 |
| プロジェクトのカスタムロールの数1 | 300 |
| カスタムロールの ID | 64 バイト |
| カスタムロールのタイトル | 100 バイト |
| カスタムロールの説明 | 300 バイト |
| カスタムロールの権限 | 3,000 |
| カスタムロールのタイトル、説明、権限名の合計サイズ | 64 KB |
| 許可ポリシーとロール バインディング | |
| リソースごとの許可ポリシー | 1 |
| 1 つの許可ポリシー内のすべてのロール バインディングに含まれるドメインと Google グループ2 | 250 |
| 1 つのポリシー内のすべてのロール バインディングおよび監査ロギングの除外に含まれるプリンシパル（ドメインと Google グループを含む）3 | 1,500 |
| 1 つのロール バインディングの条件式に含まれる論理演算子の数 | 12 |
| 同じロールと同じプリンシパルを含むが、条件式が異なる許可ポリシーのロール バインディング | 20 |
| 拒否ポリシーと拒否ルール | |
| リソースごとの拒否ポリシー | 500 |
| リソースあたりの拒否ルールの数 | 500 |
| リソースのすべての拒否ポリシーに含まれるドメインと Google グループ4 | 500 |
| リソースのすべての拒否ポリシーに含まれるプリンシパル（ドメインと Google グループを含む）の合計数4 | 2500 |
| 1 つの拒否ポリシーに含まれる拒否ルール | 500 |
| 1 つの拒否ルールの条件式に含まれる論理演算子 | 12 |
| サービス アカウント | |
| サービス アカウント ID | 30 バイト |
| サービス アカウントの表示名 | 100 バイト |
| 1 つのサービス アカウントが持つサービス アカウント キーの数 | 10 |
| Workforce Identity 連携（プレビュー） | |
| プールごとの Workload Identity プール プロバイダ | 200 |
| プールごとの削除された Workload Identity プール サブジェクト | 100,000 |
| Workload Identity 連携と Workforce Identity 連携（プレビュー）属性のマッピング | |
| マッピングされたサブジェクト | 127 バイト |
| マッピングされた Workforce identity プールユーザーの表示名 | 100 バイト |
| マッピングされた属性の合計サイズ | 8,192 バイト |
| カスタム属性マッピングの数 | 50 |
| 有効時間が短い認証情報 | |
| 認証情報アクセス境界に含まれるアクセス境界ルールの数 | 10 |
| アクセス トークンの最大有効時間5 |
3,600 秒（1 時間） |
1 プロジェクト レベルでカスタムロールを作成した場合、それらのカスタムロールは組織レベルでの上限にカウントされません。
2 この上限において、ドメインと Google グループは次のようにカウントされます。
-
ドメインについては、IAM が許可ポリシーのロール バインディング内の各ドメインのすべての出現をカウントします。複数のロール バインディングに出現するドメインは重複除去されません。たとえば、許可ポリシーに 1 つのドメイン（
domain:example.com）のみが含まれていて、そのドメインが許可ポリシーに 10 回出現している場合、上限に達するまでにさらに 240 個のドメインを追加できます。 -
Google グループの場合、許可ポリシーにグループが出現する回数に関係なく、一意の各グループは 1 回だけカウントされます。たとえば、許可ポリシーに 1 つのグループ（
group:my-group@example.com）のみが含まれ、そのグループが許可ポリシーに 10 回出現している場合、上限に達するまでにさらに 249 個の一意のグループを追加できます。
3
この上限においては、IAM は、許可ポリシーがデータアクセス監査ロギングから除外したプリンシパルと、許可ポリシーのロール バインディング内の各プリンシパルのすべての出現をカウントします複数のロール バインディングに出現するプリンシパルは重複除去されません。たとえば、許可ポリシーにプリンシパル group:my-group@example.com のロール バインディングのみが含まれ、このプリンシパルが 50 個のロール バインディングにある場合、別の 1,450 個のプリンシパルを許可ポリシーのロール バインディングに追加できます。
IAM Conditions を使用するか、通常は識別子の長い多くのプリンシパルにロールを付与すると、ポリシー内のプリンシパルの数を減らすことができます。
4
IAM は、接続されたすべての拒否ポリシーで各プリンシパルの出現をすべてカウントします。複数の拒否ルールまたは拒否ポリシーに出現するプリンシパルは重複除去されません。たとえば、リソースに接続されている拒否ポリシーにプリンシパル user:alice@example.com の拒否ルールのみが含まれ、このプリンシパルが 20 個の拒否ルールに含まれている場合、さらに 2,480 個のプリンシパルをリソースの拒否ポリシーに追加できます。
5 OAuth 2.0 アクセス トークンの場合、最大有効時間を 12 時間（43,200 秒）まで延長できます。最大有効時間を延長するには、トークンの期限を延長する必要があるサービス アカウントを特定し、constraints/iam.allowServiceAccountCredential リスト制約を含む組織のポリシーに追加します。