Microsoft Azure resiliency servicesの今回の更新は、既存のAzureリソースを自動変更したり、直ちに新しい契約を求めたりするものではありません。結論から言えば、対応優先度が高いのは、重要システムを単一ゾーン・単一リージョンで運用している組織、リージョンペアだけを災害対策の前提にしている組織、データ所在地やRPO・RTOを明文化できていない組織です。
2026年7月9日時点で確認したMicrosoft公式ブログ「Built to bounce back: How Azure resiliency evolved」は、公式ページ上では公開日が7月8日と表示されています。「Microsoft publishes an updated account of Azure’s application and infrastructure resiliency model」と要約される今回の情報は、Azureのレジリエンスを、ゾーン優先、ワークロード主導、継続的な検証、AIによる実装支援という考え方で整理し直したものです。(Microsoft Azure)
重要なのは、AIが勝手にフェイルオーバーや構成変更を実行するようになったわけではない点です。Resiliency Agentは診断、推奨、Infrastructure as Codeの生成を支援しますが、リソースへの変更は自動適用されず、利用者による確認と実行が必要です。(Microsoft Learn)
Microsoft Azure resiliency servicesの更新は運用モデルの再整理
本稿でいうMicrosoft Azure resiliency servicesとは、単一のサービス名ではなく、Resiliency in Azure、Azure Backup、Azure Site Recovery、Azure Chaos Studio、Azure Monitor、Azure Infrastructure Resiliency Manager、Azure Copilotなど、Azureの可用性・復旧・事業継続に関係する機能群の総称です。
Resiliency in Azureは、従来のAzure Business Continuity Centerから対象範囲を広げた統合管理基盤です。バックアップと災害復旧だけでなく、ゾーンレジリエンス、高可用性、ランサムウェア対策を一つの管理体験にまとめる方向へ拡張されています。(Microsoft Learn)
今回の公式整理によって強調された違いは、次のとおりです。
| 観点 | 現場でありがちな捉え方 | 今回強調された考え方 |
|---|---|---|
| 可用性 | SLAや稼働率が高ければ十分 | 障害時に事業を継続し、安全な状態へ復旧できることまで含める |
| 責任範囲 | Azureを利用すればMicrosoftが復旧してくれる | Microsoftと利用者の共有責任で設計・設定・訓練する |
| リージョン設計 | リージョンペアを使えばよい | サービス提供状況、容量、遅延、データ所在地を基に復旧先を選ぶ |
| 運用方法 | 導入時に冗長化して完了 | 設計、改善、検証を継続する |
| AIの役割 | AIが障害対応を自動実行する | リスク検出、推奨、IaC生成を支援し、人が変更を管理する |
Microsoftはレジリエンスを「Microsoftから利用者へ引き渡される完成品」ではなく、プラットフォームと利用者の設計を組み合わせて実現するものと説明しています。Microsoftはリージョン、データセンター、ネットワーク、障害分離などの基盤を担当しますが、アプリケーション構成、依存関係、復旧目標、バックアップ、災害復旧の設定とテストは利用者側の責任です。(Microsoft Azure)
自社で対応が必要かを先に判断する
今回の情報だけを理由に、すべてのAzure利用者が直ちに構成変更する必要はありません。次の基準で優先度を判断すると、過剰な投資を避けながら必要な対策を進められます。
| 現在の状況 | 対応優先度 | 最初に行うこと |
|---|---|---|
| 売上や基幹業務に関わるシステムが単一ゾーンで稼働している | 高 | ゾーン障害時に停止するリソースと依存関係を洗い出す |
| 重要システムが単一リージョンにあり、復旧先を決めていない | 高 | 復旧先リージョン、RPO、RTO、必要容量を決める |
| データを国外・域外へ複製できるか説明できない | 高 | データ分類と保存・複製・バックアップ先を確認する |
| Azure BackupやAzure Site Recoveryを設定したが、復旧テストをしていない | 高 | フェイルオーバーとバックアップ復元を別々に検証する |
| ゾーン冗長化済みだが、全体の状況を一覧化できていない | 中 | Infrastructure Resiliency Managerを検証環境で評価する |
| RPO・RTO、復旧手順、定期訓練が整備されている | 中～低 | 新しい管理機能で効率化できるかを確認する |
| Azure Governmentなどのナショナルクラウドを利用している | 個別確認 | Azure Copilotやプレビュー機能の提供状況を確認する |
| 開発用の一時環境で、停止の業務影響が小さい | 低 | コストに見合う範囲で最低限のバックアップを検討する |
特に、SLAが高いことと、アプリケーション全体が復旧可能であることは同じではありません。データベースが稼働していても、認証、DNS、ネットワーク、シークレット、外部APIなどの依存先が停止すれば、業務は継続できないためです。
Azureのレジリエンスを構成する3つの柱
Microsoftは、Azureのレジリエンスを次の3つの柱で整理しています。
| 柱 | 目的 | 関連する主な機能 |
|---|---|---|
| インフラストラクチャレジリエンス | ゾーン障害やリージョン障害が発生してもアプリケーションを継続する | Availability Zones、負荷分散、オートスケール、Azure Site Recovery、Infrastructure Resiliency Manager |
| データレジリエンス | データを保護し、必要な時点へ復元できるようにする | Azure Backup、LRS・ZRS・GRSなどのストレージ冗長化、復旧ポイント |
| サイバー回復 | 改ざんやランサムウェア被害後に、信頼できる状態へ復旧する | 不変バックアップ、論理削除、複数ユーザー承認、顧客管理キー、脅威検出 |
この3つは代替関係ではありません。たとえば、Azure Site Recoveryによるフェイルオーバーは地域障害への継続性確保に役立ちますが、破損したデータや暗号化されたデータまで複製される可能性があります。そのため、削除、破損、長期保存、サイバー攻撃への備えには、信頼できる時点へ戻すAzure Backupが必要です。(Microsoft Azure)
「ゾーン優先」と「ワークロード主導」が重要になる理由
今回の公式情報では、まず可用性ゾーンの喪失に耐えられるよう設計する「ゾーン優先」の考え方が示されています。同時に、リージョン障害への対応を、従来のリージョンペアだけに固定しない方針も強調されています。(Microsoft Azure)
ペアリージョンを利用する構成
リージョンペアを利用できる場合は、Azure Site Recoveryによるレプリケーションやフェイルオーバー、GRSなどのストレージ冗長化を組み合わせやすくなります。
ただし、リージョンペアは復旧先を決めるための有力な選択肢であり、すべてのワークロードに対する唯一の正解ではありません。対象サービスの提供状況、復旧時の容量、利用者との距離、データ所在地を確認する必要があります。
ペアを持たないリージョンや主権要件がある構成
規制や地理的な事情から、事前定義されたペアリージョンを利用できない場合があります。この場合は、ゾーン冗長化を優先し、許可された境界内に保存したバックアップから復元する構成が候補になります。
復旧時間は長くなりやすいものの、データを管轄外へ移動させないことを優先できます。
データごとに復旧方式を分ける非対称構成
すべてのデータを同じ方法で保護する必要はありません。
たとえば、Webサーバーやアプリケーションサーバーは別リージョンへフェイルオーバーし、個人情報を含むデータベースは指定地域内のバックアップから復元する構成が考えられます。Microsoftは、このようにコンプライアンスと事業継続を両立させる非対称な設計も示しています。(Microsoft Azure)
AI更新の中心はInfrastructure Resiliency ManagerとResiliency Agent
今回のAI関連更新は、レジリエンス対策を完全自律化するものではありません。中心となるのは、構成の評価、改善案の提示、IaC生成を支援する機能です。
Azure Infrastructure Resiliency Manager
Azure Infrastructure Resiliency Managerは、Microsoft Build 2026で発表されたパブリックプレビュー機能です。
アプリケーションに関係するリソースをService Groupとしてまとめ、次の処理を一元化します。
- ゾーンレジリエンスの目標設定
- 現在の構成評価
- 非対応リソースの検出
- 改善方法とコスト影響の確認
- Recovery Planの管理
- Availability Zone Down Drillの実施
- 複数Service Groupの状態確認
Microsoftは、この運用サイクルを「Start resilient」「Get resilient」「Stay resilient」と表現しています。新規システムを最初から冗長化し、既存システムの不足を改善し、訓練と監視によって状態を維持する考え方です。(Microsoft Azure)
Resiliency Agent
Resiliency AgentはAzure Copilotに統合された対話型AIです。新規アプリケーションの構成を自然言語で説明して改善案を得たり、既存リソースを基にService Groupを作成して、ゾーンレジリエンスの不足を確認したりできます。
ARMテンプレート、Bicep、TerraformによるIaCを生成できるため、推奨内容をDevOpsのデプロイ工程へ組み込みやすい点が特徴です。(Microsoft Learn)
ただし、現時点では次の制限があります。
- リソースへの変更は自動実行されず、確認と手動実行が必要
- 即時利用できるスクリプトの対応リソースは限定される
- 複数ユーザー承認やAzure Site Recoveryなど、一部の高度な設定には手作業が必要
- AIの回答や生成コードは、適用前にテストとレビューが必要
Azure Copilotのレジリエンス向けスクリプトは、現時点ではVM、App Service、Azure Database for PostgreSQL、Azure Database for MySQL、SQL Managed Instance、Azure Cache for Redis、Azure Firewallなどに対応範囲が限定されています。(Microsoft Learn)
公式ブログでは、Azure Backup MCP Serverを利用し、バックアップ状態の確認や復旧準備の検証、ポリシーに基づく復元処理をエージェントから扱う方向性も示されています。利用する場合は、接続するエージェント、認証方式、実行権限、監査ログを個別に確認する必要があります。(Microsoft Azure)
公式モデルと現在のプレビュー機能を混同しない
今回の公式ブログが扱うレジリエンスモデルは、ゾーン、リージョン、データ保護、サイバー回復を含む広い概念です。
一方、Azure Infrastructure Resiliency Managerの現在のプレビュー版で評価できる目標は、主にゾーンレジリエンスです。したがって、ダッシュボード上ですべてのリソースが「Zone resilient」と表示されても、リージョン障害、ランサムウェア、データ破損、外部サービス障害まで含めた事業継続性が保証されるわけではありません。(Microsoft Learn)
そのほか、現時点では次の条件があります。
- 1つのService Groupに含められるリソースは最大500個
- 目標設定後に追加されたリソースは自動反映されず、再検出が必要
- サービスが評価できないリソースは「Not evaluated」となる
- 独自構成で冗長化している場合は手動証明を設定できる
- 非重要リソースは評価対象から除外できる
「Not evaluated」は「問題なし」という意味ではありません。未対応、除外、検出不能のいずれなのかを確認する必要があります。(Microsoft Learn)
利用条件と現在の制限
| 機能 | 主な利用条件 | 注意点 |
|---|---|---|
| Resiliency in Azure | AzureサブスクリプションからAzure portalのResiliencyダッシュボードを利用 | 一部のゾーン関連機能はプレビュー。従来のAzure Business Continuity Center機能は継続利用可能 (Microsoft Learn) |
| Goals and Recommendations | Service Group、Usage Plan、必要なAzure RBACロールを設定 | 現在はゾーンレジリエンス目標が中心。1 Service Groupあたり最大500リソース (Microsoft Learn) |
| Resiliency Agent | テナントの許可リスト登録と、Azure Copilot管理センターでAgentsプレビューを有効化 | 自動変更は行わない。利用開始には承認を待つ場合がある (Microsoft Learn) |
| Availability Zone Down Drill | Availability Zone対応リージョン、Recovery Plan、専用RBAC、リソースプロバイダー登録 | Sovereign Cloudsは対象外。実際に停止・再起動・強制フェイルオーバーを起こすリソースがある (Microsoft Learn) |
| Azure Copilot | Azure Copilotへのアクセス権と、指定WebSocket接続を許可 | 日本語対応。Azure Governmentと21Vianet運営のAzureでは利用不可 (Microsoft Learn) |
Infrastructure Resiliency Managerでは、BasicとStandardのUsage Planが用意されています。Basicは目標、状態確認、推奨事項が中心で、StandardはRecovery Planやドリル機能を含みます。
プレビュー期間中のInfrastructure Resiliency Manager自体は無料とされていますが、ゾーン冗長化、追加インスタンス、ストレージ複製、Log Analytics、Azure Chaos Studioなど、関連サービスの利用料金は別途発生する可能性があります。Usage Planは、一般提供後に課金が始まる場合の請求先サブスクリプションを指定する役割も持ちます。(Microsoft Learn)
Azure Copilotの現行機能は追加料金なしと案内されていますが、将来の機能は有料になる可能性があります。導入判断時には、最新の価格情報を再確認してください。(Microsoft Learn)
データ境界は「業務データ」と「AI会話データ」を分けて確認する
データ境界を確認するときは、アプリケーションが扱う業務データと、Azure Copilotに入力する会話データを分けて考える必要があります。
業務データと復旧データの境界
業務データについては、次の項目を明文化します。
| 確認項目 | 判断内容 |
|---|---|
| 通常時の保存先 | 利用するAzureリージョンと可用性ゾーン |
| 同一リージョン内の複製 | LRS、ZRSなど、どの冗長化方式を使用するか |
| リージョン間の複製 | GRSやAzure Site Recoveryで域外へ移動してよいか |
| バックアップ先 | バックアップデータを保存できる国・地域 |
| 復旧先 | 障害時にどのリージョンへ復旧できるか |
| ログと監視データ | Log Analyticsや診断ログの保存地域 |
| 暗号鍵 | Microsoft管理キーか顧客管理キーか |
Microsoftも、規制対象の環境では、データの保存場所、移動先、復旧方法を利用者が明示的に定義する必要があると説明しています。(Microsoft Azure)
Availability Zone Down Drillでは、Chaos WorkspaceとLog Analytics Workspaceを作成するサブスクリプションとリージョンを選択します。そのリージョンは、評価対象のService Groupと異なる場合があります。業務データだけでなく、監視ログや訓練結果の保存先もデータ境界の確認対象に含めてください。(Microsoft Learn)
Azure Copilotのプロンプトと会話履歴
Microsoftの説明では、Azure Copilotへ入力したプロンプトと回答は、回答生成に使用するAzure OpenAI Serviceの基盤モデルを追加学習するためには利用されません。
ただし、利用者が明示的に同意してフィードバックへ含めた情報は、Microsoft製品やサービスの改善に利用される場合があります。また、セッション数、利用時間、使用された機能、評価などのエンゲージメントデータは収集されます。(Microsoft Learn)
会話履歴は、既定ではMicrosoftが管理します。組織が管理するAzure Cosmos DBへ保存するBring Your Own Storageも利用でき、全利用者のプロンプトと回答を監査証跡として保持できます。保存期間は組織側のデータ保持ポリシーで管理します。(Microsoft Learn)
ただし、Bring Your Own Storageが明示的に制御するのは会話履歴の保存先です。AI処理全体が選択したCosmos DBリージョン内だけで完結することを示す機能ではありません。厳格なデータ所在地要件がある場合は、会話へ入力できる情報の分類基準と、利用規約上のデータ処理条件を別途確認してください。
また、保存先を切り替えると、切り替え前の会話履歴をAzure Copilot上から参照できなくなる場合があります。監査目的で利用する場合は、切り替え時期と保持方針を事前に決めておく必要があります。(Microsoft Learn)
管理者が設定すべきアクセス制御
Azure Copilotは既定でテナント内の全利用者がアクセスできる構成です。Global Administratorは、Azure Copilot管理センターから利用対象をMicrosoft Entraのユーザーまたはグループへ限定し、「Copilot for Azure User」ロールを割り当てられます。(Microsoft Learn)
管理対象は、次の層に分けると整理しやすくなります。
| 管理層 | 主な制御 |
|---|---|
| テナント | Azure Copilotを利用できるユーザー・グループを限定 |
| エージェント | Agentsプレビューをテナント単位で有効化・無効化 |
| Azureリソース | Azure RBAC、Privileged Identity Management、Azure Policy、リソースロックを適用 |
| Service Group | 閲覧、目標設定、除外、手動証明の権限を分離 |
| ドリル | ドリル作成者、Recovery Plan管理者、障害注入対象の管理者を分離 |
| 会話履歴 | Microsoft管理または自社Cosmos DBを選択し、保持期間を設定 |
| 構成変更 | 生成されたIaCをリポジトリ、レビュー、CI/CD経由で適用 |
Azure Copilotは、利用者本人が閲覧できるリソースだけを参照し、本人に許可された操作だけを実行できます。Azure RBAC、Privileged Identity Management、Azure Policy、リソースロックも引き続き適用され、変更時には確認が必要です。(Microsoft Learn)
限定的に試す場合の設定順序
Agentsプレビューはテナント単位で有効化されます。承認後は、Azure Copilotを利用できるユーザー全員がプレビューエージェントを利用でき、新しいエージェント機能も追加される可能性があります。(Microsoft Learn)
そのため、限定的な検証では次の順序が安全です。
- Azure Copilotの利用対象を検証グループへ限定する
- 検証用ユーザーへ必要最小限のAzure RBACを付与する
- Agentsプレビューをテナントで有効化する
- Resiliency Agentの許可リスト登録を申請する
- 生成されたIaCを直接適用せず、Git上でレビューする
- 検証後に利用者、対象サブスクリプション、運用ルールを段階的に広げる
プレビュー用トグルだけに依存せず、Azure Copilot本体のアクセス対象を管理することが重要です。
Service Groupとドリルの権限を分離する
Infrastructure Resiliency Managerでは、閲覧だけならService Group Reader、目標設定や除外にはService Group Contributorなど、操作ごとに異なるロールが必要です。リソース単位の推奨事項を表示するには、対象リソースへのReader権限も必要になります。(Microsoft Learn)
Availability Zone Down Drillでは、さらに次のような権限が使われます。
- SG Drill Contributor
- Recovery Plan Contributor
- Drill Assets Contributor
- Drill Resource Fault Contributor
- Log Analytics Contributor
- Monitoring Contributor
- User Access Administrator
特にUser Access Administratorは影響範囲が大きいため、常時付与せず、Privileged Identity Managementによる一時的な昇格を検討すべきです。ドリル用マネージドIDにも、対象リソースと必要な操作だけを許可します。(Microsoft Learn)
業務や開発での使いどころ
| 利用者 | 活用シーン | 得られる効果 |
|---|---|---|
| 経営・BCP担当 | 重要業務ごとの停止影響、RPO、RTOを整理 | 可用性投資の優先順位を説明しやすくなる |
| クラウド基盤担当 | 複数サブスクリプションのリソースをService Groupで管理 | 単一ゾーンのリスクや設定漏れを発見しやすい |
| SRE・運用担当 | Recovery PlanとZone Down Drillを実行 | 障害時の挙動と復旧手順を実証できる |
| アプリ開発者 | 新規構成をResiliency Agentへ説明し、IaCを生成 | 設計初期からゾーン冗長化を組み込みやすい |
| セキュリティ担当 | バックアップの不変性、論理削除、承認方式を確認 | ランサムウェア後の安全な復旧方法を整備できる |
| 監査・コンプライアンス担当 | 訓練結果、構成評価、是正記録を保存 | 復旧能力を設定値だけでなく証跡で示せる |
| 規制業種 | データごとにフェイルオーバーとバックアップ復元を使い分ける | データ所在地と事業継続を両立しやすい |
開発チームにとっては、AIが提示した構成をそのまま採用することより、推奨内容をBicepやTerraformとしてコードレビューできる点が実用的です。
たとえば、Resiliency Agentがゾーン冗長のApp Service Planやデータベース構成を生成しても、次の項目は人が確認します。
- 対象リージョンで必要なSKUを利用できるか
- ゾーン冗長化による追加料金を許容できるか
- 既存データを移行する際に停止が発生するか
- Private EndpointやDNS構成が維持されるか
- Azure Policyや命名規則に適合するか
- 別リージョンへのデータ移動が規定に反しないか
実務で導入する手順
重要なワークロードを一つ選ぶ
全環境を一度に評価するのではなく、停止時の影響が大きいアプリケーションを一つ選びます。
最低限、次の項目を記録します。
- 業務責任者
- 重要なユーザーフロー
- 許容停止時間であるRTO
- 許容データ損失であるRPO
- データを保存・複製できる国や地域
- 現在のゾーン、リージョン、バックアップ方式
- 最後に復旧テストを行った日
依存関係をアプリケーション単位で整理する
VMやデータベースだけでなく、ネットワーク、DNS、Key Vault、認証、外部API、監視、デプロイパイプラインまで含めます。
Infrastructure Resiliency Managerの検出対象から除外されるネットワークや監視のサブリソースもあるため、ダッシュボードだけに依存しないことが重要です。(Microsoft Learn)
対応リソースをサポートマトリックスで確認する
Goals and Recommendationsが評価できるリソースと、Zone Down Drillでネイティブ障害を実行できるリソースは同じではありません。
評価対象にはAzure VM、SQL Database、Cosmos DB、Storage Account、AKS、Application Gateway、Azure Firewallなどが含まれます。一方、ネイティブドリルの対象はVM、VM Scale Sets、AKS、PostgreSQL、MySQL、SQL Database、Load Balancer、Azure Cache for Redis、App Serviceなどに限定されています。(Microsoft Learn)
対応していないリソースは、Azure Runbooksを利用したカスタムスクリプトで障害処理を定義できます。
Service Groupを作成して目標を設定する
アプリケーションを構成するリソースをService Groupへまとめ、Usage Planとゾーンレジリエンス目標を設定します。
結果を確認するときは、次の3分類を区別します。
- Zone resilient：推奨されるゾーン冗長構成が検出された
- Non zone-resilient：ゾーン冗長構成が検出されなかった
- Not evaluated：対象外、除外済み、または未対応
独自のアプリケーションレベル構成で冗長化している場合は、根拠を残したうえで手動証明を利用します。
Resiliency Agentの提案をIaCとしてレビューする
生成されたARM、Bicep、Terraformは、検証用ブランチへ保存します。
次の工程を通してから適用します。
- 静的解析
terraform planやWhat-Ifによる差分確認- Azure Policyの適合確認
- セキュリティレビュー
- コスト見積もり
- 非本番環境へのデプロイ
- ロールバック手順の確認
- 承認後の本番反映
ゾーン障害とバックアップ復元を別々に試す
Zone Down Drillでは、リソースの種類に応じてVM停止、ノードプール停止、強制フェイルオーバー、キャッシュの再起動、App Serviceインスタンス停止などが発生します。最初から本番全体を対象にせず、検証環境または影響を限定したService Groupで実行します。(Microsoft Learn)
また、ゾーン障害の訓練に成功しても、削除やデータ破損から復元できるとは限りません。Azure Backupから別環境へ復元し、アプリケーションを起動できるところまで確認します。
結果を運用手順へ戻す
ドリル後は、成功・失敗だけでなく、次の内容を記録します。
- 実測RTO
- 実測RPO
- 手作業が必要だった工程
- 権限不足や接続エラー
- 復旧時に不足した容量
- アラートが届かなかった箇所
- 実行できなかったリソース
- 次回までの改善担当者と期限
この記録をRecovery Plan、IaC、監視設定、障害対応手順へ反映して初めて、継続的なレジリエンス改善になります。
失敗しやすいポイントと対策
| 失敗しやすい判断 | 問題点 | 対策 |
|---|---|---|
| SLAが高いので対策不要と考える | アプリケーション依存関係やデータ復旧を評価できない | 重要なユーザーフロー単位で停止影響を確認する |
| リージョンペアだけで復旧先を決める | サービス提供状況、容量、遅延、データ所在地を見落とす | ワークロードごとに復旧先を選定する |
| ダッシュボードが100％なら安全と判断する | 現在の評価はゾーンレジリエンスが中心 | リージョン障害、バックアップ、サイバー回復を別途確認する |
| Not evaluatedを問題なしと解釈する | 未対応や除外されたリソースが隠れる | 除外理由と手動証明の根拠を定期確認する |
| 評価対象ならドリルも実行できると思う | 評価とネイティブ障害注入では対応リソースが異なる | それぞれのサポートマトリックスを確認する |
| AIが生成したIaCを直接本番へ適用する | 誤設定、料金増加、停止、規制違反の可能性がある | Pull Request、差分確認、非本番テストを必須にする |
| バックアップジョブの成功だけを確認する | 復元後にアプリケーションが動くとは限らない | 定期的に別環境への復元と起動を試す |
| BYOSで全AI処理が指定地域内になると考える | BYOSが明示的に管理するのは会話履歴の保存先 | 入力ルールとサービスのデータ処理条件を別途確認する |
まず一つの重要システムから現状を可視化する
Microsoft Azure resiliency servicesの今回の更新は、新しい機能を一斉導入するための告知ではありません。Azureのレジリエンスを、個別サービスの設定ではなく、アプリケーション全体の設計、データ保護、サイバー回復、継続的な訓練として扱うための再整理です。
最初に行うべきことは、最重要アプリケーションを一つ選び、RPO、RTO、データ所在地、ゾーンとリージョン、復旧方法、最終テスト日を一枚にまとめることです。
その結果、単一ゾーンのリスクや復旧手順の不足が見つかった場合は、Infrastructure Resiliency ManagerのGoals and Recommendationsを検証します。AI機能を使う場合は、Azure Copilotの利用者を限定し、生成されたIaCを通常のコードレビューとCI/CDに組み込んでください。
レジリエンスの価値は、サービスを何個導入したかではなく、設計、評価、改善、訓練、再評価のサイクルを継続できるかで決まります。
コメント