リソース ロケーションのサポート対象サービス

各サービスで使用されるリソースは、さまざまな形でロケーションによる影響を受けます。リソース ロケーションの制約を組織のポリシーに追加する前に、以下の該当するセクションを参照して、ポリシーを適用するリソースの動作を確認してください。

Agent Assist

Agent Assist で conversation profile リソースまたは knowledge base リソースを作成する際に組織のポリシーが適用されます。どちらのリソースもリージョン リソースです。

使用可能なロケーションと制限事項のリストについては、Agent Assist のリージョン指定とデータ所在地ページをご覧ください。

Apigee

リソース ロケーションの制約は、次の Apigee リソースを作成するときに適用されます。

使用可能なロケーションのリストについては、Apigee のロケーションをご覧ください。

リソース ロケーションの制約を含む組織のポリシーの設定方法については、リソース ロケーションの制限をご覧ください。

AI Platform

リソース ロケーションの制約は、次の AI Platform リソースに適用されます。

AI Platform トレーニングと AI Platform Prediction リソースは、リージョン ロケーションのみをサポートしています。マルチリージョン ロケーションとゾーン ロケーションの制約は、AI Platform には影響しません。ただし、リージョンを含む値グループに対する制約には影響します。たとえば、組織ポリシーの値 asia は AI Platform に影響しませんが、値 in:asia-locations は影響します。

AI Platform Training に使用できるリージョンと AI Platform Prediction に使用できるリージョンの詳細をご覧ください。

AlloyDB for PostgreSQL

クラスタ、インスタンス、および特定のタイプのバックアップを作成する際に、組織ポリシーが適用されます。オンデマンド バックアップの作成には組織のポリシーが適用されますが、自動バックアップと継続的なバックアップの作成が有効な場合は、データ損失を防ぐために除外されます。

AlloyDB for PostgreSQL は、リージョンのロケーションのみをサポートしています。マルチリージョン ロケーションとゾーン ロケーションの制約は影響をもたらしません。ただし、リージョンを含む値グループに対する制約には影響します。たとえば、組織のポリシーの値 asia は効力を持ちませんが、値 in:asia-locations は効力を持ちます。

使用可能なロケーションのリストについては、AlloyDB for PostgreSQL のロケーションをご覧ください。

Anti Money Laundering AI

リソース ロケーションの制約は、すべてのマネー ロンダリング防止 AI のリソースに適用され、リソースの作成時に適用されます。

利用可能なロケーションの一覧については、AML AI ロケーションをご覧ください。

Apigee Integration API

Apigee Integrations API を使用して次のリソースを作成する際に、組織のポリシーが適用されます。

  • 統合
  • 承認構成（AuthConfig）
  • AuthConfig の証明書
  • 統合バージョン
  • SFDC（Salesforce）チャネル
  • SFDC（Salesforce）インスタンス

統合の実行、スケジューリング、テストの際にも、組織のポリシーが適用されます。

Apigee のインテグレーションは、リージョン固有です。つまり、特定のリージョンで作成されたインテグレーションは、そのリージョン内でのみリソースにアクセスできます。

インテグレーションを作成できるロケーションのリストについては、サポート対象のリージョンをご覧ください。

App Engine

App Engine は application リソースのプロパティです。application を作成すると、すべての環境に対してロケーション プロパティが適用されます。プロジェクトごとに 1 つの App Engine application のみを作成できます。Cloud Storage バケットは、application と同じロケーションに自動的に作成されます。組織のポリシーに準拠していない広範囲なロケーションで application を作成する場合は、新しいプロジェクトと App Engine application を作成する必要があります。

application を無効にすると、それ以降機能しなくなりますが、複製されたコードとデータが application の保存場所であるロケーションに残ります。このデータを完全に消去するには、親プロジェクトを削除してください。

Compute Engine の上に App Engine フレキシブル環境が構築されます。スケーリングの発生するいずれかのロケーションが、組織のポリシーで定義された許可ロケーション リストに含まれない場合は、インスタンスの自動スケーリングに失敗することがあります。

使用可能なロケーションのリストについては、App Engine のロケーションをご覧ください。

Application Integration API

Application Integration API を使用して次のリソースを作成する場合は、組織のポリシーが適用されます。

統合の実行、スケジューリング、テストの際にも、組織のポリシーが適用されます。

Application Integration はリージョナルです。つまり、特定のリージョンで作成された統合は、そのリージョン内のリソースにのみアクセスできます。

使用可能なロケーションのリストについては、Application Integration のロケーションをご覧ください。

制限事項

次の Application Integration リソースは、指定したリソース ロケーションの制約をサポートしていません。

Artifact Registry

マルチリージョンまたはリージョンでリポジトリを作成できます。Artifact Registry は、リポジトリの作成時に組織のポリシーを適用します。

組織のポリシーの準拠は過去に遡って適用されません。リポジトリのロケーションがリソース ロケーションの組織のポリシーによって拒否される場合でも、アーティファクトを既存のリポジトリに追加できます。新しいリソース ロケーションの組織のポリシーを既存のリポジトリに適用するには、組織のポリシーの適用後に新しいリポジトリを作成し、古いリポジトリから新しいリポジトリにアーティファクトを移行します。gcrane ツールを使用して、リポジトリ間でイメージをコピーできます。

使用可能なロケーションのリストについては、Artifact Registry のドキュメントをご覧ください。

監査マネージャー

新しい監査を実行すると、監査リクエストの作成時に指定したリージョンに基づいて組織のポリシーが適用されます。監査のロケーションがグローバルとして選択されている場合、リソースのロケーションの制約は適用されません。

使用可能なリージョンのロケーションの一覧については、Audit Manager のロケーションをご覧ください。

Backup for GKE

