Azure リージョン選定と冗長化（DR）

山崎行政書士事務所
9月11日
読了時間: 8分

— Data Residency／責任分界／SLA／監査を織り込む“法務×技術”アーキテクチャ —

著者：山崎行政書士事務所クラウド法務・アーキテクチャ支援チーム

発行日：2025-09-11

要旨（Abstract）

Azure におけるリージョン選定と DR 設計は、**技術指標（レイテンシ／可用性／コスト）だけでは最適化できない。Data Residency（データ所在）、越境移転の適法性（DPA／SCC／TIA）、Shared Responsibility Model における利用者責任、SLA と補償範囲、監査対応（ログの保管・提示性）を同一設計書の中で整合させる必要がある。本稿は、リージョン選定 → DR 方式 → データ／ログ／鍵 → 監査証跡の順に検討軸を体系化し、実装テンプレート（Policy/Bicep/KQL）と運用証跡（Evidence Pack）**まで落とし込む。

キーワード：Region Pair, Availability Zone, GRS/GZRS/RA‑GZRS, Azure Site Recovery, Failover Group, Cosmos DB Multi‑Region, Data Residency, DPA/SCC/TIA, SLA, Shared Responsibility, Purview, Sentinel, Immutable (WORM)

リージョン選択における考慮事項
リージョン間冗長化（DR）アーキテクチャ
代表シナリオとトレードオフ
設計テンプレ（Policy/Bicep/KQL 抜粋）
監査・運用：Evidence Pack と DR 演習
まとめ（推奨アクション）
山崎行政書士事務所のご支援（PR）— 参照リンク集（べた貼り）

1. リージョン選択における考慮事項

1.1 リージョン選定の要件（技術 × 法務）

レイテンシ（遅延）

技術：主要ユーザー拠点に近接するリージョンで応答時間と体感性能を最適化。
法務：近接配置は越境移転の抑制に寄与し、説明・合意のコストを低減。

コスト

技術：同一サービスでもリージョン差がある。ストレージ／帯域／監視の継続費用を含めて試算。
法務：EU 内選定はGDPR 適合が設計しやすい反面、SCC/監査の初期整備が別途必要な場合あり。**総保有コスト（TCO）**で評価。

法的要件（Data Residency／越境移転）

APPI（個人情報保護法）：国外移転時の同意・保護措置、第三者提供の管理。
GDPR：域外移転には SCC 等の根拠と**TIA（移転影響評価）**が必要。
ベンダー契約：DPA（Data Processing Addendum）におけるデータ複製／バックアップ先や下位委託を確認。

可用性／機能対応

Availability Zone 有無、新機能のリージョン提供状況、**制約（Key Vault HSM、Confidential Computing、規制対応 SKU 等）**をカタログで確認。

ログ／鍵／監査

Log Analytics ワークスペースのリージョン、Sentinel のデータ居所、Immutable（WORM）保管の可否をデータ分類と紐づけて選定。
Key Vault／Managed HSM の設置リージョンと**鍵の主権（CMK/BYOK）**を明確化。

1.2 SLA と責任分界（Shared Responsibility）

SLA：サービス／リージョン／冗長化オプションにより稼働率目標が異なる。補償は通常サービスクレジットであり、業務損失はカバーされない。
責任分界：IaaS/PaaS いずれもバックアップ設定／暗号化／DR 切替は利用者責任の領域が残る。設計書に“誰が何をいつ行うか”を明記する。

1.3 ログ管理・監査対応（データ所在まで説明可能に）

どのリージョンに、どのログを、何年保管するかを**データ種別（PII/PHI/秘密情報）**と照合。
DR 時のログ複製先、監査要求（金融等）での提示形式、**改ざん耐性（WORM／署名）**を Evidence Pack へ反映。

2. リージョン間冗長化（DR：Disaster Recovery）

2.1 Region Pair（ペアドリージョン）の活用

例：Japan East ↔ Japan West, West Europe ↔ North Europe。
特徴：更新の段階展開／相互分離／優先復旧が原則。
法務留意：ペア先が国境を跨ぐ場合、バックアップ複製＝越境移転となる。DPA/SCC/TIAとプライバシーポリシーの明示を用意。

