Azure Site Recovery の A2A / Azure to Azure のシナリオ (Azure 環境同士で DR を組むこと) において、よりセキュリティ要件を高めたい場合、プライベートエンドポイントを用いて閉域化構成ができます。

実機検証を行ってみて重要だったポイントについての備忘録です。

以下、Azure Site Recoveryを構成する際の主要コンポーネントである
・Azure Site Recovery Vault
・キャッシュ用ストレージアカウント　の2つについてまとめます。

Azure Site Recovery Vault

・ターゲットリージョンにデプロイ必須。(例西リージョンのVMをフェールオーバーしたい場合には、東リージョンにデプロイする。

・プライベートエンドポイントは1つのAzure Site Recovery vaultに対して東西２つ作成する。

・プライベートエンドポイント作成の際には動的IPが必須で、 (公式ドキュメントには動的IPが必須である旨はなかったと思います。しかもAzure Portalで静的IPが選べてしまうので注意です。) DNSゾーン統合の設定はオン推奨。

・上記のプライベートエンドポイントは1つのPEに対して最大9個のIPが払いだされるので、サブネットのIPレンジが9個空いてないといけない。

・プライベートエンドポイントのFQDN統合先のプライベートDNSゾーンはソースリージョン、ターゲットリージョンそれぞれに２つ必要。

・システム割り当てマネージドIDを有効化する。

キャッシュ用ストレージアカウント

・レプリケーション用、再保護用にそれぞれ1つずつ必要で、ソースリージョン、ターゲットリージョンに配置する。

・データ管理→データ保護より"BLOBの論理的削除"は無効化する。

・Azure Site RecoveryのManaged IDに"共同作成者"と"ストレージBLOBデータ共同作成者"のRBACロール付与を行う。

・ストレージアカウントキーの有効化を行う。

（参考) 実機検証環境でのネットワークまわり

①リージョン
東　Japan East (ソースリージョン)
西　Japan west (ターゲットリージョン)
②VNet
東西にそれぞれVNetひとつずつ(以下、東VNetと西VNet)
③ピアリング
東VNetと西VNetはピアリングしている
④VNetLink
東VNetと西VNetの両方がプライベートDNSゾーンとそれぞれVNetLinkしている

よって、本検証環境における名前解決の経路イメージは
VNet→Azure DNS→プライベートDNSゾーン→プライベートエンドポイント