AKS Backupとクロスリージョン復元でコンテナBCPを考える

コンテナ基盤のBCPはVMより説明が難しい

RTO/RPOと運用手順を文書化する

確認日：2026年7月9日対象読者：経営層、情シス担当者、クラウド運用担当者、AKS運用担当者、監査対応担当者、BCP/DR担当者対象領域：Azure Kubernetes Service、AKS Backup、Azure Backup、Cross Region Restore、BCP、DR、RTO、RPO、コンテナ運用規程

結論

AKS Backupとクロスリージョン復元は、コンテナ基盤のBCP/DRを説明するための重要な選択肢です。ただし、AKS Backupを設定しているだけでは、経営層や監査に対して「いつまでのデータを、何分で、どの業務状態まで戻せるのか」は説明できません。

コンテナBCPでは、AKSクラスター、Kubernetesリソース、Persistent Volume、コンテナーイメージ、Secrets、Ingress、DNS、Key Vault、外部DB、監視、承認手順までを一体で整理する必要があります。

特にクロスリージョン復元では、Vault Tierに格納したバックアップを使い、Geo冗長のBackup VaultでCross Region Restoreを有効にすることで、Azureペアリージョン側への復元が可能になります。ただし、Microsoft公式では、Vault Tierのスケジュール済み復旧ポイントは1日1つで、プライマリリージョンのRPOは最大24時間、セカンダリリージョンではレプリケーションに最大12時間追加され、有効RPOは最大36時間になると説明されています。したがって、「クロスリージョン復元を使えば短時間・低RPOで自動復旧できる」とは言えません。 

理由

VMのBCPは、比較的「VM、ディスク、ネットワーク、DNS、バックアップ」という単位で説明できます。一方、AKSのBCPは、Kubernetes上の宣言的なリソース、永続ボリューム、コンテナーイメージ、Namespace、StorageClass、Secret、ConfigMap、CRD、Ingress、Managed Identity、外部PaaSが絡むため、復旧対象が分散します。

Microsoft公式では、AKS Backupは、AKSクラスターで実行されるコンテナー化されたアプリケーションとデータをバックアップ・復元するクラウドネイティブなプロセスであり、CSIドライバーベースのAzure DiskとAzure SMB Files上のPersistent Volume、およびクラスター状態をスケジュールバックアップできると説明されています。復元は元のAKSクラスターまたは代替AKSクラスターに対して実行できますが、ターゲットAKSクラスターにはBackup ExtensionのインストールとTrusted Accessが必要です。

つまり、AKS Backupは有効な技術手段ですが、BCP文書・RTO/RPO定義・復旧手順・承認証跡・復元訓練がなければ、企業としての説明責任には届きません。

数字で見る：コンテナBCPで最低限確認すべき20項目

No.	確認項目	確認内容
1	対象業務	どの業務・API・バッチを復旧対象にするか
2	業務重要度	Tier 1、Tier 2、Tier 3の分類
3	RTO	何分・何時間以内に業務再開するか
4	RPO	何時間分のデータ損失を許容するか
5	対象Namespace	どのNamespaceをバックアップするか
6	Cluster-scoped resources	CRD、ClusterRole、StorageClass等を含めるか
7	Persistent Volume	Azure Disk、Azure Files、非対応ストレージの区別
8	CSI対応	in-tree volumeではなくCSIベースか
9	Backup Tier	Operational Tierのみか、Vault Tierも使うか
10	Cross Region Restore	Geo冗長Backup VaultとCRRを有効にするか
11	復元先AKS	既存クラスター、代替クラスター、DRクラスターのどれか
12	ノード容量	復元先AKSに十分なCPU/メモリ/IPがあるか
13	コンテナーイメージ	ACR geo-replication、タグ、Digestを管理しているか
14	Secrets	Kubernetes Secret、Key Vault、Managed Identityの復旧
15	Ingress/DNS	Front Door、Traffic Manager、Private DNSの切替
16	外部DB/PaaS	AKS Backup対象外の依存先DR
17	アプリ整合性	Backup Hook、DB停止/Flush、Restore Hook
18	復元訓練	四半期・半期・年次などの実施記録
19	証跡	Backup Job、Restore Job、承認、ログ、テスト結果
20	例外管理	バックアップ対象外、未対応PV、手動復旧の管理