上位 2 つのリージョン リソースのいずれかを作成すると、組織のポリシーが適用されます。

  • BackupPlan: このリソースのロケーションにより、このプランの下に作成されるバックアップのすべてのバックアップ データが保存されるターゲット リージョンが決定されます。1 つのプロジェクトに複数の BackupPlan リソースが存在する場合があります。

  • RestorePlan: このリソースのロケーションによって、バックアップのデータの復元先であるターゲット クラスタとして許容されるリージョンが制御されます。プロジェクトには複数の RestorePlan リソースがある場合があります

詳細については、Backup for GKE のロケーションをご覧ください。

BigQuery

BigQuery dataset リソースは、リージョンとマルチリージョンのどちらにもなります。組織のポリシーの準拠は過去に遡って適用されません。新しいリソース ロケーションの制約を既存の dataset に適用するには、dataset リソースを削除し、親リソースに適用されている組織のポリシーを使用してそれをもう一度作成します。

Database リソースは、リソース ロケーションの組織のポリシーによって拒否されるロケーションを持つ dataset リソース内に作成できます。dataset リソースのロケーションは、database リソースのロケーションを指定しません。新しいリソース ロケーションの制約を既存の database に適用するには、database リソースを削除し、親リソースに適用されている組織のポリシーを使用してそれをもう一度作成します。

使用可能なロケーションのリストについては、BigQuery データセットのロケーション ページをご覧ください。

BigQuery Data Transfer Service

TransferConfig リソースは、リージョン リソースとマルチリージョン リソースのいずれの場合もあります。組織のポリシーの準拠は過去に遡って適用されません。組織のポリシーは、TransferConfig を作成するときにのみ確認されます。新しいリソース ロケーションの制約を既存の TransferConfig に適用するには、TransferConfig リソースを削除し、親リソースに適用されている組織のポリシーを使用してそれをもう一度作成します。

使用可能なロケーションのリストについては、BigQuery Data Transfer Service のロケーションをご覧ください。

BigQuery Migration Service

MigrationWorkflow リソースは、移行ワークフローを構成するタスクとサブタスクを記述します。タスクやサブタスクは、移行評価または SQL 変換の実行時に Google Cloud コンソールまたは API を使用して作成できます。移行ワークフローは、ワークフローが使用するリソースと同じロケーションで作成する必要があります。たとえば、BigQuery データセットと Cloud Storage バケットが US マルチリージョンにある場合、移行ワークフローは US マルチリージョンまたは us-west1 リージョンに作成できます。

組織のポリシーは不変リソースであるため、移行ワークフローの作成時にのみ確認されます。

使用可能なロケーションのリストについては、BigQuery Migration Service のロケーションをご覧ください。

Certificate Authority Service

証明書テンプレート、認証局（CA）プール、CA などの CA サービスのリソースは、利用可能な任意のロケーションに作成できます。これらのリソースは、作成後に移動することはできません。

証明書テンプレートは、Google Cloud CLI コマンドを使用して複製できます。gcloud CLI コマンドを使用することで、サポートされている別のロケーションに同じ名前のリソースを作成できます。詳細については、証明書テンプレートの作成をご覧ください。

同じ CA プール内の既存の CA から CA のクローンを作成できます。これらの新しい CA は、クローンを作成した CA と同じロケーションに作成されます。詳しくは、認証局の作成をご覧ください。

使用可能なロケーションのリストについては、CA サービス ロケーションをご覧ください。

Bigtable

Bigtable インスタンス リソースは、複数のクラスタからなる論理コンテナです。これらのクラスタのそれぞれは、1 つのゾーン内に配置されます。インスタンス内のすべてのデータが、そのインスタンスに含まれるすべてのクラスタに均一に複製されます。クラスタの作成時には組織ポリシーが適用されます。組織のポリシーによって拒否されたロケーションに新しいストレージ コンテナを作成することはできません。既存のインスタンスとクラスタは、組織のポリシーへのその後の変更によって拒否された場所にある場合でも、引き続き動作します。

新しい組織のポリシーが導入されたら、その組織のポリシーに違反するリソースを削除して再作成することで、リソースを手動で修正できます。たとえば、あるクラスタに新しい組織のポリシーに違反したマルチクラスタ インスタンスがある場合は、それを削除してから、許可されたゾーンに新しいクラスタを追加できます。

使用可能なロケーションのリストについては、Bigtable のロケーション ページをご覧ください。

Cloud Build

組織のポリシーは、新しいリージョン Cloud Build リソースの作成時に適用されます。任意のリージョンにリソースを作成できますが、Cloud Build によって、組織で承認されたリージョンが選択されるようにします。組織のポリシーは、組織のポリシーを作成した後に、グローバル リージョン以外に新しく作成された Cloud Build リソースにのみ適用されます。

使用可能なリージョンの一覧については、Cloud Build のロケーションページをご覧ください。

Certificate Manager

グローバルにのみ存在できる CertificateMaps と CertificateMapEntries を除き、Certificate Manager リソースは任意のリージョンまたはグローバルのロケーションに作成できます。ただし、リソースのゾーンを選択することはできません。組織のポリシーは、Certificate Manager リソースの作成時に適用されます。

利用可能なロケーションのリストについては、ロケーション別のプロダクト提供状況をご覧ください。

Cloud Composer

Cloud Composer 環境は、以下にリストされたリソースの論理コンテナです。環境の作成プロセスでは、環境のロケーション（リージョン / ゾーン）を選択すると、基盤となるリソースが、選択したロケーションに基づいて作成されます。

  • Google Kubernetes Engine クラスタ

  • Cloud SQL インスタンス

  • Airflow ウェブサーバーを使用している App Engine VM

  • Persistent Disk: Airflow ウェブサーバーと GKE クラスタで使用

  • Pub/Sub トピック

  • Cloud Storage

  • カスタム Python 依存関係を持つ Airflow イメージのビルドと保存

    • ロケーション制限が指定されていない場合は、構成によっては、Composer が GKE クラスタ内で、または Cloud Build を使用して Airflow イメージをビルドできます。詳細については、プライベート IP 環境への Python 依存関係のインストールをご覧ください。Composer のバージョンに応じて、選択したリージョン（Artifact Registry を使用）、または選択したリージョンが属するマルチリージョン（Container Registry を使用）に Airflow イメージが保存されている可能性があります。

    • ロケーションの制限を指定すると、Cloud Composer は、環境の GKE クラスタ内に Airflow イメージをビルドし、選択したリージョンの Artifact Registry リポジトリにそれらのイメージを保存します。

  • Cloud Monitoring: 指定したリージョンに環境と実行済みの Airflow DAG の指標を保存します。

    • 一部の指標ラベルには、DAG 環境と Cloud Composer 環境の名前が含まれることがあります。

  • Cloud Logging: デフォルトでは、Cloud Composer はグローバル Google Cloud サービスである Cloud Logging に保存されます。Cloud Composer ログを特定のロケーションに保存する場合は、このロケーションの Cloud Storage バケットにログをリダイレクトする必要があります。