DR 基本構図（Active/Passive）

         Primary Region (R1)                Secondary Region (R2)
 ┌────────────────────────┐      ┌────────────────────────┐
 │  App/DB/Storage/KeyVault │      │  Warm Standby / Replicas      │
 │  Zone-Redundant (where)  │      │  (Auto/Manual Failover)       │
 └───────────┬──────────────┘      └───────────┬──────────────┘
             │  Async Replication                      │
             └─────────────────────────────────────────┘
                 DNS / Traffic Manager / Front Door

RTO/RPO 設計

RPO（許容データ損失）：サービス別に非対称（例：Storage GRS≠SQL GeoReplica≠Cosmos DB）。
RTO（復旧時間）：切替オーケストレーション（ASR／Failover Group／Runbook）と人的承認の有無で変動。

2.2 ストレージ冗長化（LRS/ZRS/GZRS/GRS/RA‑GZRS）

LRS：単一リージョン内、多重コピー。
ZRS：同一リージョンの複数 AZへ同期。
GZRS：ZRS を別リージョンへ非同期複製。
GRS：単一リージョン→ペアへ非同期複製。
RA‑GZRS/RA‑GRS：セカンダリから読み取り可。

法務注意：G* 系（Geo-*）は別地域へコピーされる。規程／同意／契約で明示し、**移転停止（GRS→LRS/ZRS）**の判断基準を文書化。

2.3 Azure Site Recovery（ASR）

対象：Azure VM／オンプレ VM。
構成：レプリケーションポリシー、ネットワークマッピング、フェイルオーバー計画（計画/非計画）、テストフェイルオーバー。
設計要点：IP 付与、名前解決（DNS/Private DNS）、秘密情報（Key Vault）、接続先（PE/Firewall）の二重化。
法務注意：レプリカの保存先国、ログの保管場所、テスト時の個人データ取り扱い（匿名化・生成データ使用）を規定。

2.4 データ層ごとの DR パターン

Azure SQL：Auto‑Failover Group で DB/ログインのペア管理。読み取りセカンダリ活用で性能平準化。
PostgreSQL/MySQL（Flexible）：クロスリージョンリードレプリカ → 昇格手順と逆レプリケーション計画を明文化。
Cosmos DB：マルチリージョン（単/複数書込）、整合性レベルで RPO/RTO を調整。
Key Vault／HSM：ソフトデリート＋パージ保護必須、リージョン間復旧手順を別紙に。
AKS：クラスター二重化＋**レジストリ（ACR）**の Geo‑replicate、Stateful は CSI スナップショット＋Backup で対応。
メッセージング／イベント：サービス固有の DR（例：ネームスペース切替／別リージョンにミラー）を Runbook 化。

2.5 アイデンティティ／アクセス

Microsoft Entra ID はグローバル冗長だが、CA/PIM/Break‑Glass（MFA 免除の緊急アカウント）を運用で担保。
ハイブリッド：ID 同期（Entra Connect/Cloud Sync）側の DR、対向ディレクトリ／ネットワークの二重化も忘れない。

3. 代表シナリオとトレードオフ

3.1 Japan East（主）＋Japan West（従）

長所：越境移転リスクが低い／国内規制との整合が取りやすい。
短所：広域災害の相関リスク、価格差や機能提供差。

3.2 Japan East（主）＋アジア他地域（従）

長所：地理的隔離が大きく、BCP に強い。
短所：**越境移転の法務対応（SCC/TIA/説明）**と、監査での提示事項増。

3.3 EU 圏内（West Europe＋North Europe）

長所：EU 域内完結で GDPR の説明が容易。
短所：日本等のユーザーに対するレイテンシ増、コスト差。

3.4 オンプレ＋Azure DR（ASR ハイブリッド）

長所：既存 DC を活かしつつクラウド冗長。
短所：二重運用の複雑性、ネットワーク障害時の切替実効性を定期演習で保証する必要。

4. 設計テンプレ（抜粋）

4.1 Allowed locations（Policy）：指定リージョン以外を拒否