1. AKS Backupの全体像

AKS Backupは、Backup VaultとAKSクラスター内にインストールするBackup Extensionを使って、KubernetesリソースとPersistent Volumeをバックアップ・復元する仕組みです。Microsoft公式では、Backup Extensionの利用は必須であり、Backup VaultがExtensionと通信してバックアップ・復元操作を実行すると説明されています。

図1：AKS Backupの基本構成

Azure Backup / Backup Vault
        │
        │ Trusted Access
        ▼
AKS Cluster
        │
        ├─ Backup Extension
        │
        ├─ Kubernetes Resources
        │    ├─ Namespace
        │    ├─ Deployment
        │    ├─ Service
        │    ├─ ConfigMap
        │    ├─ Secret
        │    └─ CRD等
        │
        └─ Persistent Volumes
             ├─ Azure Disk CSI
             └─ Azure Files CSI / SMB

2. Operational TierとVault Tierを分けて考える

AKS Backupでは、Operational TierとVault Tierを分けて考える必要があります。

Operational Tierは、主にスナップショットを使った同一リージョン内の運用復旧に向きます。Vault Tierは、バックアップをテナント外のVault側へ移動し、長期保持やクロスリージョン復元に利用する位置付けです。Microsoft公式では、Vault Tierに格納されたバックアップはオフサイトに保存され、テナント侵害、悪意ある攻撃、ランサムウェア脅威からの保護に役立つと説明されています。

表1：Operational TierとVault Tierの比較

項目	Operational Tier	Vault Tier
主な目的	同一リージョンでの運用復旧	長期保持、リージョン障害対策
保存方式	スナップショット＋BLOB上のクラスター状態	Vault側のバックアップデータ
対象PV	Azure Disk、Azure Files SMB	Azure DiskベースPVのみ
Azure Files	サポートあり。ただし制限あり	非対応
バックアップ頻度	4、6、8、12、24時間間隔	1日1つの復旧ポイントが対象
リージョン間復元	原則対象外	Geo冗長＋CRR有効時にAzureペアリージョンへ復元可能
RPOの考え方	設定したバックアップ頻度に依存	Primary最大24時間、Secondary最大36時間
主な用途	誤削除、設定ミス、同一リージョン復元	リージョン障害、ランサムウェア対策、長期保全

Azure Backup for AKSでは、最小バックアップ頻度は4時間で、6、8、12、24時間の選択肢もあります。ただし、Vault Tierへ移動できるのは24時間内の最初の成功バックアップであり、Vault TierはAzure Diskベースのボリュームのみが対象です。

3. クロスリージョン復元の基本構成

クロスリージョン復元では、プライマリリージョンのAKSバックアップをVault Tierに格納し、Backup VaultをGeo冗長にしてCross Region Restoreを有効化します。そのうえで、Azureペアリージョン側のAKSクラスターへ復元します。Microsoft公式チュートリアルでは、セカンダリリージョンに格納されたAKSバックアップを使い、リージョン障害時にAKSクラスターを復旧する手順が説明されています。

図2：AKS Backupによるクロスリージョン復元

Primary Region
┌─────────────────────────────┐
│ AKS Cluster                  │
│  ├─ Kubernetes Resources      │
│  └─ Azure Disk PV             │
│                               │
│ Backup Extension              │
└───────────────┬─────────────┘
                │
                ▼
        Operational Tier
        Snapshot / Metadata
                │
                ▼
        Vault Tier
        Geo-redundant Backup Vault
                │
                ▼
Secondary Region / Paired Region
┌─────────────────────────────┐
│ Target AKS Cluster           │
│  ├─ Backup Extension          │
│  ├─ Trusted Access            │
│  ├─ Staging Storage           │
│  └─ Restored Workloads        │
└─────────────────────────────┘

4. クロスリージョン復元の制限を経営層へ説明する

クロスリージョン復元は強力ですが、万能ではありません。Microsoft公式のサポートマトリックスでは、Azure Filesベースのボリュームは別リージョン・別サブスクリプションへの復元をサポートしないこと、Vault TierとCross Region RestoreではAzure DiskベースPVに制限があることが明記されています。