使用可能なロケーションのリストについては、Cloud Composer のリージョンをご覧ください。

Cloud Composer のドキュメントに、Cloud Composer 環境のアーキテクチャの詳細が記載されています。

Cloud Data Fusion

インスタンスの作成時に組織のポリシーが適用されます。 インスタンスは、指定したリージョンで作成されるリージョン リソースです。

顧客管理の暗号鍵（CMEK）でインスタンスを作成する場合、鍵のロケーションはインスタンスのロケーションと同じである必要があります。

デフォルトでは、Cloud Data Fusion は各パイプラインのインスタンスと同じリージョンに Dataproc のエフェメラル クラスタを作成します。これらのエフェメラル クラスタのロケーションは変更可能であり、リソース ロケーションの組織のポリシーによって適用されることはありません。静的 Dataproc クラスタの場合、Dataproc でサポートされている任意のロケーションを使用できます。これらのロケーションは、リソース ロケーションの組織のポリシーによって適用されるものではありません。

使用可能なロケーションのリストについては、Cloud Data Fusion でサポートされているリージョンをご覧ください。

Cloud Deploy

Cloud Deploy のリソースタイプは次のとおりです。

  • デリバリー パイプライン
  • ターゲット
  • リリース
  • ロールアウト
  • ジョブ実行

すべての Cloud Deploy リソースは、デリバリー パイプラインが作成されたところと同じリージョンに作成されます。

特定のロケーションの使用に対する組織のポリシーがある場合、そのリージョンに Cloud Deploy リソース（デリバリー パイプライン、ターゲット、リリース、ロールアウト）を作成することはできません。

Cloud Deploy サービスとそのリソースに使用可能なロケーションのリストについては、Cloud Deploy リージョンについてをご覧ください。

Cloud Run 関数

Cloud Run functions のリソースを作成または更新する際に組織のポリシーが適用されます。既存のリソースには適用されません。

利用可能なリージョンの一覧については、Cloud Run functions のロケーションをご覧ください。

Cloud Healthcare API

dataset リソースを作成すると、組織ポリシーが適用されます。dataset リソースは、リージョンまたはマルチリージョンのリソースです。FHIR ストアなどのデータストア リソース、または HL7v2 メッセージなどの他の下位レベルのリソースは、dataset リソースが組織のポリシーによって拒否されたロケーションにある場合でも、既存の dataset に追加できます。リソースがリソース ロケーションの制約に準拠していることを確認するには、組織ポリシーの適用後に新しい dataset リソースを作成してから、古い dataset リソースから新しいリソースにデータを移行します。

利用可能なロケーションの一覧については、Cloud Healthcare API リージョンをご覧ください。

Cloud Interconnect

Cloud Interconnect アタッチメントは、どのリージョンにも作成できます。ただし、ゾーンを選択することはできません。組織のポリシーは、Cloud Interconnect アタッチメントを作成するときに適用されます。

使用可能なリージョンのリストについては、Compute Engine のリージョンとゾーンページをご覧ください。

Cloud Intrusion Detection System

組織のポリシーは、ゾーン リソースである Cloud IDS エンドポイントを作成するときに適用されます。組織のポリシーの準拠は過去に遡って適用されません。組織のポリシーで拒否されたロケーションに配置されていても、既存のエンドポイントは引き続き動作します。既存の Cloud IDS エンドポイントに新しいリソース ロケーションの制約を適用するには、インスタンスを削除し、組織のポリシーを適用して再作成します。

利用可能なロケーションのリストについては、ロケーション別のプロダクト提供状況をご覧ください。

Cloud Key Management Service

Cloud KMS リソースは、リージョン、デュアル リージョン、マルチ リージョン、またはグローバルの各ロケーションに作成できます。組織のポリシーは、そのリソースの作成時に適用されます。

詳細については、Cloud KMS のロケーションページをご覧ください。

Cloud Logging

組織のポリシーは、新しいログバケットの作成時に適用されます。新しいバケットを任意のリージョンに作成することや、ロケーションを global に設定することはできますが、Logging では組織で承認されたリージョンを選択してください。組織のポリシーは、組織ポリシーの作成後に新しく作成されたログバケットにのみ適用されます。

使用可能なリージョンの一覧については、Cloud Logging ストレージの概要ページのリージョン指定セクションをご覧ください。

Cloud NAT

Cloud NAT ゲートウェイは、任意のリージョン ロケーションに作成できます。ただし、Cloud NAT ゲートウェイのゾーンは選択できません。組織のポリシーは、Cloud NAT ゲートウェイの作成時に適用されます。

使用可能なロケーションのリストについては、Compute Engine のリージョンとゾーンページをご覧ください。

Cloud Router

Cloud Router は、任意のリージョン ロケーションに作成できます。ただし、Cloud Router にゾーンを選択することはできません。組織のポリシーは、Cloud Router の作成時に適用されます。

使用可能なロケーションのリストについては、Compute Engine のリージョンとゾーンページをご覧ください。

Cloud Load Balancing

