長くエンタープライズ顧客を相手にしていると単純なLift&Shift（オンプレからの移行）もあるけど、サブスクリプション間で移行したいといった要件も出てきますね。慣れている人は「Azure ADテナントが違って」とか「サブスクリプション移行をしたくて」といった言葉が出てきただけで、変な汗が出てくること間違いないｗ（私だけ？汗）
それもそのはずで、契約形態や移行したいシステムリソースによって対応方法もいくつかあり、簡単なものから複雑なもの、リスク込みのものや金かけてでもダウンタイム最小限にしたいものまであるから、といった実情があるからだろう。
例えばこんなパターンが考えられる。
１）EA契約のサブスクリプションからCSP契約のサブスクリプションへ移行したい
２）EA契約同士、もしくはCSP契約同士でサブスクリプションを移行したい
３）無償利用で作ったものをEA契約もしくはCSP契約へ移行したい
４）同じ契約内で異なるサブスクリプションへ移行したい
１～３はそもそもAzure AD テナントが変わる前提で、４）だけ変わらない。あと２のEA契約同士というのは、本社とグループ会社で、というのが多いが、CSP間で、とかはそもそもビジネスの主管を変えるって話になるので技術の前に話し合うべきことが多いことも押さえておこう。まぁ平たく言えば、hogehoge.comで管理されている環境で作ったシステムリソースをfugafuga.comで管理されているシステムリソースへ移行したいのか、hogehoge.comで管理されている環境は変えずに別のサブスクリプションへ移行したいのかって違いがあるということ。
なーんだ、システムリソースはあるんだから契約情報だけ差し替えてくれればオッケーっす！マイクロソフトさんよろ！なーんて考えていると甘い。マイクロソフトはセキュリティの会社と言われているぐらいなので、締結された契約をそんな安易に企業間の都合だけで対応できるようになんて仕組みにしていない。たぶんｗ
とはいえ技術的な側面ではしっかりとお互いの認証を行い双方での疎通が取れる状態にすることはできるので、今回はその１つである「異なるAzure ADテナントの異なるサブスクリプション間のvNET同士をピアリングし、プライベート間で通信できるようにする」ということを試した結果を記事にしておく。
やりたいことは簡単。koiketmp1@outlook.jp（マイクロソフトアカウント）のVMからkoiketmp1@outlook.com（マイクロソフトアカウント）のVMへプライベート接続でデータを送りたい。つまりoutlook.jpとoutlook.comの仮想ネットワーク(vNET)間をプライベートピアリングして接続したい、ということ。
※社員用サブスクは制限かかっているようなのでできまへん。ちーん。
ちなみに以下のオフィシャルサイトを参考にしてほしい。
https://docs.microsoft.com/ja-jp/azure/virtual-network/create-peering-different-subscriptions
なんだか小難しい手順が書かれているが、簡単に言うと以下となる。
１）Azure ADで「ゲストユーザー招待」を完了させておけ
２）お互いのvNETで相手側のアカウントが操作できるよう
「ネットワーク共同作成者」をRBAC(IAM)で相互で設定しておけ
３）ピアリング設定をする際は「リソースID指定」で認証してやれ
ということでやってみよう。
まず「outlook.jp」側のリソースがこれ。
「cent-vnet」という名前のvNETに「cent0001」という仮想マシンが 172.16.0.4 というプライベート用のNiCが付いた状態でいる。
もう片方は「outlook.com」側のリソース。
「cent-vnet2」という名前のvNETに「cent0003」という仮想マシンが 192.168.0.4 というプライベート用のNiCが付いた状態でいる。
とりあえずAzure Portalの左ペインからAzure Active Directoryを選択。
「ユーザー」から「＋新しいゲストユーザー」を選択し、以下メールアドレスを入力して「招待する」を押す。
しばらくすると上で入力されたメールアドレスへ以下のようなゲストユーザー招待のメールが届く。
メール内にある「招待の承諾」を押すことブラウザから認証が走るので、招待された側は自分（outlook.jp側）のアカウントとパスワードを入力して招待を受ける。
この作業はoutlook.jp側からoutlook.com側への招待も同じく実施する。つまりそれぞれ1回ずつ招待し計2回やる。
反映に少し時間がかかるかもしれないが、以下のような画面がAzure Active Directoryのユーザー一覧に出力されることを確認しよう。
※これはoutlook.com側のアカウントでログインした時の画面。koiketmp1@outlook.jpのアカウントがゲストユーザーとして反映されていることが確認できる。
これでとりあえずAzure AD側では双方のアカウントが認識された状態となる。次はそれぞれのvNET（cent-vnetとcent-vnet2）にて、RBAC(IAM)を操作し、お互い「ネットワーク共同作成者」のロールを付与する。つまりお互いがお互いのvNETに対して作成や更新ができる状態にしよう。
outlook.jpとoutlook.com両方のvNETに、以下のようにアクセス制御(IAM)の設定を入れて保存する。
保存が正常に終わると「アクセス制御(IAM)」の「ロールの割り当て」画面に、指定したアカウントとロールが一覧に表示されるので確認しておこう。ちなみにRBAC（あーるばっく）とはRole-Based Access Contolの略で、この「アクセス制御(IAM)」を指します。
双方（outlook.jpとoutlook.comの両方）でのRBACの設定が終われば最後はピアリング。
ここまでで、以下の１）と２）が終わった状態。
１）Azure ADで「ゲストユーザー招待」を完了させておけ
２）お互いのvNETで相手側のアカウントが操作できるよう
「ネットワーク共同作成者」をRBAC(IAM)で相互で設定しておけ
３）ピアリング設定をする際は「リソースID指定」で認証してやれ
最後に３）を行うが、先に許可を許す側のvNETの「プロパティ」を選択し、「リソースID」をコピっておこう。
※2画面で別々のアカウントでログインしてやっていると、サインアウトしないといけない部分などがタイミングによってあるので、ここからは1画面でやるのがよい。
お互いのリソースIDをメモ帳などにコピーしたら、vNETの「ピアリング」から「追加」を選ぶ。
Peeringの設定ではピアリングの名前は適当（任意）でOK。リソースIDを知っている、というチェックボックスにチェックを入れる。
先ほどメモ帳でコピーしたリソースIDを、べたっと張り付けるとディレクトリがプルダウンで選択できるようになるため、該当のっディレクトリを選択して「認証」を押す。
上の画面ではoutlook.jp側のアカウントでログインしoutlook.jp側のvNET(cent-vnet)のピアリングを追加する画面。なのでoutlook.com側のリソースIDとディレクトリを指定してあげて認証する。認証が終われば1番下のOKボタンを押す。
以下のように設定したピアリング項目がvNETのピアリング画面に表示されればOK。
※ピアリング状態が「開始済み」なので、まだ片方向でしか設定が完了していないことを示す。双方向でピアリングが確立していると「接続済み」というステータスになるため、現時点ではまだvNET Peeringは終わっていない。
ということで今度はもう片方側でログインして同じようにピアリングの設定を行おう。
こんな感じで「接続済み」ステータスになっていれば万事OK！！！
ちなみにこんなエラーが出てピアリングがうまく行かない時がある。
この場合はピアリング先のアカウントがログイン状態になっている、とか、Azure AD側の反映が遅れている、などの原因が考えられるため、１日おいて片方のアカウントだけでログインしてもう一度設定することをお薦めする。
では最後に仮想マシン間でチェックしよう。
outlook.jp側もoutlook.com側も、どちらのVMからも双方向でpingチェックの通信が通ることが確認できた。ってことでファイルをコピーしてみよう。
172.16.0.4 のVMから192.168.0.4 のVMへ scp でファイルコピー。
すばらしい。
ってことで、異なるアカウント同士で異なるネットワークセグメント間のVM同士を仮想ネットワーク単位でピアリングすることができました。VMイメージのvhdをエクスポートしてインポートしたり、VMを新規作成してデータだけblobへ配置して吸い上げる、Azure Filesで双方でマウントする、などなどいろんな移行方法はあるけど、サーバー間を繋げることでプライベート網を使った接続が簡単にできるので、今後の移行方法の１つとして考えてもらえればと。
