組織リソース間でプロジェクトを移行する

Cloud de Confiance by S3NS プロジェクトをリソース階層内の新しい場所に移動するには、メタデータを更新します。プロジェクトを新しい組織に移行する前に、移行がプロジェクトのリソースと構成にどのように影響するかを確認してください。

リソース階層内のプロジェクト

プロジェクト リソースは、 Cloud de Confiance by S3NS組織リソースでの基本レベルの構成エンティティです。プロジェクトは組織リソースの下に作成され、フォルダまたは組織リソース自体の下に配置でき、リソース階層を形成します。

組織リソース間では、買収、規制要件、ビジネス ユニットの分離などにより、プロジェクトの移行が必要な場合があります。Resource Manager API を使用して、これらのプロジェクトを移行できます。移行オペレーションは、オペレーション名を表す文字列を返します。また、この API を使用すると、移行をロールバックし、必要に応じてプロジェクトを階層内の元の場所に移行できます。

移行のシナリオ

プロジェクトの場所によって、次の 2 つのパスのいずれかを選択します。

  • プロジェクトをある組織から別の組織リソースに移行する。
  • スタンドアロン プロジェクト（組織なしで作成されたプロジェクト）を組織リソースの階層に移行します。

組織リソースに関連付けられた後でプロジェクトを [組織なし] に戻す必要がある場合は、Cloud カスタマーケアにお問い合わせください。組織から組織なしへのセルフサービス ロールバックはサポートされていません。

API に加えて、 Cloud de Confiance コンソールを使用してプロジェクトを選択し、新しい親の宛先を割り当てることで、プロジェクトを移動することもできます。

プロジェクトの現在の状態を特定する

始める前に、プロジェクトが組織リソースに関連付けられているかどうかを確認する必要があります。これにより、組織間パスまたは組織なしパスのどちらを使用するかが決まります。

プロジェクトの親組織リソースに対する resourcemanager.organizations.get 権限がない場合、プロジェクトがCloud de Confiance コンソールの実際の組織のもとで想定どおりに反映されていない可能性があります。これにより、プロジェクトがどの組織リソースにも関連付けられていないように見えることがあります。

プロジェクトが組織リソースに関連付けられているかどうかを確認するには、次のコマンドを実行します。

gcloud

gcloud projects get-ancestors PROJECT_ID

PROJECT_ID は、移行するプロジェクトの ID に置き換えます。

出力の階層に organization リソースタイプが含まれている場合、プロジェクトはすでに組織階層の一部になっています。

organization タイプがないか空の場合、プロジェクトは組織リソースのないスタンドアロン プロジェクトです。

プロジェクトの状態に応じて、関連するガイドに沿って操作します。

移行の仕組み

プロジェクトの移行はデータ転送ではありません。サービス、データベース、仮想マシン（VM）インスタンスはアクティブなままで、ダウンタイムは発生しません。代わりに、移行によってプロジェクトの親リソースが更新されます。 Cloud de Confiance by S3NS は階層継承モデルに従うため、プロジェクトのセキュリティ ポスチャーは、新しい親に接続された瞬間に変更されます。

機能 ステータス 影響
プロジェクト ID とプロジェクト番号 変更なし API キー、サービス名、ハードコードされた ID は変更されません。
データとリソース 変更なし VM、ストレージ バケット、データベースはオンラインのままです。
直接 IAM ロール 変更なし プロジェクトに直接付与されたロールは、プロジェクトとともに移動します。
継承された IAM ロール 変更点 移行元の組織レベルまたはフォルダレベルで付与されたロールは失われます。
組織のポリシー 変更点 ソースの制約は、宛先の制約に置き換えられます。
割り当て 変更点 継承された組織レベルの割り当ては失われます。プロジェクト レベルの割り当ては残ります。
請求先アカウント 変更なし プロジェクトは元の請求先アカウントにリンクされたままになります。

割り当ての影響

特定のリソースレベルで割り当てが定義されている場合、移行後に次の要素が適用されます。

  • プロジェクト レベルで定義された割り当ては変更されません。
  • 組織リソースレベルで定義された割り当ては転送されません。組織は、継承された割り当てまたは割り当てのオーバーライドを失います。

次のページを使用して、組織リソースに適用する割り当てを判断できます。

例

$ gcloud alpha services quota list --service=compute.googleapis.com --consumer=projects/workloadyee --filter="metric: compute.googleapis.com/cpus"

...
  - defaultLimit: '600'
    dimensions:
      region: us-central1
    effectiveLimit: '650'
...

重要な考慮事項

移行を開始する前に、サービスの中断を防ぐために、次のリスクの高い領域を確認してください。

  • 割り当て上限: 移行先の組織の割り当て上限が移行元よりも低い場合、プロジェクトが移行先に到着した時点で割り当てを超過する可能性があります。

  • Asset Inventory: Cloud Asset Inventory のリソースの完全なリストの更新は、移行後に完全に反映されるまでに数日かかることがあります。

  • 費用と割引: 元の組織に SKU ベースの割引またはエンタープライズ割引プログラム（EDP）の割引が適用されていた場合、Google の営業担当者と交渉するまで、新しい組織にはそれらの割引は適用されません。確約利用割引（CUD）と Google Cloud Marketplace での購入も再購入が必要になる場合があります。

  • サポート階層: 移行先の組織に有効なサポート契約がない場合や、サポートレベルが低い場合は、現在のサポート階層が失われる可能性があります。

  • カスタムロール: プロジェクトが組織レベルで定義されたカスタム IAM ロールに依存している場合、それらのロールは移行先には存在しません。移動する前に、移行先の組織で再作成してください。

移行のロードマップ

次のロードマップを使用して、プロジェクトの移行プロセスを進めます。

  1. 準備: 移行計画を作成して、タイミングを調整します。
  2. 実行: IAM ロールを割り当て、組織のポリシーを構成し、移行を実行します。
  3. 確認: 移行後のタスク（継承されたポリシーの監査、請求情報の更新など）を完了します。

次のステップ