次のプロダクトを使用するロードバランサは、任意のリージョン ロケーションで作成できます。

  • リージョンの外部アプリケーション ロードバランサ
  • リージョンの外部プロキシ ネットワーク ロードバランサ
  • リージョンの内部アプリケーション ロードバランサ
  • リージョンの内部プロキシ ネットワーク ロードバランサ
  • 外部パススルー ネットワーク ロードバランサ
  • 内部パススルー ネットワーク ロードバランサ

ただし、これらのロードバランサにゾーンを選択することはできません。組織のポリシーは、ロードバランシング リソースの作成時に適用されます。

使用可能なロケーションのリストについては、Compute Engine のリージョンとゾーンページをご覧ください。

Google Cloud Armor

Google Cloud Armor セキュリティ ポリシーを作成すると、作成リクエストで指定したリージョンに基づいて組織のポリシーが適用されます。このポリシーは、既存のリソースには適用されません。グローバル リソースは、リソース ロケーションの制約を受けません。

使用可能なロケーションのリストについては、Compute Engine のリージョンとゾーンページをご覧ください。

Cloud Run

組織のポリシーは、Service などの最上位リソースを作成するときに適用されます。これは、既存リソースや既存リソースの更新には適用されません（このような更新が発生して Revision などの下位レベルのリソースが作成される場合でも同様です）。

使用可能なリージョンの一覧については、Cloud Run のロケーションページをご覧ください。

Cloud Service Mesh

組織のポリシーは、Cloud Service Mesh のプロビジョニングやメッシュのワークロードの作成を試行するときに適用されます。Cloud Service Mesh は、ワークロードがメッシュに登録されたときに組織のポリシーを適用しません。

特定のサービス ワークロードに関する関連ドキュメントをご覧ください。

Cloud Service Mesh コンピューティング インフラストラクチャで使用可能なリージョンの一覧を確認します。

Spanner

インスタンスの作成時に組織のポリシーが適用されます。インスタンスは、リージョン リソースまたはマルチリージョン リソースのどちらかです。インスタンスがリソース ロケーションの組織のポリシーによってブロックされる場合、リソースを準拠させる唯一の方法は、インスタンスを削除することです。リソース ロケーションの組織のポリシーによってブロックされるインスタンスでは、データベース リソースの読み取り、書き込み、作成を引き続き行えます。

使用可能なロケーションのリストについては、Spanner インスタンス ページをご覧ください。

Cloud SQL

インスタンスの作成時に組織のポリシーが適用されます。インスタンスは、リソース ロケーションが適用されないゾーン データベースを作成するリージョン リソースです。リードレプリカまたはデータベース クローンを作成すると、元のリソースと同じリージョンに新しいリソースが配置されるため、リソース ロケーションの組織のポリシーは適用されません。

使用可能なロケーションのリストについては、Cloud SQL インスタンスのロケーション ページをご覧ください。

Cloud Storage

組織のポリシーは、bucket リソースの作成時に適用されます。Bucket リソースは、リージョン リソースまたはマルチリージョン リソースのどちらかです。リソース ロケーションの組織のポリシーによって拒否されたロケーションに object がある場合でも、Object リソースを既存の bucket に追加できます。リソースがリソース ロケーションの組織のポリシーに準拠するようにするには、組織のポリシーの適用後に新しい bucket リソースを作成し、その後、古い bucket リソースから新しいリソースにデータを移行します。

使用可能なロケーションのリストについては、Cloud Storage バケットのロケーション ページをご覧ください。

Cloud Tasks

組織のポリシーはキューの作成時に適用されます。組織ポリシーの設定前に作成されたキューに適用されることや、このようなキューの更新時に適用されることはありません。

利用可能なロケーションのリストについては、ロケーション別のプロダクト提供状況をご覧ください。

制限事項

次のリージョンに適用される制限事項:

  • us-central1
  • us-central2（プライベート Google Cloud リージョン）

組織のポリシーに前述のいずれかのリージョンが含まれている場合は、これらのリージョンに Cloud Tasks リソースを作成していなくても、us-central1 と us-central2 の両方を含める必要があります。プライベート リージョンを使用していない組織でも、組織のポリシーにリージョン us-central2 を含めることができます。

Cloud Translation - Advanced API (v3)

Cloud Translation リソースがリソース ロケーションの制約に準拠するようにするには、リソースの作成時にリージョン エンドポイントを指定します。リソース ロケーションの制約は、Cloud Translation リソースを作成するときに適用されます。

リージョン エンドポイントの使用方法については、リージョン エンドポイントを指定するをご覧ください。

Cloud VPN

Cloud VPN ゲートウェイは、任意のリージョン ロケーションに作成できます。ただし、Cloud VPN ゲートウェイのゾーンは選択できません。組織のポリシーは、Cloud VPN ゲートウェイの作成時に適用されます。

使用可能なロケーションのリストについては、Compute Engine のリージョンとゾーンページをご覧ください。

Cloud Workstations

組織のポリシーは、ワークステーション クラスタ、ワークステーション構成、ワークステーションなどの新しいリージョン リソースを作成するときに適用されます。ワークステーション構成を作成すると、Compute Engine 永続ディスクと VM が作成される可能性があるため、これらのリソースは組織ポリシーで許可されているゾーンでのみ作成できます。

使用可能なロケーションのリストについては、Cloud Workstations のロケーションをご覧ください。

Compute Engine

Compute Engine はグローバル、リージョン、ゾーンに対応したさまざまなリソースを提供しています。リージョンおよびゾーンのリソースは、リソース ロケーションの制約対象となります。グローバル リソースはリソース ロケーションの制約を受けませんが、一部のグローバル リソースはリージョンリ ソースとゾーン リソースを使用します。これらのリージョン リソースとゾーン リソースは、リソース ロケーションの制約を受けます。

たとえば、インスタンス テンプレートはグローバル リソースですが、インスタンス テンプレートでリージョンまたはゾーンディスクを指定できます。これらのディスクはリソース ロケーションの制約を受けるため、インスタンス テンプレートでは、組織のポリシーで許可されているリージョンとゾーンにディスクを指定する必要があります。

