Azure リソースを同一テナントの別のサブスクリプションへ移動させてみた
2025.04.17いわさです。
先日、Azure リソースのサブスクリプション間移行可否を判断するスクリプトを作ってみました。
サブスクリプション全体の移行可否が確認出来たので今回は Azure ポータル上で、サブスクリプション間のリソース移動を行ってみました。
試したところ、前回のスクリプトで「移行 OK」と判定されたものがいくつか移行できなかったりしたので学びになりました。その様子を紹介したいと思います。
今回は次のように、同一テナント上の 2 つのサブスクリプション間でリソース移動を行います。
サブスクリプションのプランが関係するのかよくわかってないですが、どちらのサブスクリプションも Microsoft MVP 特典でもらえるやつで、移行元のhoge subscriptionは「MSDN」（MS-AZR-0063P）、移行先のpiyo subscriptionは「Azure スポンサー プラン」（MS-AZR-0036P）です。プランに依存したダウンタイムは発生しないそうですが一部運用上の制限がある場合があるらしいので少し注意したいところです。
サブスクリプションに関連付けられているユーザーにサービスのダウンタイムは生じません。 ただし、切り替え先のプランによっては、制限がある場合があります。 たとえば、一部のオファーでは運用環境での使用が禁止されているため、該当する場合は、運用環境のリソースを別のサブスクリプションに移動する必要があります。
Azure サブスクリプション オファーの変更 - Microsoft Cost Management | Microsoft Learnより
リソース移動の流れ
リソース移動の検証と実施の方法ですが、リソースグループ内にある「移動」機能を使います。
次のように別のリソースグループ、サブスクリプション、リージョンへ移動するメニューがあるので、今回は「別のサブスクリプションに移動する」を選択します。
検証対象のリソースグループは App Service + Azure Database for PostgreSQL + VNET + α な感じです。App Service には別で用意したマネージド ID をユーザー割り当てしてます。
別のサブスクリプションへの移動を開始すると、まずは移行先のサブスクリプションとリソースを選択します。ここでリソースグループの作成もできるみたいですが、今回は事前に移行先サブスクリプションに空のリソースグループを作成しておきました。
移行先サブスクリプションを選択したら、続いて移行するリソースを選択します。まず「リソースの追加」を押します。
そうすると移行元リソースグループ内のリソース一覧から移行対象を選択することが出来ます。
お試しなので、まずは全てのリソースを選択してみます。
リソースを選択出来たら、それらのリソースが移動できるかを Azure が検証してくれます。
「検証」ボタンを押します。
検証が開始されます。数十秒から数分で、リソースが移動できるか検証結果が出ます。
今回移行できなかったリソース
次のようにリソース移動の検証に失敗しました。
どうやら選択したリソースに対して個別に移動できるできないがステータス表示されるわけではなく、今回選択したリソース一式に対して移行できるかどうかが検証されるみたいです。
なので、ひとつでも移行できないリソースが含まれていると、全部失敗します。
エラーメッセージから、どのリソースが原因なのか読み解くことができるので見てみましょう。
マネージド ID は移行できない
まず、マネージド ID はリソース移動がサポートされていないというメッセージが表示されています。
これは実は既に知っており、前回の移行検証スクリプトのブログでもマネージド ID は移行できないということに触れていました。
そう知っていたのだよ。わざとだよ。
ということでもう一度さきほどの移動操作を行います。リソース選択時に今度はマネージド ID を除外してみましょう。
VNET へデプロイされた PostgreSQL Flexible Server は移動できない
再び移行検証してみたところ、今度は次のようなエラーが発生しました。
なんか先程は出てなかったエラーが色々出てますね。ひとつ潰しても新しいエラーが出たりするのでこのあたりはトライ＆エラーするしかなさそうです。
まず、Postgres Flexible Server が移行できないとされていますね。なんと。
ただし、例のスクリプトによると PostgreSQL Flexible Server は移行 OK だったはず。
Azure resource types for move operations - Azure Resource Manager | Microsoft Learn より
ドキュメントを調べていくうちにわかったのですが、以下によると PostgreSQL サーバーを VNET にデプロイしている場合は他のリソースグループやサブスクリプションへは移動ができないようです。
そしてそれに引っ張られて PostgreSQL Flexible Server が存在する VNET 一式も移動が出来ないということもわかりました。
なんてこったい。
というわけで、今度は PostgreSQL Server と VNET も除外して検証してみます。
VNET 統合された App Service は移動できない
また検証エラーが発生しました。
今度は App Service が移動できないとのこと。よく見ると先程のエラーメッセージにも記載されていました。
以下のドキュメントによると VNET 統合されている App Service は移動できないそうです。
リソース グループまたはサブスクリプション間で Azure App Service リソースを移動する - Azure Resource Manager | Microsoft Learn より
ただし、PostgreSQL と違って VNET 統合を一度削除し、移動後に再接続すれば良いらしいです。
ネットワークの関連具合でダウンタイムが発生する可能性はありそうですが仕方ない。
以下から VNET との接続を切断します。
VNET 統合が解除されました。
検証成功したら移行できる
ここまで来てようやく App Service も含めて移行検証に成功しました。
App Service には移行できないマネージド ID が割当されてますが、そこは問題ないみたいです。マネージド ID 割当時に別のサブスクリプションの ID を選択できるので、同一テナントであれば良いみたいですね。まぁ Entra 側なので言われてみればそうなのかという気もします。
検証に成功したら「次へ」ボタンが押せるようになるので押します。
そうするとリソース移動の最終確認画面が表示されます。
注意事項のチェックボックスを ON にし、「移動」ボタンを押します。
移動が開始されました。
以下は移動元のリソースグループで、上部に「リソースを移動しています」というバナーが表示されています。
以下は移動先のリソースグループです。こちらにも同様のバナーが表示されています。
これら以外のリソースグループではバナーは表示されませんでした。
メッセージとしては次のように「正常に移動しました」というメッセージが表示されますが、まだ移動中です。完了してないので注意してください。
今回の私の構成だと 4 ~ 5 分で移動が完了しました。
以下は完了後の移動元リソースグループです。除外したリソースが残っていることがわかります。
以下は完了後の移動先リソースグループです。別のサブスクリプションなのですが移行に成功したことがわかります。
以下のドキュメントによると「既存のリソースは引き続き完全に動作します。 たとえば、仮想マシンを別のリソース グループに移動する場合、移動の間に、それを削除することはできず、そのプロパティ (サイズなど) を変更することはできません。 このような制限にもかかわらず、仮想マシンは正常に動作し続け、それに依存するサービスでダウンタイムが発生することはありません。」と説明されているので、移動操作によるダウンタイムは発生しないようです。
ただ、先程のような App Service の VNET 解除など、移動させるために事前に設定変更が必要な場合があって、その変更内容自体にダウンタイムや影響がある場合があるのでそのあたりは注意しながら進める必要がありそうです。
さいごに
本日は Azure リソースを同一テナントの別のサブスクリプションへ移動させてみました。
思ったより検証フェーズで色々引っかかりました。特に今回の範囲であれば VNET 統合されていると制約が発生しやすい印象です。次回は VNET と仮想マシン・ロードバランサーくらいの IaaS ベースのワークロード移行を試してみたいと思います。
先日のブログでスクリプトによる検証を行いましたが、スクリプト上は移動 OK なものでも実際に移動の検証をさせてみると NG になる場合があるのでその前提で移行計画を立てる必要がありそうですね。