表2：クロスリージョン復元の主な制限

制限項目	内容
対象リージョン	Azureペアリージョン間のみ
Vault Tier対象	Azure DiskベースPVのみ
Azure Files	リージョン間復元・サブスクリプション間復元は非対応
Azure Diskサイズ	Vault Tier移動対象はPVサイズ1TB以下
ディスク数	バックアップインスタンスあたりPVディスク100個以下
RPO	Primary最大24時間、Secondary最大36時間
Backup Extension	ターゲットAKSにも必要
Trusted Access	Backup VaultとAKS間で必要
ノード容量	Azure BackupはAKSノードを自動スケールアウトしない
Staging	Vault Tier復元ではステージング用ストレージ等が必要

Microsoft公式では、Azure BackupはAKSノードを自動的にスケールアウトせず、データと関連リソースのみを復元すると説明されています。復元前にターゲットAKSクラスターに十分なリソースがあるか確認しなければ、復元失敗や性能問題が起き得ます。

5. RTO/RPO/SLAを分けて説明する

コンテナBCPで最も混乱しやすいのが、RTO、RPO、SLAの混同です。

表3：RTO/RPO/SLAの違い

用語	意味	AKS Backupでの確認観点
RTO	何分・何時間以内に業務再開するか	復元開始、ターゲットAKS準備、Restore Job、Pod起動、DNS切替、業務確認の合計時間
RPO	どの時点までのデータ損失を許容するか	Backup頻度、復旧ポイント時刻、Vault Tierの24h/36h制約
SLA	サービス提供者の稼働率等の約束	Azure Backupサービスの可用性と、自社アプリSLAを分ける

Azure BackupのSLAは、バックアップおよび復元操作に対するサービス可用性を対象とし、SLA対象となるには失敗したバックアップまたは復元ジョブを少なくとも30分に1回再試行する必要があると説明されています。これは、自社アプリケーションが何分で復旧するかを保証するものではありません。

経営層向けに必ず説明すべきこと

説明項目	伝えるべき内容
RTO	Backupからの復元時間だけでなく、AKS起動、イメージ取得、Pod起動、DNS切替、業務確認まで含める
RPO	Vault Tierクロスリージョン復元では最大36時間になり得る
SLA	Azure BackupのSLAと、自社サービスのSLAは別物
訓練	実測しなければRTOは確認できない
例外	Azure Files、非CSIボリューム、Blob/Container Storage PVなどは別設計が必要

確認できないこと：Microsoft公式情報からは、AKS Backupのクロスリージョン復元について、企業ごとの業務RTOを一律に保証する数値は確認できません。業務RTOは、各社のAKS構成、ノード容量、イメージサイズ、依存PaaS、DNS切替、承認手順、復元訓練結果で測定する必要があります。

6. なぜコンテナ基盤のBCPはVMより説明が難しいのか

表4：VM BCPとAKS BCPの違い

観点	VM中心のBCP	AKS/コンテナBCP
復旧単位	VM、ディスク、NIC	Namespace、Deployment、Service、PVC、CRD、Secret
データ	OSディスク、データディスク	Persistent Volume、外部DB、Object Storage
アプリ	VM内に配置	コンテナーイメージ＋マニフェスト
構成	OS設定、ミドルウェア	Kubernetes YAML、Helm、Kustomize、GitOps
ネットワーク	IP、NSG、LB、DNS	Ingress、Service、CNI、NetworkPolicy、Private DNS
認証	VMローカル、AD、Entra ID	Managed Identity、Workload Identity、Key Vault
復旧確認	VM起動、サービス起動	Pod Ready、PVC mount、ImagePull、Probe、Ingress
監査証跡	バックアップジョブ、復旧ジョブ	Backup/Restore Job、Kubernetes状態、Git履歴、承認

VMでは「ディスクが戻れば復旧に近づく」ことがあります。しかしAKSでは、PVCが戻っても、Deployment、Secret、Ingress、DNS、イメージ、外部DB、権限が揃わなければ業務は戻りません。

7. AKS Backupで保護できるもの・別設計が必要なもの

表5：AKS Backup対象の整理

