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ゾーン→プライベートエンドポイント