{
  "properties": {
    "displayName": "Allow only JP/EU regions",
    "policyType": "Custom",
    "mode": "All",
    "parameters": {
      "listOfAllowedLocations": {
        "type": "Array",
        "defaultValue": ["japaneast","japanwest","northeurope","westeurope"]
      }
    },
    "policyRule": {
      "if": { "field": "location", "notIn": "[parameters('listOfAllowedLocations')]" },
      "then": { "effect": "deny" }
    }
  }
}

4.2 Storage の冗長化（Bicep スケッチ）

resource sa 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'stprodprimary'
  location: 'japaneast'
  sku: { name: 'Standard_GZRS' }   // 例：GZRS（要件で調整）
  kind: 'StorageV2'
  properties: {
    allowBlobPublicAccess: false
    publicNetworkAccess: 'Disabled'
    encryption: { keySource: 'Microsoft.Storage' } // or Keyvault (CMK)
    immutableStorageWithVersioning: { enabled: true } // WORM
  }
}

4.3 Azure SQL：Auto‑Failover Group（T‑SQL 抜粋）

-- 事前に R2 側へサーバ準備済みとする
ALTER DATABASE [appdb] SET PARTNER = 'tcp:appdb-secondary.database.windows.net';
-- 管理は Portal/CLI/ARM を推奨。T-SQL は概念例。

4.4 DR 可観測性（KQL スニペット）

// フェイルオーバー事象の近傍メトリクス（例：SQL/ストレージ）
AzureDiagnostics
| where TimeGenerated > ago(24h)
| where Category in ("SQLSecurityAuditEvents","StorageRead","StorageWrite")
| summarize count() by Category, bin(TimeGenerated, 5m)

// ASR テストフェイルオーバーの結果集約（イベント名は環境で調整）
AzureActivity
| where OperationNameValue has "Site Recovery"
| summarize any(Properties) by ActivityStatus, bin(TimeGenerated, 1d)

5. 監査・運用：Evidence Pack と DR 演習

Evidence Pack（構成証跡）

アーキ図（リージョン／ゾーン／データ流／鍵の所在）
契約対応（DPA／SCC／TIA 抜粋と設計項目の対照表）
設定証跡（Policy/冗長化設定/Failover Group/ASR プロファイル）
ログ／保持（ワークスペース構成、WORM、保持期間、保存リージョン）
演習記録（テストフェイルオーバー結果、RTO/RPO 実測、是正計画）

DR 演習（四半期推奨）

テスト FO（読み取り系） → 計画 FO（メンテ窓） → 非計画 FO（想定インシデント） を段階化。
DNS/トラフィック切替、機密情報流用防止（検証データ）、復旧後の逆レプリケーションまで Runbook 化。

6. まとめ（推奨アクション）

法務×技術の同時設計：Data Residency／越境移転と冗長化方式を同じ表で整理。
SLA／責任分界の明文化：**“誰が何をいつ”**を設計書と運用手順へ落とす。
Storage 冗長化と DB/ID/ログの整合：GZRS/GRSとFailover Group／ASR／WORMを連動。
Evidence Pack と DR 演習を定常化：RTO/RPO 実測で改善ループを回す。

7. 山崎行政書士事務所のご支援（PR）

「クラウド法務（DPA/SCC/TIA/監査）× Azure 技術（Region/DR/鍵/ログ）」を一体で設計・実装・証跡化します。

要件整理：対象データ／居所／越境の是非、RTO/RPO、SLA と BCP の整合を初回 1 枚絵に集約。
テンプレ提供：Policy／Bicep／Failover Runbook／KQL をお客様要件に合わせて即運用可能な形で提供。
監査対応：Evidence Pack（設計対照表／スクリーンショット／演習ログ）を監査提出レベルで整備。
移行伴走：既存環境の差分是正計画（例外棚卸し・期限付与・改善 KPI）と演習主導まで完走します。

初回ディスカッションの論点例 どのデータをどのリージョン／冗長化で扱うか（分類×居所マトリクス）。 GRS/GZRS の越境説明と同意・契約の整合は？ DB/ID/ログのRPO/RTOをどう“揃える”か？ Evidence Pack の構成と、監査依頼時の提示動線は？

参照リンク集