対象	AKS Backupでの扱い	BCP上の注意
Namespace	バックアップ/復元対象にできる	業務単位で対象を整理
Deployment/Service等	クラスターリソースとして復元対象	GitOpsとの差分に注意
PVC/PV	CSIベースのAzure Disk、Azure SMB Filesが対象	非対応PVは別設計
Azure Disk PV	Operational/Vault Tier対象	Cross Region Restoreの主対象
Azure Files SMB PV	Operational Tier対象	Cross Region Restore非対応
Azure Files NFS	非対応	別バックアップが必要
Azure Blob/Container Storage PV	AKS Backupでは非対応	専用のバックアップ設計が必要
Secret	バックアップ構成に含めるか判断	Key Vault運用との整合が必要
CRD	対象に含めるか確認	Operator復旧順序に注意
AKSノード	自動スケールアウトされない	復旧先AKS容量が必要
ACR	AKS Backup対象外	geo-replication、イメージ保全
Key Vault	AKS Backup対象外	Soft Delete、Purge Protection、リージョン設計
Azure SQL等PaaS	AKS Backup対象外	PaaSごとのDR機能が必要

Azure Backup for AKSはCSIドライバーベースの永続ボリュームのみをサポートし、in-tree volume pluginはサポートされません。Azure Blob StorageやAzure Container StorageベースのPersistent VolumeもAKS Backup対象外として説明されています。

8. RPO設計：Operational TierとVault Tierで別に定義する

表6：RPO設計表

復旧方式	想定RPO	向いている用途	注意点
Operational Tier 4時間間隔	約4時間目標	誤削除、設定ミス、同一リージョン復旧	同一リージョン依存
Operational Tier 8/12/24時間	8〜24時間目標	低重要度、低更新頻度	更新頻度が高い業務には不向き
Vault Tier Primary	最大24時間	長期保全、Vault側保護	1日1復旧ポイント
Vault Tier Secondary	最大36時間	リージョン障害対策	レプリケーションに最大12時間追加
Active-passive AKS	設計次第	重要システム	データ同期・外部DB設計が必要
Active-active AKS	設計次第	ミッションクリティカル	高コスト・高難度

Microsoft公式のAKSマルチリージョンモデルでは、アクティブ/アクティブ、アクティブ/パッシブ、パッシブ/コールドの3モデルが示され、アクティブ/アクティブは高い回復性がある一方で高コスト・複雑、パッシブ/コールドは最低コストだがデータ損失や長い復旧時間、手動介入のリスクがあると説明されています。

9. RTO設計：Restore Jobだけで測らない

AKS Backupの復元時間だけを見ても、業務RTOは説明できません。

図3：コンテナBCPにおけるRTOの内訳

障害検知
  │
  ▼
災害宣言・承認
  │
  ▼
復旧先AKS確認
  │
  ▼
Backup Vault / 復旧ポイント選択
  │
  ▼
Restore実行
  │
  ▼
Kubernetes Resources復元
  │
  ▼
PV/PVC復元
  │
  ▼
Image Pull
  │
  ▼
Pod Ready / Probe OK
  │
  ▼
Ingress / DNS / Front Door切替
  │
  ▼
業務確認
  │
  ▼
業務再開

表7：RTOに含めるべき時間

時間要素	内容
検知時間	Azure Monitor、Sentinel、Service Health、アプリ監視
判断時間	災害宣言、経営承認、システムオーナー承認
復旧先準備時間	AKS、Node pool、IP、Quota、Backup Extension
復元時間	Kubernetes resources、PV、Vault hydration、staging
コンテナー起動時間	ACR接続、Image Pull、Init Container、Probe
アプリ整合性確認	DB、Queue、Cache、外部API、認証
通信切替時間	Front Door、Traffic Manager、DNS、Private DNS
業務確認時間	ログイン、登録、検索、帳票、API確認
記録時間	チケット、承認、復旧完了報告

10. クロスリージョン復元を使う構成パターン

表8：コンテナBCP構成パターン