制限事項

すべての Compute Engine リソースは、指定したリソース ロケーションの制約をサポートしますが、以下の例外があります。

  • スナップショットとイメージ

    • スナップショットまたはイメージを作成するときに、許可されたロケーション内にストレージ ロケーションを指定する必要があります。それ以外の場合は、スナップショットまたはイメージの作成が失敗する可能性があります。

  • マネージド インスタンス グループ

    • 一部のマネージド インスタンス グループ（MIG）オペレーションは、許可されたゾーン内での VM の作成または再作成に依存します。こうしたオペレーションには、スケールアウト（手動または自動スケーリング）、自動修復、自動更新、プロアクティブなインスタンスの再配布があります。これらのオペレーションを成功させるには、組織のリソース ロケーションの制約で許可されている場所に MIG が存在する必要があります。

    • 許可された場所に MIG を作成します。リージョン MIG の場合は、場所に制限がないゾーンを選択します。

    • 既存のゾーン MIG またはリージョン MIG が存在し、後でリソース ロケーションの制約を設定した場合、制約に違反すると、MIG オペレーションは失敗します。許可されたロケーションに MIG を再作成する必要があります。

  • 単一テナントノード

    • 既存のノードグループがあり、後でリソースの場所の制約を設定した場合、グループの場所が制約に違反していると、グループをスケールアウトして（手動または自動スケーリングによって）新しいホストを追加できません。新しいホストを追加するのにグループをスケールアウトできなくなります。

使用可能なロケーションのリストについては、Compute Engine のリージョンとゾーンページをご覧ください。

Config Controller

Config Controller は、Compute Engine のリージョンとゾーンを使用します。リソース ロケーションの適用は、クラスタを作成する際に、Compute Engine リソースのレベルで処理されます。インスタンスを追加してクラスタをスケールするには、こうした追加分が許可されたロケーションに含まれる必要もあります。

十分な冗長性を備えたクラスタを作成するには、値グループを使用して、制限対象のロケーションを制御します。手動でロケーションを設定する場合は、そのリージョン内のすべてのゾーンを許可リストに含め、冗長性のレベルを等しくする必要があります。スケーリングの発生するいずれかのロケーションが、組織ポリシー内で定義された許可ロケーション リストに含まれない場合は、クラスタの自動スケーリングが中断される可能性があります。

Contact Center AI Insights

組織のポリシーは、Contact Center AI Insights で conversation を作成するときに適用されます。conversation リソースはリージョン リソースです。

使用可能なロケーションのリストについては、Contact Center AI Insights のロケーション ページをご覧ください。

データリネージ API

組織のポリシーは、CreateProcess メソッド、UpdateProcess メソッド、ProcessOpenLineageRunEvent メソッドを使用して Process を作成または更新するときに適用されます。

リソース ロケーションの組織のポリシーによって拒否されたロケーションに Process がある場合でも、子リソース（Runs または Events）を既存の Process に更新または追加できます。すべてのリソースがリソース ロケーションの組織のポリシーに準拠するようにするには、組織のポリシーの適用後に新しい Process を作成します。

Dataflow

組織のポリシーは、job の作成時に適用されます。job は、Cloud Storage と Compute Engine の両方を使用するリージョン リソースです。ゾーン パラメータを指定することにより、ジョブのリージョン外のゾーンで実行されるように Compute Engine ワーカーを構成できます。この場合、Dataflow コントロール プレーンは指定されたリージョンで動作しますが、データ処理ワーカーは指定されたゾーンで動作します。ワーカーのゾーンを指定しない場合、ワーカーは、job が実行されるように構成されているリージョン内に作成されます。

job のゾーンを指定しなければ、ワーカーのロケーションは、job を実行するように構成されているリーション内のいずれかのゾーンになります。Dataflow は、ゾーン内で使用可能な容量に基づいてゾーンを選択します。job のリージョン内のすべてのゾーンは、リソース ロケーションの組織のポリシーで許可された値に設定する必要があります。

スケーリングの発生するいずれかのロケーションが、組織ポリシー内で定義された許可ロケーション リストに含まれない場合は、クラスタの自動スケーリングが中断される可能性があります。

使用可能なロケーションのリストについては、Dataflow リージョン エンドポイントのページを参照してください。

Dataform

Dataform リソースはリージョン リソースです。Dataform リポジトリを作成すると、リポジトリとそのすべての子リソースは、リポジトリの作成時に指定したリージョンに制限されます。

使用可能なロケーションのリストについては、Dataform のロケーションをご覧ください。

Dataplex

組織のポリシーは、次のいずれかの Dataplex リソースを作成するときに適用されます。

ポリシーは、リソースの作成時に適用されます。リソースのロケーションの制約を適用しても、既存のリソースやそれらのリソースの更新には影響しません。

Dataproc

cluster を作成すると、作成リクエストで指定したリージョンに基づいて組織のポリシーが適用されます。job のロケーションは、submit メソッドの呼び出し時にその親である cluster のロケーションによってバインドされます。

使用可能なロケーションのリストについては、Dataproc リージョン エンドポイントのページを参照してください。

Dataproc Metastore

service を作成すると、作成リクエストで指定したリージョンに基づいて組織のポリシーが適用されます。backups と metadataImports のロケーションは、importMetadata メソッドと backupService メソッドの呼び出し時にその親である service のロケーションによってバインドされます。

使用可能なロケーションのリストについては、Dataproc Metastore ロケーション ページをご覧ください。

Datastore

Datastore database リソースは、親プロジェクトにある App Engine アプリケーションとその定義された場所に直接依存します。App Engine アプリケーションを無効にすると、関連するデータベースへの API アクセスがブロックされます。複製されたデータを物理的なロケーションから削除するには、App Engine セクションの説明に従ってプロジェクトを削除します。

使用可能なロケーションのリストについては、Datastore ロケーションページをご覧ください。

