このページの一部またはすべての情報は、S3NS の Trusted Cloud に適用されない場合があります。
割り当てと上限
このドキュメントでは、VPC Service Controls に適用される割り当てと上限について説明します。このドキュメントに示されている割り当てと上限は変更される場合があります。
割り当ての使用の計算は、自動適用モードとドライラン モードの使用の合計に基づいて行われます。たとえば、サービス境界が自動適用モードで 5 つのリソースを保護し、ドライラン モードで 7 つのリソースを保護している場合は、両方の合計(12)が、対応する上限と比較されます。また、個々のエントリはそれぞれが 1 つとしてカウントされます。これは、エントリがポリシー内のどこにあっても同様です。たとえば、1 つのプロジェクトが 1 つの通常の境界と 5 つのブリッジ境界に含まれている場合、6 つのインスタンスがすべてカウントされ、重複除去は行われません。
ただし、VPC Service Controls ではサービス境界の上限が異なる方法で計算されます。詳細については、このドキュメントのサービス境界の上限をご覧ください。
Trusted Cloud コンソールで割り当てを表示する
Trusted Cloud コンソールのナビゲーション メニューで [セキュリティ]、[VPC Service Controls] の順にクリックします。
[VPC Service Controls] に移動
プロンプトが表示されたら、組織、フォルダ、またはプロジェクトを選択します。
[VPC Service Controls] ページで、割り当てを表示するアクセス ポリシーを選択します。
[View Quota] をクリックします。
[割り当て] ページには、次のアクセス ポリシーの上限に対して使用状況の指標が表示されます。これらの上限は、特定のアクセス ポリシーのすべてのサービス境界に累積的に適用されます。
- サービス境界
- 保護対象リソース
- アクセスレベル
- 上り(内向き)属性と下り(外向き)属性の合計
サービス境界の上限
各サービス境界の構成には、次の上限が適用されます。この上限は、境界のドライラン構成と自動適用構成に個別に適用されます。
種類 |
上限 |
注 |
属性 |
6,000 |
この上限は、上り(内向き)ルールと下り(外向き)ルールで指定された属性の合計数に適用されます。属性の上限には、これらのルール内のプロジェクト、VPC ネットワーク、アクセスレベル、メソッド セレクタ、ID、ロールへの参照が含まれます。属性の合計数には、メソッド、サービス、プロジェクトの属性でワイルドカード文字 * が使用されている場合も含まれます。 |
属性の上限に関する考慮事項
VPC Service Controls では、次の上り(内向き)ルールと下り(外向き)ルールのフィールドの各エントリが 1 つの属性としてカウントされます。
ルールブロック |
フィールド |
ingressFrom |
|
ingressTo |
resources
methodSelectors
roles
|
egressFrom |
|
egressTo |
resources
methodSelectors
externalResources
roles
|
これらのフィールドの詳細については、上り(内向き)ルールのリファレンスと下り(外向き)ルールのリファレンスをご覧ください。
VPC Service Controls は、次のルールを考慮して、境界が属性の上限を超えているかどうかを確認します。
上り(内向き)ルールと下り(外向き)ルールの各フィールドには複数のエントリを含めることができ、それぞれのエントリが上限にカウントされます。
たとえば、egressFrom
ルールブロックの identities
フィールドにサービス アカウントとユーザー アカウントを指定すると、VPC Service Controls は上限に対して 2 つの属性をカウントします。
VPC Service Controls では、複数のルールで同じリソースを繰り返した場合でも、ルール内のリソースの出現は個別にカウントされます。
たとえば、2 つの異なる上り(内向き)ルールまたは下り(外向き)ルール(rule-1
と rule-2
)でプロジェクト project-1
を指定すると、VPC Service Controls は上限に対して 2 つの属性をカウントします。
各サービス境界には、自動適用構成とドライラン構成を設定できます。VPC Service Controls は、構成ごとに属性の上限を個別に適用します。
たとえば、境界の自動適用構成とドライラン構成の属性の合計数がそれぞれ 3,500 属性と 3,000 属性の場合、VPC Service Controls は境界が属性の上限内にあると見なします。
アクセス ポリシーの上限
次に示すアクセス ポリシーの上限は、1 つのアクセス ポリシー内のすべてのサービス境界に対して累積的に適用されます。
種類 |
上限 |
注 |
サービス境界
|
10,000 |
サービス境界ブリッジはこの上限にカウントされます |
保護対象リソース |
40,000 |
上り(内向き)と下り(外向き)のポリシー内でのみ参照されるプロジェクトは、この上限にはカウントされません。保護対象リソースを 10,000 個以下のリソースのバッチでのみポリシーに追加し、ポリシーの変更リクエストがタイムアウトしないようにします。次のポリシー変更を行う前に 30 秒待つことをおすすめします。 |
ID グループ |
1,000 |
これは、上り(内向き)ルールと下り(外向き)ルールで構成された ID グループ数の上限です。 |
VPC ネットワーク |
500 |
この上限では、自動適用モード、ドライラン モード、上り(内向き)ルールで参照される VPC ネットワークの数がカウントされます。 |
すべてのルールのタイトルの合計文字数 |
240,000 |
すべての上り(内向き)ルールと下り(外向き)ルールのタイトルの合計長がこの上限を超えないようにする必要があります。ルールのタイトルに含まれる空白文字もこの上限にカウントされます。ただし、タイトルを指定していないルールは、この上限にはカウントされません。 |
次に示すアクセス ポリシーの上限は、特定のアクセス ポリシー内のすべてのアクセスレベルに累積的に適用されます。
種類 |
上限 |
注 |
VPC ネットワーク |
500 |
この上限は、アクセスレベルで参照される VPC ネットワークの数に適用されます。 |
組織の上限
1 つの組織内のすべてのアクセス ポリシーには、次の上限が適用されます。
種類 |
上限 |
組織レベルのアクセス ポリシー |
1
|
フォルダとプロジェクト スコープのアクセス ポリシー |
50
|
Access Context Manager の割り当てと上限
VPC Service Controls は Access Context Manager API を使用するため、Access Context Manager の割り当てと上限も適用されます。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-08-18 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-18 UTC。"],[],[],null,["# Quotas and limits\n\nThis document lists the quotas and limits that apply to\nVPC Service Controls. Quotas and limits specified in this document are subject to change.\n\nThe quota utilization computation is based on the sum of the utilization\nacross the enforced and the dry-run modes. For example, if a\nservice perimeter protects five resources in enforced mode\nand seven resources in dry-run mode, then the sum of both, which is 12, is tested\nagainst the corresponding limit. Also, each individual entry is counted as one\neven if it occurs elsewhere in the policy. For example, if a project is included\nin one regular perimeter and five bridge perimeters, all six instances are\ncounted and no deduplication is performed.\n\nHowever, VPC Service Controls calculates the service perimeter limits differently.\nFor more information, see the [Service perimeter limits](/vpc-service-controls/quotas#perimeter-limits)\nsection of this document.\n\nView quotas in the Google Cloud console\n---------------------------------------\n\n1. In the Google Cloud console navigation menu, click **Security** , and then\n click **VPC Service Controls**.\n\n [Go to VPC Service Controls](https://console.cloud.google.com/security/service-perimeter)\n2. If you are prompted, select your organization, folder, or project.\n\n3. On the **VPC Service Controls** page, select the access policy for which you want to view quotas.\n\n4. Click **View Quota**.\n\n The **Quota** page displays the usage metrics\n for the following [access policy](/access-context-manager/docs/scoped-policies) limits that\n apply cumulatively across all service perimeters in a given access policy:\n - Service perimeters\n - Protected resources\n - Access levels\n - Total ingress and egress attributes\n\nService perimeter limits\n------------------------\n\nThe following limit applies to each service perimeter configuration. That is,\nthis limit applies separately for the dry-run and enforced configurations of a\nperimeter:\n\n### Attribute limit considerations\n\nVPC Service Controls counts each entry in the following ingress and egress rule\nfields as one attribute:\n\nFor more information about these fields, see [Ingress rules reference](/vpc-service-controls/docs/ingress-egress-rules#ingress-rules-reference)\nand [Egress rules reference](/vpc-service-controls/docs/ingress-egress-rules#egress-rules-reference).\n\nVPC Service Controls considers the following rules to check if a perimeter exceeds\nthe attribute limit:\n\n- Each field in an ingress and egress rule can have multiple entries, and each\n entry counts towards the limit.\n\n For example, if you mention a service account and a user account in the `identities`\n field of an `egressFrom` rule block, VPC Service Controls counts two attributes\n towards the limit.\n- VPC Service Controls counts each occurrence of a resource in the rules separately,\n even if you repeat the same resource in multiple rules.\n\n For example, if you mention a project, `project-1`, in two different ingress or\n egress rules, `rule-1` and `rule-2`, VPC Service Controls counts two attributes\n towards the limit.\n- Each service perimeter can have an [enforced](/vpc-service-controls/docs/service-perimeters#enforced-mode)\n and a [dry run](/vpc-service-controls/docs/service-perimeters#dry-run-mode) configuration.\n VPC Service Controls applies the attribute limit separately for each configuration.\n\n For example, if the total attribute counts for the enforced and dry run configurations\n of a perimeter are 3,500 and 3,000 attributes, respectively, VPC Service Controls\n considers that the perimeter is still within the attribute limit.\n\nAccess policy limits\n--------------------\n\nThe following [access policy](/access-context-manager/docs/scoped-policies) limits\napply cumulatively across all service perimeters in a given access policy:\n\nThe following [access policy](/access-context-manager/docs/scoped-policies) limits\napply cumulatively across all access levels in a given access policy:\n\nOrganization limits\n-------------------\n\nThe following limits apply across all access policies in a given organization:\n\nAccess Context Manager quotas and limits\n----------------------------------------\n\nYou're also subject to the [Access Context Manager quotas and\nlimits](/access-context-manager/quotas#limits) because VPC Service Controls uses\nAccess Context Manager APIs."]]