パターン	構成	コスト	RTO	RPO	向いている業務
A	Operational Tierのみ	低	中	4〜24時間設計	誤削除・同一リージョン復旧
B	Vault Tier＋Cross Region Restore	中	中〜長	最大36時間	リージョン障害時の最低限復旧
C	Passive-cold AKS＋CRR	中	長	最大36時間	低〜中重要度、費用重視
D	Active-passive AKS＋データ同期	高	短〜中	設計次第	重要業務
E	Active-active AKS＋グローバル分散	非常に高	短	設計次第	ミッションクリティカル

Microsoft公式のAKSマルチリージョンモデルでは、リージョン障害に備えるため、複数リージョンのAKSクラスター計画、Traffic Manager等による複数クラスター間トラフィックルーティング、コンテナーイメージレジストリのgeo-replication、複数クラスター間のアプリケーション状態計画、複数リージョン間のストレージレプリケーションがベストプラクティスとして示されています。

11. コンテナBCPの設計図

図4：AKS Backupを中心にしたBCP構成例

Primary Region
┌──────────────────────────────┐
│ AKS Cluster                   │
│  ├─ App Namespace             │
│  ├─ PVC / Azure Disk CSI       │
│  ├─ Secrets / ConfigMaps       │
│  └─ Ingress                    │
│                               │
│ Azure Container Registry       │
│ Key Vault                      │
│ Azure SQL / Storage / Redis    │
└───────────────┬──────────────┘
                │
                │ AKS Backup
                ▼
        Backup Vault
        Operational Tier
        Vault Tier / GRS / CRR
                │
                ▼
Secondary Region
┌──────────────────────────────┐
│ Target AKS Cluster            │
│  ├─ Backup Extension           │
│  ├─ Trusted Access             │
│  ├─ Restored Namespace         │
│  ├─ Restored PVC/PV            │
│  └─ Restored Workloads         │
│                               │
│ ACR geo-replica                │
│ Key Vault equivalent           │
│ PaaS DR configuration          │
└───────────────┬──────────────┘
                │
                ▼
        Front Door / DNS切替
                │
                ▼
             利用者

12. BCP文書とAzure構成の突合表

表9：AKS BCP/DR突合マトリクス

BCP文書の項目	Azure/AKSで確認する項目	証跡
対象業務	Namespace、アプリ、API、バッチ一覧	業務台帳
復旧優先度	Tier分類、Namespace順序	BIA資料
RTO	Restore Drill実測、DNS切替時間	訓練報告書
RPO	Backup Policy、復旧ポイント時刻	Backup Job
データ保護	PV種別、CSI、Vault Tier対象	PV台帳
リージョンDR	GRS Backup Vault、CRR有効化	Vault設定
復元先	Target AKS、Node pool、Quota	AKS構成図
イメージ	ACR geo-replication、Digest	ACR設定
Secret	Kubernetes Secret、Key Vault	Secret台帳
Ingress	Application Gateway、NGINX、Front Door	ネットワーク図
DNS	Public DNS、Private DNS、Traffic Manager	DNS変更履歴
外部PaaS	SQL、Storage、Redis、Service Bus	PaaS DR設計
承認	災害宣言、復元実行、公開切替	チケット
監査証跡	Backup/Restore Job、Activity Log	監査資料
例外	非対応PV、手動復旧、未保護リソース	例外台帳

13. 復元手順をRunbook化する

図5：クロスリージョン復元Runbook

1. 障害検知
   ↓
2. 災害宣言・承認
   ↓
3. 復旧対象Namespace確認
   ↓
4. Backup Vaultと復旧ポイント確認
   ↓
5. Secondary RegionのAKS確認
   ↓
6. Backup Extension / Trusted Access確認
   ↓
7. 復元先Node pool容量確認
   ↓
8. Restore実行
   ↓
9. PVC/PV復元確認
   ↓
10. Pod Ready確認
   ↓
11. Ingress / DNS / Front Door切替
   ↓
12. 業務確認
   ↓
13. 経営・関係者報告
   ↓
14. 証跡保存
   ↓
15. 改善事項登録

表10：復元手順書テンプレート