Dialogflow

組織のポリシーは、Dialogflow CX で agent リソースまたは location setting リソースを作成するときに適用されます（Dialogflow ES ではまだ組織ポリシーを適用していません）。agent リソースと location setting リソースはいずれもリージョン リソースまたはマルチリージョン リソースです。他の Dialogflow リソース（intents や flows など）は、組織のポリシーによって agent リソースが拒否されたロケーションにある場合でも、既存の agent に追加できます。リソースがリソース ロケーションの制約に準拠していることを確認するには、組織のポリシーの適用後に新しい agent リソースを作成し、古い agent リソースから新しいリソースにデータを移行します。

使用可能なロケーションのリストについては、Dialogflow ロケーションページをご覧ください。

Document AI

Document AI リソースはリージョン リソースです。Processor または LabelerPool リソースを作成すると、リソース ロケーションの組織のポリシーが適用され、新しいリソースを作成または保存できるリージョンが制限されます。

組織のポリシーの準拠は過去に遡って適用されません。親のリソース ロケーションがリソース ロケーションの組織のポリシーによって拒否された場合でも、既存の親リソースの下に新しい Document AI リソースを作成できます。新しいリソース ロケーションの制約を既存のリソースに適用するには、リソースを削除し、組織のポリシーを適用してそれをもう一度作成します。

使用可能なロケーションのリストについては、Document AI のマルチリージョンのサポートページをご覧ください。

Eventarc

組織のポリシーは、Eventarc トリガーの作成時に適用されます。このポリシーは、既存のリソースや既存のリソースの更新には適用されません。トリガーはグローバル リソースまたはリージョン リソースのいずれかになります。グローバル リソースは、リソース ロケーションの制約を受けません。

リソース ロケーションの制約が適用される場合、リージョンがリソース ロケーションの制約に適用されたものと完全に一致するか、値グループに含まれているリージョン トリガーのみを作成できます。たとえば、組織のポリシーで定義されている許可されたロケーションのリストに、us-central1 または us-locations のいずれかが含まれている場合は、us-central1 トリガーを作成できます。

使用可能なロケーションのリストについては、Eventarc のロケーションをご覧ください。

Filestore

組織のポリシーは、ゾーンリソースまたはリージョン リソースである Filestore インスタンスを作成するときに適用されます。組織のポリシーの準拠は過去に遡って適用されません。組織のポリシーで拒否されたロケーションに配置されていても、既存のインスタンスは引き続き動作します。既存の Filestore インスタンスに新しいリソース ロケーションの制約を適用するには、インスタンスを削除してから、組織のポリシーを適用してインスタンスを再度作成します。

使用可能なロケーションのリストについては、Filestore のリージョンとゾーンのページをご覧ください。

Firestore

Firestore の database リソースは、親プロジェクト内の App Engine アプリケーションとその定義されたロケーションに直接依存します。App Engine アプリケーションを無効にすると、関連するデータベースへの API アクセスがブロックされます。複製されたデータを物理的なロケーションから削除するには、App Engine セクションの説明に従ってプロジェクトを削除します。

使用可能なロケーションのリストについては、Firestore のロケーション ページをご覧ください。

Cloud Next Generation Firewall Enterprise

組織のポリシーは、ゾーンリソースである Cloud NGFW Enterprise を作成するときに適用されます。組織のポリシーの準拠は過去に遡って適用されません。組織のポリシーで拒否されたロケーションに配置されていても、既存のエンドポイントは引き続き動作します。既存の Cloud NGFW Enterprise エンドポイントに新しいリソース ロケーションの制約を適用するには、インスタンスを削除してから、組織のポリシーを適用してインスタンスを再度作成します。

利用可能なロケーションのリストについては、ロケーション別のプロダクト提供状況をご覧ください。

安全なウェブプロキシ

Secure Web Proxy は、任意のリージョン ロケーションに作成できます。ただし、Secure Web Proxy のゾーンは選択できません。組織のポリシーは、Secure Web Proxy の作成時に適用されます。

利用可能なロケーションのリストについては、ロケーション別のプロダクト提供状況をご覧ください。

フリート

Cloud フリート membership リソースは、Compute Engine のリージョンとゾーンのリージョン ロケーションのみをサポートします。リソース ロケーションの適用は、クラスタ登録時に membership リソースのレベルで処理されます。フリート メンバーシップは、グローバルとリージョンのロケーションでサポートされています。

十分な冗長性を備えたメンバーシップを作成するには、値グループを使用して、制限対象のリージョンを制御します。マルチリージョン ロケーションとゾーン・ロケーションの制約は、フリート membership には影響しません。ただし、リージョンを含む値グループに対する制約には影響します。たとえば、組織のポリシーの値 asia はフリートメンバーシップに影響しませんが、値 in:asia-locations は影響します。

Vertex AI の生成 AI

リソース ロケーションの制約は、すべての Vertex AI の生成 AI リソースに適用されます。組織のポリシーの遵守は、過去に遡って適用されることはありません。つまり、リソースのロケーションの制約を適用しても、既存のリソースやそれらのリソースの更新には影響しません。 Google モデルは Google Cloud リソースではないため、リソース ロケーションの制約は適用されません。

使用可能なリージョンの一覧については、Vertex AI の生成 AI のロケーション をご覧ください。

GKE Multi-Cloud

GKE Multi-Cloud API を使用して次のクラスタを作成する際に、組織のポリシーが適用されます。

  • GKE on AWS
  • GKE on Azure
  • GKE 接続クラスタ

使用可能なロケーションのリストについては、各クラスタ プラットフォームの次のページをご覧ください。

Google Kubernetes Engine

Google Kubernetes Engine は、Compute Engine のリージョンとゾーンを使用します。リソース ロケーションの適用は、クラスタの VM を作成するときの Compute Engine リソースのレベルで処理されます。インスタンスや別のゾーンを追加して、クラスタをスケーリングする場合には、それらの追加分を可能なロケーションに含める必要もあります。

