Azure Backup for AKS の構成は、Azure CLI の単一コマンドで開始できるようになりました。これにより、AKS のバックアップ設定は「担当者が手順書を見ながら個別に作業するもの」から、「CI/CD、プラットフォームテンプレート、Day 2 operations に組み込む標準プロセス」へ近づきます。結論から言うと、重要なのはコマンド数の削減そのものではありません。バックアップ拡張機能、Backup Vault、ポリシー、Trusted Access、バックアップインスタンス作成までを一つの流れにまとめられることで、AKS 運用のばらつきと設定漏れを減らしやすくなる点が本質です。(マイクロソフト アジュール)
ただし、1コマンド化は「バックアップ設計が不要になる」という意味ではありません。対象の名前空間、永続ボリューム、Vault 層の利用有無、復元テスト、権限、リージョン、タグ設計は引き続き運用チームが決める必要があります。この記事では、Azure Backup for AKS / Azure CLI の最新動向を踏まえ、Platform engineers と Kubernetes administrators が実務でどう取り入れるべきかを整理します。
Azure Backup for AKS のCLI構成は何が変わったのか
2026年4月18日時点の更新として注目すべき点は、Azure Backup for AKS のバックアップ構成を az dataprotection enable-backup trigger で開始できるようになったことです。Microsoft の説明では、従来は az aks、az k8s-extension、az dataprotection など複数の CLI 領域をまたぎ、バックアップ拡張機能、ストレージ、Backup Vault、ポリシー、Trusted Access、バックアップインスタンスを手動でつなぐ必要がありました。新しいフローでは、その一連のセットアップを単一の CLI コマンドに集約します。(TECHCOMMUNITY.MICROSOFT.COM)
基本形は次のようになります。
az dataprotection enable-backup trigger \
--datasource-type AzureKubernetesService \
--datasource-id /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ContainerService/managedClusters/<aks-cluster-name>このコマンドは、AKS クラスターの状態確認、バックアップ用リソースグループの作成または再利用、Backup Extension のインストール、必要なストレージリソースの作成または再利用、Backup Vault とバックアップポリシーの作成または再利用、Trusted Access の有効化、バックアップインスタンスの作成までを自動化します。(Microsoft Learn)
| 観点 | 従来のCLI構成 | 単一コマンド化後 | 実務上の意味 |
|---|---|---|---|
| 作業単位 | 拡張機能、Vault、ポリシー、権限、インスタンスを個別に設定 | az dataprotection enable-backup trigger に集約 | 手順漏れを減らしやすい |
| 自動化 | 複数コマンドをスクリプトでつなぐ必要がある | CI/CD の1ステップに組み込みやすい | AKS 作成直後に保護を開始しやすい |
| 標準化 | チームごとに実装差が出やすい | 戦略と設定ファイルをテンプレート化しやすい | Platform engineering の「標準パス」にしやすい |
| 既存資産の利用 | 手動で Vault やポリシーを指定 | 設定JSONで既存 Vault、ポリシー、ストレージを指定可能 | ガバナンスと共存しやすい |
| 従来手順 | 引き続き利用可能 | 代替アプローチとして追加 | 既存運用を急に置き換える必要はない |
重要なのは、新しいコマンドが従来方式を完全に廃止するものではない点です。Microsoft Learn では、az dataprotection backup-instance initialize-backupconfig を使う従来のバックアップインスタンス作成方法も引き続き動作すると説明されています。(Microsoft Learn)
まず押さえるべきAzure CLIの基本フロー
実務では、最初に dataprotection 拡張機能を更新し、バージョンを確認してから実行するのが安全です。Microsoft Learn では、この単一コマンドを使うために dataprotection 拡張機能 1.9.0 以上が必要とされています。(Microsoft Learn)
az extension add -n dataprotection --upgrade
az extension show -n dataprotection --query version -o tsvAKS クラスターの ARM ID を取得してから実行すると、スクリプトやパイプラインに組み込みやすくなります。
AKS_ID=$(az aks show \
--resource-group <aks-resource-group> \
--name <aks-cluster-name> \
--query id \
--output tsv)
az dataprotection enable-backup trigger \
--datasource-type AzureKubernetesService \
--datasource-id "$AKS_ID" \
--backup-strategy Month \
--yes--backup-strategy には、用途に応じたプリセットを指定できます。CLI リファレンスでは、Week、Month、DisasterRecovery、Custom が選択肢として示されています。(Microsoft Learn)
| バックアップ戦略 | 保持の考え方 | 向いている用途 | 注意点 |
|---|---|---|---|
Week | Operational Store に7日保持 | 開発、検証、短期保護 | 既定値のため、本番でそのまま使う前に要件確認が必要 |
Month | Operational Store に30日保持 | 一般的な本番環境の初期候補 | リージョン障害対策として十分かは別途判断 |
DisasterRecovery | Operational Store 7日 + Vault Store 90日 | DR を意識した環境 | Cross Region Restore には Vault 側の冗長性設定も確認が必要 |
Custom | 既存 Vault とポリシーを利用 | 統制済みのエンタープライズ環境 | backupVaultId と backupPolicyId を設定JSONで指定する |
本番環境では、Week を既定値のまま使うより、RPO、RTO、保持期間、監査要件に合わせて Month、DisasterRecovery、または Custom を選ぶのが現実的です。
設定JSONで既存のVaultやタグ設計に合わせる
単一コマンド化の価値は、何でも自動作成できることだけではありません。むしろ大規模環境では、既存の Backup Vault、バックアップポリシー、ストレージアカウント、タグルールに合わせて実行できる点が重要です。--backup-configuration-file には、既存 Vault、既存ポリシー、既存ストレージ、Blob コンテナー名、バックアップリソースグループ、タグなどを指定できます。(Microsoft Learn)
例として、プラットフォームチームが管理する Backup Vault とポリシーを使う場合は、次のような config.json を用意します。
{
"backupVaultId": "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.DataProtection/backupVaults/<vault>",
"backupPolicyId": "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.DataProtection/backupVaults/<vault>/backupPolicies/<policy>",
"storageAccountResourceId": "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
"blobContainerName": "aks-backup",
"backupResourceGroupId": "/subscriptions/<sub>/resourceGroups/<rg>",
"tags": {
"Owner": "platform-team",
"Environment": "prod",
"CostCenter": "cc-1234",
"ManagedBy": "platform-template"
}
}実行コマンドは次の形です。
az dataprotection enable-backup trigger \
--datasource-type AzureKubernetesService \
--datasource-id "$AKS_ID" \
--backup-strategy Custom \
--backup-configuration-file @config.json \
--yesCustom 戦略は、バックアップを各アプリチーム任せにせず、プラットフォーム側で定義した Vault、ポリシー、命名規則、タグを使わせたい場合に特に有効です。自由に自動作成させると、サブスクリプション内に用途不明の Vault やストレージが増え、後からコスト管理や監査が難しくなります。
AKS自動化で重要になる理由
AKS operators が CLI simplification や backup automation guidance を探す理由は明確です。AKS クラスターは、作って終わりではありません。新規環境、ステージング、本番、DR 用クラスター、短命な検証クラスターなどが増えるほど、「すべてのクラスターが同じ保護レベルでバックアップされているか」を人手で確認するのは難しくなります。
単一コマンド化によって、バックアップ構成を AKS プロビジョニング後の標準ステップにできます。
set -euo pipefail
az account set --subscription "<subscription-id>"
AKS_ID=$(az aks show \
--resource-group "$AKS_RESOURCE_GROUP" \
--name "$AKS_CLUSTER_NAME" \
--query id \
--output tsv)
az dataprotection enable-backup trigger \
--datasource-type AzureKubernetesService \
--datasource-id "$AKS_ID" \
--backup-strategy "$BACKUP_STRATEGY" \
--backup-configuration-file @aks-backup-config.json \
--yesこの形にしておくと、Azure DevOps、GitHub Actions、社内のデプロイ基盤、セルフサービスポータルから同じ流れを呼び出せます。AKS 作成時にバックアップ設定を後回しにしないため、クラスター作成から初回バックアップまでの「無保護な時間」を短くできます。
さらに、失敗時の切り分けもしやすくなります。従来のように複数のスクリプトでリソース作成、拡張機能、RBAC、Trusted Access、バックアップインスタンスを順番に処理していると、どの段階で失敗したのかをジョブログと Azure 側の状態から追う必要があります。単一コマンドに寄せることで、少なくともオンボーディング処理の入口を統一できます。
プラットフォームテンプレートに組み込むときの設計ポイント
Platform engineering の文脈では、単一コマンドをそのまま「各チームが好きに実行する便利コマンド」として配るより、AKS platform template の一部として抽象化するほうが効果的です。
たとえば、プラットフォームテンプレート側では次のような入力だけをアプリチームに見せます。
| テンプレート入力 | 選択例 | プラットフォーム側で吸収する内容 |
|---|---|---|
backup_enabled | true / false | バックアップ構成を実行するか |
backup_tier | dev / prod / dr | Week、Month、DisasterRecovery、Custom へのマッピング |
data_classification | internal / confidential | Vault、保持期間、タグ、アラートルールの選択 |
owner_team | payments、platform など | タグ、通知先、コスト配賦 |
restore_test_required | true / false | 初回復元テストのチケット作成やワークフロー起動 |
この設計にすると、アプリチームは Backup Vault や Trusted Access の細部を知らなくても、組織標準に沿った保護を受けられます。一方、プラットフォームチームは config.json とバックアップポリシーを管理することで、統制を維持できます。
ここでの判断基準は、次の通りです。
| 環境 | 推奨アプローチ | 理由 |
|---|---|---|
| 個人検証、短期PoC | Week から開始 | 構成を軽くし、後片付けしやすい |
| 共有開発環境 | Week または Month | 誤削除からの短期復旧を重視 |
| 一般的な本番環境 | Month または Custom | 保持期間、タグ、監査要件を明示しやすい |
| 規制・監査対象の本番環境 | Custom | 既存 Vault、既存ポリシー、承認済み設定を使う |
| リージョン障害も想定する環境 | DisasterRecovery または Custom | Vault Store と Cross Region Restore の設計が必要 |
IaC との関係にも注意が必要です。Bicep や Terraform で AKS、ネットワーク、ID、ポリシーを宣言的に管理している場合、単一 CLI コマンドは「宣言的リソース定義の代替」というより、「クラスター作成後の保護オンボーディング処理」として扱うほうが自然です。厳格な構成管理を行う組織では、Vault やポリシーは IaC で先に作り、CLI では Custom と設定JSONを使ってバックアップ保護を有効化する構成が扱いやすくなります。
Day 2 operationsで本当に見るべきこと
Day 2 operations とは、初期構築後の日常運用を指します。AKS バックアップでは、初回構成よりも、バックアップが継続して成功しているか、復元できるか、ポリシーが要件に合っているかを確認し続けることが重要です。
Azure Backup for AKS は、Operational Tier と Vault Tier の両方を扱えます。Operational Tier はスナップショットなどを利用したテナント内のバックアップで、Vault Tier はテナント外の Vault 側に保存されるバックアップです。リージョンをまたぐ復元を考える場合は、Vault Tier と Cross Region Restore の設計が重要になります。(Microsoft Learn)
Day 2 operations では、少なくとも次の項目を運用チェックリストに入れてください。
| 運用項目 | 確認内容 | 実務でのポイント |
|---|---|---|
| 初回バックアップ確認 | バックアップインスタンスが作成され、初回ジョブが成功しているか | 構成直後に必ず確認する |
| スケジュールジョブ監視 | ScheduledBackup が継続成功しているか | Azure Monitor や運用ダッシュボードに載せる |
| オンデマンドバックアップ | 変更前や移行前に手動バックアップできるか | 重要作業の前に実行する |
| 復元テスト | 別クラスターまたは検証名前空間へ戻せるか | バックアップ成功だけで安心しない |
| ポリシー見直し | 保持期間、Vault Store、DR要件が合っているか | 本番化時や監査前に確認する |
| 権限レビュー | Backup Vault、AKS、スナップショットリソースグループの権限が維持されているか | RBAC変更後の失敗を防ぐ |
| タグと所有者 | Owner、Environment、CostCenter などが付いているか | コスト管理と問い合わせ対応に効く |
バックアップジョブの追跡には az dataprotection job や Resource Graph を使う方法が示されています。オンデマンドバックアップやスケジュールバックアップのジョブを一覧化し、運用監視に組み込むのが現実的です。(Microsoft Learn)
az dataprotection job list-from-resourcegraph \
--datasource-type AzureKubernetesService \
--datasource-id "$AKS_ID" \
--operation ScheduledBackup実装前に確認すべき制約
単一コマンド化されても、Azure Backup for AKS のサポート条件は無視できません。特に永続ボリューム、ノードプール、リージョン、ID、ネットワーク分離に関する制約は、導入前に確認が必要です。
| 確認項目 | 注意点 | 見落とした場合の影響 |
|---|---|---|
| 永続ボリューム | CSI ドライバーを使う Azure Disk と Azure Files SMB が主な対象。Azure Files NFS や Azure Blob Storage ベースの PV は対象外または個別対応が必要 | データがバックアップされていると思い込むリスク |
| 静的プロビジョニング | 静的ボリュームでは StorageClass の明示が必要になる場合がある | バックアップ時にボリュームがスキップされる可能性 |
| リージョン | Backup Vault と AKS クラスターは同一リージョンが基本 | 構成時に失敗する、または設計変更が必要 |
| ノードプール | Backup Extension は Windows ベースや ARM64 ベースのノードプールにはインストールできない | 対応する Linux x86 ノードプールの準備が必要 |
| マネージドID | AKS 側の ID と Backup Vault 側の権限が必要 | RBAC不足で検証やバックアップが失敗する |
| プライベート環境 | プライベート仮想ネットワーク内の AKS ではバックアップ操作用のプライベートエンドポイント構成が必要になる | 通信できずバックアップ操作が失敗する |
| Network Isolated AKS | 現時点で AKS Backup のサポート対象外とされている | 対象クラスターでは別設計が必要 |
| 整合性 | Operational Tier の PV スナップショットは基本的にクラッシュ整合性。アプリケーション整合性が必要な場合はフック設計を検討 | DB系ワークロードで復元後の整合性問題が起きる |
これらの条件は、AKS バックアップのサポートマトリックスで明示されています。特に、サポート外の永続ボリュームはバックアッププロセス中にスキップされる可能性があるため、Kubernetes 管理者は PersistentVolume と StorageClass の棚卸しを先に行うべきです。(Microsoft Learn)
失敗しやすいポイントと回避策
単一CLI化は便利ですが、運用設計を省略すると失敗します。よくある落とし穴は次の通りです。
| 失敗しやすいポイント | ありがちな状態 | 回避策 |
|---|---|---|
既定の Week のまま本番適用する | 7日保持で要件を満たせない | 本番化前に RPO、RTO、保持期間を確認する |
DR要件を DisasterRecovery 指定だけで満たしたと思う | Vault の冗長性や Cross Region Restore の設計が不足 | Backup Vault の GRS、Cross Region Restore、復元先リージョンを確認する |
| バックアップ成功だけを見ている | 復元できるか未検証 | 四半期ごと、またはリリース節目で復元演習を行う |
| すべてのPVが対象だと思い込む | Azure Files NFS や Blob ベースPVが含まれる | PV種別を棚卸しし、対象外データは別バックアップを設計する |
| チームごとに自由に実行させる | Vault、ポリシー、タグが乱立する | Custom と設定JSONをプラットフォーム側で管理する |
| 権限反映直後に失敗する | RBAC の伝播待ちを考慮していない | 検証とリトライをパイプラインに入れる |
| サブスクリプションを間違える | 別環境のクラスターに対して実行する | az account set と AKS_ID の出力確認を必須にする |
特に注意すべきなのは、バックアップは「取ること」より「戻せること」が重要だという点です。Azure Backup for AKS は元のクラスターまたは別の AKS クラスターへの復元をサポートしますが、復元先クラスターにも Backup Extension と Trusted Access が必要です。(Microsoft Learn)
既存環境ではどう移行すべきか
すでに Azure Backup for AKS を構成済みの環境で、急いで新コマンドへ全面移行する必要はありません。Microsoft Learn でも、従来の initialize-backupconfig を使う方法は引き続き利用できると説明されています。(Microsoft Learn)
判断基準は次の通りです。
| 状況 | 推奨判断 |
|---|---|
| 既存スクリプトが安定しており、監査済み | すぐに置き換えず、新規クラスターから新フローを試す |
| 手順が属人化している | 単一コマンドを使った標準スクリプトへ寄せる |
| 複数チームが個別にバックアップ設定している | Platform template に統合する |
| Vault、ポリシー、タグを中央管理している | Custom と config.json を使う |
| DR要件を見直している | DisasterRecovery だけでなく Vault 冗長性と復元手順を含めて再設計する |
| Terraform/Bicep中心で運用している | Vault やポリシーは IaC、バックアップ有効化はパイプラインの後処理として分離する |
移行時は、いきなり全本番クラスターに適用するのではなく、代表的なステージングクラスターで次の流れを検証します。
| 検証ステップ | 確認内容 |
|---|---|
| 事前棚卸し | AKS のリージョン、ID、ノードプール、PV種別、StorageClass を確認 |
| コマンド実行 | enable-backup trigger が成功するか |
| リソース確認 | Vault、ポリシー、ストレージ、バックアップインスタンス、タグを確認 |
| 初回バックアップ | スケジュールまたはオンデマンドで復旧ポイントが作られるか |
| 復元テスト | 別クラスターまたは検証環境へ戻せるか |
| 運用監視 | ジョブ失敗を検知できるか |
次に取るべき行動
Azure Backup for AKS の単一CLI化は、AKS バックアップを「後から手動で設定する作業」から「クラスター作成時に必ず通す標準フロー」へ変えるきっかけになります。Platform engineers は、まず新しい az dataprotection enable-backup trigger を検証環境で試し、Week、Month、DisasterRecovery、Custom のどれを環境別の標準にするか決めるべきです。
Kubernetes administrators は、コマンドを実行する前に PV 種別、CSI ドライバー、ノードプール、リージョン、マネージドID、ネットワーク条件を棚卸ししてください。そのうえで、初回バックアップの成功確認、オンデマンドバックアップ、復元テスト、ジョブ監視までを Day 2 operations の手順に入れることが重要です。
最初の一歩としては、次の順序が現実的です。
| 順序 | やること |
|---|---|
| 1 | 代表的な AKS クラスターを1つ選ぶ |
| 2 | dataprotection 拡張機能を更新する |
| 3 | PV、リージョン、ノードプール、ID、ネットワーク条件を確認する |
| 4 | Month または Custom でバックアップを有効化する |
| 5 | 初回バックアップとジョブ一覧を確認する |
| 6 | 検証用クラスターに復元テストを行う |
| 7 | 成功した設定を platform template と CI/CD に組み込む |
1コマンド化の最大のメリットは、作業が短くなることではなく、標準化しやすくなることです。AKS の数が増えるほど、バックアップの品質は個人の手順理解ではなく、テンプレート、ポリシー、監視、復元演習で担保する必要があります。Azure Backup for AKS / Azure CLI の新しい流れは、その運用モデルへ移行するための実用的な入口になります。
コメント