手順	作業	実施者	承認者	証跡
1	障害検知・一次判定	SOC/運用	情シス責任者	アラート
2	災害宣言	情シス責任者	経営層	チケット
3	復元対象確認	AKS担当	システムオーナー	BCP台帳
4	復旧ポイント選択	AKS担当	情シス責任者	Backup Vault画面
5	復元先AKS確認	AKS担当	クラウド責任者	AKS構成
6	Restore実行	AKS担当	変更管理責任者	Restore Job
7	PVC/PV確認	AKS担当	アプリ担当	kubectl結果
8	Pod Ready確認	アプリ担当	システムオーナー	Probe結果
9	Ingress確認	ネットワーク担当	情シス責任者	疎通試験
10	DNS/Front Door切替	ネットワーク担当	経営/情シス	DNS履歴
11	業務確認	業務部門	業務責任者	確認記録
12	完了報告	情シス責任者	経営層	報告書

14. アプリ整合性：Backup HookとRestore Hookを検討する

Kubernetes上でデータベースや状態を持つアプリを運用している場合、単なるスナップショットでは業務整合性を説明できないことがあります。

Microsoft公式では、AKS Backupでバックアップ操作中または復元後にコンテナー内でコマンドを実行するカスタムフックを構成できると説明されています。Backup HookやRestore Hookを使うことで、バックアップ前処理、バックアップ後処理、復元後処理をRunbook化できます。

表11：Hookで検討する処理例

Hook	処理例	目的
Pre-backup Hook	アプリの書込み一時停止、flush	整合性向上
Post-backup Hook	書込み再開、状態確認	業務影響を短縮
Restore Hook	キャッシュ再作成、設定補正	復元後起動を安定化
Restore Hook	DB migration確認	バージョン差異対策
Restore Hook	外部API接続確認	業務再開確認

15. 監査で問われる質問

表12：監査質問と準備資料

監査質問	準備資料
AKSのどの業務がBCP対象ですか	業務・Namespace対応表
RTOは何分ですか	復元訓練の実測結果
RPOは何時間ですか	Backup Policy、復旧ポイント履歴
Cross Region Restoreは有効ですか	Backup Vault設定、GRS/CRR設定
Azure Filesはリージョン復元できますか	サポートマトリックス、例外台帳
非対応PVはありますか	PV台帳、CSI確認結果
復元先AKSは用意されていますか	DRクラスター設計書
イメージは取得できますか	ACR geo-replication設定
Secretsは復旧できますか	Key Vault/Secret運用台帳
DNS切替手順はありますか	Runbook、DNS変更手順
誰が復元を承認しますか	BCP/DR RACI表
復元訓練をしていますか	訓練報告書
例外は管理されていますか	例外台帳

NIST SP 800-34 Rev.1は、情報システムと業務を評価し、コンティンジェンシープランニングの要件と優先順位を決めるためのガイダンスです。また、NIST SP 800-84は、IT計画と能力に対するテスト・訓練・演習を設計、実施、評価するための支援を目的としています。

16. RACI：誰が責任を持つのか

表13：AKS Backup / コンテナBCP RACI

作業	経営層	情シス責任者	AKS基盤	アプリ担当	ネットワーク	セキュリティ	監査/規程
業務重要度決定	A	C	I	C	I	C	C
RTO/RPO決定	A	R	C	C	C	C	C
Backup Policy設計	I	A	R	C	I	C	C
Vault Tier/CRR設計	I	A	R	C	C	C	C
Backup Extension運用	I	A	R	C	I	C	I
PV/CSI確認	I	C	R	R	I	I	I
Secret/Key Vault設計	I	A	C	C	I	R	C
ACR geo-replication	I	C	R	C	I	C	I
復元訓練	I	A	R	R	C	C	C
DNS/Traffic切替	I	A	C	C	R	C	I
災害宣言	A	R	C	C	C	C	I
業務再開判定	A	C	C	R	C	C	I
証跡保存	I	A	R	C	C	C	R

R：実行責任、A：説明責任、C：相談先、I：共有先

17. BCP/DR台帳テンプレート

表14：AKS BCP/DR台帳