十分な冗長性を備えたクラスタを作成するには、値グループを使用して、制限対象のロケーションを制御します。手動でロケーションを設定する場合は、そのリージョン内のすべてのゾーンを許可リストに含めることで冗長性のレベルを同じにする必要があります。スケーリングの発生するいずれかのロケーションが、組織ポリシー内で定義された許可ロケーション リストに含まれない場合は、クラスタの自動スケーリングが中断される可能性があります。

Infrastructure Manager

Infrastructure Manager は、Infra Manager の Deployment を作成するためにこれらの Google Cloud リージョンを使用します。

また、Infrastructure Manager は構成言語として HCL を使用し、Terraform でリソースを有効にします。

リソースのロケーション制約は、Infra Manager Deployment リソースと HCL で定義されたサポート対象の Google Cloud リソースの両方に適用されます。

Integration Connectors API

Integration Connectors API を使用して次のリソースを作成する場合、組織のポリシーが適用されます。

使用可能なロケーションのリストについては、Integration Connectors のロケーションをご覧ください。

Looker（Google Cloud コア）

Looker（Google Cloud コア）リソースは、リージョンのロケーションに作成できます。組織のポリシーは、そのリソースの作成時に適用されます。

使用可能なリージョンの一覧については、Looker（Google Cloud コア）インスタントを作成するページをご覧ください。

Managed Service for Microsoft Active Directory

組織のポリシーは、Managed Microsoft AD のドメインを作成するか、既存の AD リソースを更新するときに適用されます。Managed Microsoft AD では global ロケーションを許可する必要があります。global ロケーションを許可していない場合、ドメインの作成とリソースの更新は失敗します。

詳しくは、global に対するリソース ロケーションの制約の表示と更新方法をご覧ください。

Memorystore for Memcached

インスタンスの作成時に組織のポリシーが適用されます。インスタンスは、選択したノード数に応じて 1 つ以上のゾーン キャッシュを作成するリージョン リソースです。スケールアップ オペレーションを使用してノードを追加すると、新しいリソースが元のインスタンスと同じリージョンに配置されます。ロケーションの組織のポリシーは、スケールアップ中に適用されます。

使用可能なロケーションのリストについては、Memorystore for Memcached のリージョンとゾーンのページをご覧ください。

Memorystore for Redis

インスタンスの作成時に組織のポリシーが適用されます。インスタンスは、選択したインスタンス階層に応じて 1 つ以上のゾーン キャッシュを作成するリージョン リソースです。ベーシック ティア インスタンスは、指定されたリージョンとゾーン内に単一のキャッシュをデプロイします。標準階層インスタンスは、インスタンスのリージョン内にあるゾーン キャッシュと 1 つ以上のゾーン キャッシュのレプリカをデプロイします。追加のレプリカを作成すると、元のゾーン キャッシュと同じリージョンに新しいリソースが配置されます。追加のレプリカを作成するときに、ロケーションの組織ポリシーが適用されます。

使用可能なロケーションのリストについては、Memorystore for Redis のリージョンとゾーンのページをご覧ください。

Memorystore for Redis Cluster

インスタンスの作成時に組織のポリシーが適用されます。インスタンスは、選択したゾーン分散モードに応じて 1 つ以上のゾーン キャッシュを作成するリージョン リソースです。追加のレプリカまたはシャードを作成すると、元のゾーン キャッシュと同じリージョンに新しいリソースが配置されます。追加のレプリカを作成するときに、ロケーションの組織ポリシーが適用されます。

使用可能なロケーションの一覧については、Memorystore for Redis Cluster のロケーション ページをご覧ください。

Network Connectivity Center

Network Connectivity Center ハブリソースと VPC スポーク リソースは、グローバル ロケーションに作成できます。Network Connectivity Center ハイブリッド スポーク リソースは、任意のリージョン ロケーションに作成できます。組織のポリシーは、そのリソースの作成時に適用されます。

使用可能なロケーションのリストについては、Compute Engine のリージョンとゾーンページをご覧ください。

Network Intelligence Center - 接続テスト

接続テストのリソースは、グローバル ロケーションに作成できます。組織のポリシーは、そのリソースの作成時に適用されます。

Persistent Disk

組織のポリシーは、disk リソースの作成時に適用されます。これは、仮想マシンに追加できます。

  • ゾーン disk リソースを作成した後、同じゾーンの仮想マシン インスタンスにそれを追加できます。
  • リージョン disk リソースを作成した後、disk が配置されている 2 つのゾーンのいずれかにある仮想マシン インスタンスにそれを追加できます。

組織のポリシーの準拠は過去に遡って適用されません。既存の disk リソースに新しいリソース ロケーションの組織のポリシーを適用するには、disk リソースを削除してから、親リソースに適用されている組織のポリシーを使用してそれらをもう一度作成します。

使用可能なロケーションのリストについては、Compute Engine のリージョンとゾーンページをご覧ください。

Pub/Sub

リソース ロケーションの組織のポリシーは、topic に発行されるメッセージを永久保存できるロケーションに影響を及ぼします。組織のポリシーは、topic にメッセージを発行すると適用されます。topic は、引き続き、許可されたクライアントが世界中のどこからでもアクセスできるグローバル リソースであることに注意してください。

組織のポリシーの変更は遡って適用されず、既存の topics には適用されません。新しいリソース ロケーションの制約により、topic に公開されたメッセージがすでに保存されているロケーションが拒否される場合、それらのメッセージは自動的に移動されません。

詳細については、Pub/Sub の Pub/Sub リソースのロケーションの制限ページをご覧ください。

Pub/Sub Lite

リソース ロケーションの組織のポリシーは、topic を作成できるロケーションに影響します。これにより、メッセージが保持される場所が決まります。topic はゾーンリソースですが、メッセージは、Google Cloud の外など、あらゆるロケーションからリクエストできます。