項目	記入例
管理番号	AKS-BCP-2026-001
対象業務	顧客向けAPI基盤
対象AKS	aks-prod-east
復旧先AKS	aks-dr-west
対象Namespace	api-prod、worker-prod
重要度	Tier 1
業務RTO	4時間
業務RPO	24時間
Backup Tier	Operational + Vault
Backup頻度	4時間
Vault Tier	有効
Cross Region Restore	有効
対象PV	Azure Disk CSI
除外PV	Azure Files NFS、Blob CSI
ACR	geo-replication有効
Secret	Key Vault参照。Kubernetes Secretはバックアップ対象確認
Ingress	Application Gateway Ingress Controller
DNS切替	Azure Front Door
復元手順	Runbook AKS-DR-RB-001
最終復元訓練	2026-06-30
実測RTO	2時間45分
実測RPO	23時間
未解決課題	Restore Hook標準化
次回見直し	2026-09-30
承認者	情シス責任者、業務責任者

18. コンテナBCP規程に入れるべき条項

規程文サンプル

第○条（AKS BackupおよびコンテナBCP管理）

1. 当社は、AKS上で稼働する重要業務について、業務影響分析に基づき、
   RTOおよびRPOを定義し、AKS BCP/DR台帳に記録する。

2. AKS Backupを利用する場合は、対象Namespace、クラスターリソース、
   Persistent Volume、Secret、Backup Tier、復元先AKS、復旧ポイント方針を
   事前に定義しなければならない。

3. クロスリージョン復元を利用する場合は、Backup VaultのGeo冗長設定、
   Cross Region Restoreの有効化、Vault Tier対象データ、Azureペアリージョン、
   復元先AKS、ステージング場所、DNS切替手順を文書化する。

4. AKS Backupは、Azure Files、Azure Blob Storage、Azure Container Storage、
   非CSI Persistent Volumeなど、すべてのデータを保護するものではない。
   非対応のデータについては、別途バックアップ方式、例外理由、代替策を記録する。

5. 業務RTOは、Restore Jobの実行時間だけでなく、障害検知、災害宣言、
   復元先AKS準備、Pod起動、Ingress/DNS切替、業務確認、再開承認までを含めて管理する。

6. 重要業務については、少なくとも年1回以上、必要に応じて四半期ごとに
   復元訓練を実施し、実測RTO、実測RPO、課題、改善期限、承認者を記録する。

7. 復元、DNS切替、業務再開、例外承認、手順変更は、
   変更管理手続に基づき、証跡を保存する。

19. 経営層向け説明資料の1枚テンプレート

表15：経営向けAKS BCP説明表

項目	現状	目標	差分	対応方針
対象業務	顧客API	Tier 1	重要	AKS Backup＋CRR対象
RTO	未測定	4時間	不明	復元訓練で測定
RPO	最大36時間	24時間以内	未達可能性	Active-passive検討
復元方式	Operational Tier	Vault Tier＋CRR	DR不足	GRS/CRR有効化
PV	Azure Disk/Files混在	DiskはCRR、Filesは別設計	Files非対応	例外管理
イメージ	単一リージョンACR	geo-replication	リージョン障害時リスク	ACR複製
Secret	手動管理	Key Vault標準化	属人化	規程整備
DNS切替	手順なし	Runbook化	RTO不明	Front Door/DNS手順化
訓練	未実施	四半期	証跡不足	Restore Drill実施

20. 費用対効果も説明する

AKS Backupとクロスリージョン復元は、可用性を高める一方でコストも発生します。Azure Backupの価格ページでは、保護されたインスタンスとストレージが主な課金要素であり、Backup StorageはAzure Backupが管理するストレージに保存され、ストレージ料金は保護インスタンスのコストとは別に発生すると説明されています。

表16：コンテナBCPで増える費用

費用項目	内容
Azure Backup	保護インスタンス、Backup Vault
Backup Storage	Operational/Vault、LRS/ZRS/GRS
スナップショット	Azure Disk、Azure Files
クロスリージョン	Geo冗長、復元時の転送・ステージング
DR AKS	予備クラスター、Node pool、Public IP、Ingress
ACR	geo-replication
Key Vault	リージョン別保管、証明書・Secret
監視	Log Analytics、アラート、ダッシュボード
運用	復元訓練、Runbook、承認、監査資料

21. 山崎行政書士事務所としての支援領域

AKS Backupとクロスリージョン復元は、Azure設定だけでは完成しません。企業として必要なのは、RTO/RPO、復旧手順、承認、例外管理、監査証跡、経営説明を一体化することです。

山崎行政書士事務所では、Azure技術支援とクラウド法務・ガバナンス支援を一体で行います。

領域	支援内容
Azure技術支援	AKS Backup、Backup Vault、Vault Tier、Cross Region Restore設計
AKS設計レビュー	Namespace、PV/PVC、CSI、Ingress、ACR、Key Vault、DNS
BCP/DR突合	BCP文書とAKS構成の差分整理
RTO/RPO整理	業務RTO、技術RTO、Backup RPO、Vault Tier RPOの整理
復元訓練支援	Restore Drill、手順書、証跡、改善管理
規程整備	コンテナBCP規程、バックアップ規程、DR運用規程
監査対応	台帳、承認記録、復元証跡、例外管理資料
経営説明	費用対効果、リスク、未対応範囲、投資判断資料
契約・委託管理	運用委託、責任分界、報告様式、SLA整理

行政書士業務の範囲を踏まえ、個別紛争対応や訴訟代理など弁護士領域に属する事項は切り分けたうえで、企業がクラウドを安全に利用するための規程整備、契約関連資料、監査説明資料、運用ルール整備を支援します。

まとめ

AKS Backupとクロスリージョン復元は、コンテナBCPを整備するうえで重要な技術です。ただし、コンテナ基盤のBCPはVMより説明が難しく、バックアップ設定だけでは不十分です。

重要なのは、次の5点です。

重要ポイント	内容
RTO/RPOを分ける	Vault Tier CRRのRPOは最大36時間になり得る
対象を明確にする	Namespace、PV、Secret、CRD、外部PaaSを整理
制限を説明する	Azure Files、非CSI、Blob/Container Storage PVは別設計
復元手順を作る	Target AKS、容量、Restore、DNS、業務確認をRunbook化
証跡を残す	Backup/Restore Job、承認、訓練、改善履歴を保管

コンテナBCPでは、「バックアップがあります」ではなく、「この業務は、このRPOで、この手順により、この時間内を目標に復旧します」と説明できる状態が必要です。

AKS Backup、クロスリージョン復元、コンテナBCP、RTO/RPO整理、運用手順・規程整備、監査対応資料の作成は、山崎行政書士事務所へご相談ください。

出典・確認日

確認日：2026年7月9日

出典	確認した主な内容	Microsoft Learn等の表示日
Microsoft Learn：Azure Kubernetes Service バックアップとは	AKS Backupの概要、Backup Extension、Operational Tier/Vault Tier、復元対象、Hook	2026年3月17日
Microsoft Learn：AKSバックアップ サポートマトリックス	CSI、Azure Disk/Azure Files対応、非対応シナリオ、Vault Tier、CRR制限、RPO	2026年3月17日
Microsoft Learn：AKSのVault Tierバックアップとリージョン間復元チュートリアル	Vault Tier、Cross Region Restore、Primary 24h/Secondary 36h RPO	2026年1月29日
Microsoft Learn：Azure Backupを使用してAKSを復元する	元クラスター・代替クラスターへの復元、Backup Extension、Trusted Access、Target AKS、Staging	2026年3月17日
Microsoft Learn：AKSをバックアップする	バックアップ前提条件、Azure Files制限、Backup Vault、頻度、保持	2026年3月17日
Microsoft Learn：AKSマルチリージョンデプロイモデル	Active-active、Active-passive、Passive-coldの比較、複数リージョンDRの考慮事項	2025年8月1日
Microsoft Learn：Azure Backupの信頼性	Azure Backup SLAの範囲、失敗ジョブ再試行条件	2026年4月14日
Microsoft Azure：Azure Backup価格	保護インスタンス、Backup Storage、LRS/ZRS/GRS、ストレージ課金	確認日：2026年7月9日
Microsoft Azure：Azure BackupとAzure Site Recoveryの違い	Backupはデータのバックアップ/復元、Site RecoveryはアプリDR向け	確認日：2026年7月9日
NIST SP 800-34 Rev.1	コンティンジェンシープランニング要件・優先順位の考え方	2010年11月11日
NIST SP 800-84	IT計画・能力に関するテスト、訓練、演習の設計・実施・評価	2006年9月21日