組織のポリシーの変更は遡って適用されず、既存の topics には適用されません。新しいリソース ロケーションの制約により、topic に公開されたメッセージがすでに保存されているロケーションが拒否される場合、それらのメッセージは自動的に移動されません。

Secret Manager

Secret には、自動レプリケーション ポリシーまたはユーザー管理のレプリケーション ポリシーがあります。

自動レプリケーション ポリシーを使用する場合、ペイロード データは制限なしで複製されます。Secret Manager では、自動レプリケーション ポリシーでシークレットを作成する場合に、global ロケーションを許可する必要があります。global のロケーションが許可されていない場合、シークレットの作成は失敗します。

ユーザー管理のレプリケーション ポリシーを使用する場合、ペイロード データは、ユーザーが定義したサポートされているロケーションに複製されます。Secret Manager では、ユーザー管理のレプリケーション ポリシーを使用して Secret を作成するときに、レプリケーション ポリシーのすべてのロケーションが許可されている必要があります。Secret のレプリケーション ポリシーで許可されていないロケーションがある場合、Secret の作成は失敗します。

組織のポリシーは、その Secret の作成時に適用されます。

詳細については、Secret Manager のロケーションのページをご覧ください。

サーバーレス VPC アクセス

組織のポリシーは、新しいサーバーレス VPC アクセス コネクタ インスタンスの作成時に適用されます。組織のポリシーは、組織のポリシーを作成した後に、リージョン内で新しく作成されたサーバーレス VPC アクセス コネクタ インスタンスにのみ適用されます。

詳細については、サーバーレス VPC アクセスのサポートされているリージョンをご覧ください。

Secure Source Manager

組織のポリシーは、新しい Secure Source Manager インスタンスの作成時に適用されます。Secure Source Manager では組織で承認されたリージョンを選択してください。組織のポリシーは、組織のポリシーを作成した後に、リージョン内で新しく作成された Secure Source Manager インスタンスにのみ適用されます。

詳細については、Secure Source Manager の概要ページをご覧ください。

Sensitive Data Protection

リソース ロケーションの制約は、すべての Sensitive Data Protection リソースに適用されます。

組織のポリシーの変更は遡って適用されず、既存のリソースには適用されません。

Sensitive Data Protection に使用できるリージョンについて説明します。

Speaker ID

リソース ロケーションの組織ポリシーは、speaker リソースを作成できるロケーションに影響します。これにより、登録フレーズと音声指紋の保存場所が決定されます。

リソース ロケーションの組織のポリシーは、settings を更新できるロケーションにも影響します。

Speaker ID が利用可能なリージョンについて詳しく説明します。

Speech-to-Text

リソース ロケーションの組織のポリシーは、Speech-to-Text リソースを作成できるロケーションに影響します。また、config リソースを更新できるロケーションにも影響します。

Speech-to-Text v1 は global、eu、us の各リージョンで利用できます。Speech-to-Text v2 で利用可能なリージョンについてご確認ください。

Timeseries 分析情報 API

リソース ロケーションの制約は、すべての Timeseries Insights API リソースに適用されます。

Timeseries Insights API では、リージョンのロケーションのみがサポートされます。特定のリージョンで作成されたインテグレーションは、そのリージョン内のリソースにのみアクセスできます。マルチリージョン ロケーションとゾーン ロケーションの制約は、Timeseries Insights API には影響しません。ただし、リージョンを含む値グループに対する制約には影響します。たとえば、組織ポリシーの値 asia は、Timeseries Insights API に影響しませんが、値 in:asia-locations は影響します。

インテグレーションを作成できるロケーションのリストについては、サポート対象のリージョンをご覧ください。

Transcoder API

job リソースと jobTemplate リソースはリージョン別です。リソースの作成時にロケーションを指定できます。リソースの作成時に組織のポリシーが適用されます。

利用可能なリージョンの一覧については、Transcoder API のロケーションをご覧ください。

Vertex AI

リソース ロケーションの制約は、DataLabelingJob リソースを除くすべての Vertex AI リソースに適用されます。

Vertex AI では、リージョンのロケーションのみがサポートされます。マルチリージョン ロケーションとゾーン ロケーションの制約は Vertex AI には影響しません。ただし、リージョンを含む値グループに対する制約には影響します。たとえば、組織のポリシーの値 asia は Vertex AI には影響しませんが、値 in:asia-locations は影響します。

AI Platform Training で利用可能なリージョンについて説明します。

リソース ロケーションの制約は、すべての Vertex AI Search リソースに適用されます。組織のポリシーの遵守は、過去に遡って適用されることはありません。つまり、リソースのロケーションの制約を適用しても、既存のリソースやそれらのリソースの更新には影響しません。

使用可能なリージョンの一覧については、Vertex AI Search のロケーションをご覧ください。

Virtual Private Cloud

Virtual Private Cloud（VPC）ネットワークは、リージョン仮想サブネットワーク（サブネット）を含むグローバル仮想ネットワークです。VPC ネットワークはグローバル リソースであるため、リソース ロケーションの制約は適用されません。リソース ロケーションの制約は、サブネットワークの作成時にサブネットワークに適用されます。自動モードの VPC ネットワークを作成する場合、サブネットはリソースのロケーション制約で許可されているリージョンにのみ作成されます。

使用可能なリージョンのリストについては、Compute Engine のリージョンとゾーンページをご覧ください。

Workflows

組織のポリシーは、ワークフロー ワークフローの作成時に適用されます。このポリシーは、既存のリソースや既存のリソースの更新には適用されません。ワークフローはリージョン リソースであり、リソース ロケーションの制約を受けます。

リソース ロケーションの制約が適用される場合、リージョンがリソース ロケーションの制約に適用されたものと完全に一致するか、値グループに含まれているワークフローのみを作成できます。たとえば、組織のポリシーで定義されている許可されたロケーションのリストに、us-central1 または us-locations のいずれかが含まれている場合は、us-central1 ワークフローを作成できます。

使用可能なロケーションのリストについては、Workflows のロケーションをご覧ください。