はじめに
今回は、2026年9月18日に発表されたAWS Resilience Hubのレジリエンスポリシーの組織共有について説明します。
AWS Resilience Hubは、AWS上のワークロードが障害時の復旧目標を満たせるかを評価し、改善策を提示するサービスです。2026年5月には次世代のResilience Hubが発表され、評価の対象となるワークロードを「サービス」として登録し、サービスを構成するリソースをAWS CloudFormationのスタックやタグ、Amazon EKSのクラスターなどの「入力ソース」で指定する形になりました。
評価の基準となるのが「レジリエンスポリシー」です。レジリエンスポリシーは、障害の発生から復旧までに許容される時間であるRTOや、許容できるデータ損失の範囲であるRPOといった目標をまとめたもので、サービスに指定して使います。例えば「マルチAZ構成でRTO30分・RPO15分」のように、ワークロードの重要度に応じた目標を定義します。
今回のアップデートでは、Amazon EKSのラベルを使ったサービスの入力ソース指定、サービスが依存しているAWSサービスや外部エンドポイントを検出・分析する依存関係インサイト、AWS Organizationsを通じたレジリエンスポリシーの共有という3つの機能が追加されました。
このうちレジリエンスポリシーの共有は、CCoEや共通基盤チームが定めたRTO・RPOの基準を組織内の各アカウントに公開し、各アカウントのサービス所有者が自分で選んで適用できるようにするものです。マルチアカウント環境で可用性の基準を統一したいと考えていた方にとっては気になるアップデートかと思います。
本稿では、委任管理者を設定し、共有したポリシーがメンバーアカウントからどのように見え、共有を停止したときに何が起きるのかを確認しました。
Resilience HubのOrganizations連携とポリシーの共有
次世代のResilience Hubでは、発表時からOrganizations連携が提供されており、委任管理者アカウントから組織内の各アカウントのサービスをまとめて確認できました。一方で、メンバーアカウントのサービスに直接指定できるレジリエンスポリシーは、そのアカウント自身で作成したものに限られていました。今回のアップデートにより、委任管理者アカウントや管理アカウントで作成したポリシーを組織に共有し、メンバーアカウントのサービスにそのまま指定できるようになりました。
公式ドキュメントでは、Organizations連携を有効にすると、委任管理者アカウントから組織全体のレジリエンスの状況を確認できると説明されています。委任管理者がメンバーアカウントの情報を参照するために、各メンバーアカウントにはサービスリンクロールが自動的に作成されます。ただし、本稿では障害モード評価を実行していないため、委任管理者アカウントから確認できたのは、共有したポリシーがどのアカウントのどのサービスに適用されているかまでです。Organizations連携自体は次世代のResilience Hubの発表時から提供されており、今回のアップデートでは、ここにポリシーの共有が加わりました。
ドキュメントによると、委任管理者アカウントまたは管理アカウントでポリシーの共有を有効にすると、そのポリシーが組織内のメンバーアカウントに公開されます。公開されたポリシーを自分のサービスに適用するかどうかは、メンバーアカウント側のサービス所有者が選びます。共有を有効にしただけで、各アカウントのサービスに自動で適用されるわけではありません。
この共有はAWS Resource Access Managerを使うものではなく、Resilience Hub自身の機能として提供されています。共有先のOUやアカウントを指定する項目はなく、共有を有効にしたポリシーは組織内のメンバーアカウントの一覧に表示されます。
なお、次世代のResilience Hubは従来のResilience Hubとは別のAPIとして提供されており、AWS CLIでもaws resiliencehubではなくaws resiliencehubv2という別のコマンドになっています。筆者の環境では、AWS CLI 2.34.21にはresiliencehubv2が含まれておらず、2.37.1に更新して利用できるようになりました。CLIで操作する場合は、事前にバージョンを確認しておきましょう。
検証環境
本稿では、下記の環境で確認を行いました。
| # | アカウント | 役割 |
| 1 | 管理アカウント | Organizationsの管理アカウント |
| 2 | 委任管理者アカウント | Resilience Hubの委任管理者として今回登録 |
| 3 | Workload | メンバーアカウント。共有ポリシーを適用するサービスを作成 |
委任管理者アカウントには、これまでの回と同様に管理アカウントとは別のアカウントを使っています。第33回でポリシー管理を委任したアカウントと同じです。
リージョンは東京リージョンを使っています。
管理アカウントでの操作
ドキュメントでは、管理アカウントで次世代Resilience Hubのコンソールを開き、「AWS Organizations の設定」から信頼されたアクセスの有効化とサービスリンクロールの作成、委任管理者の登録を行う手順が紹介されています。本稿では、Organizationsのユーザーガイドに記載されているCLIの手順で同じ設定を行いました。
（1）信頼されたアクセスを有効にします。
~ $ aws organizations enable-aws-service-access \
> --service-principal resiliencehub.amazonaws.com
（2）管理アカウントにサービスリンクロールを作成します。
~ $ aws iam create-service-linked-role \
> --aws-service-name resiliencehub.amazonaws.com
（3）委任管理者を登録します。
~ $ aws organizations register-delegated-administrator \
> --account-id {委任管理者アカウントID} \
> --service-principal resiliencehub.amazonaws.com
これで管理アカウントの操作は完了です。コンソールの「AWS Organizations の設定」画面を開くと、信頼されたアクセスが有効化済み、サービスリンクロールが作成済みとなり、委任管理者が登録されていることを確認できます。
ここで、各アカウントのサービスリンクロールAWSServiceRoleForResilienceHubの作成日時を確認したところ、以下のとおりでした。
| # | アカウント | サービスリンクロールの作成 |
| 1 | 管理アカウント | 手順2で手動作成するまで作成されなかった |
| 2 | 委任管理者アカウント | 信頼されたアクセスの有効化から約1分半後に自動作成 |
| 3 | Workload | 同上 |
メンバーアカウントのサービスリンクロールは、信頼されたアクセスを有効にしてから約1分半で作成されており、委任管理者の登録を待つ必要はありませんでした。
一方、管理アカウントのサービスリンクロールは、信頼されたアクセスを有効にしてから1時間以上経っても作成されていませんでした。Organizationsのユーザーガイドでは、信頼されたアクセスを有効にすると管理アカウントに自動で作成されると説明されている一方、Resilience Hubのユーザーガイドでは管理アカウントで作成する必要があると説明されており、両者の記載が一致していません。筆者の環境では自動では作成されなかったため、CLIで設定する場合は手順2を忘れずに実施してください。
委任管理者アカウントでの操作
次に、委任管理者アカウントで、共有を有効にしたポリシーを作成します。ここでは、マルチAZでのRTO30分・RPO15分と、1日1回のバックアップを目標とするポリシーを作成しました。ポリシー名のTier1-MultiAZは筆者が付けた名前です。ワークロードを重要度で段階分けし、最も重要な段階をTier1と呼ぶ運用を想定して、Tier1のワークロードがマルチAZで満たすべき目標という意味で名付けています。なお、コンソールではレジリエンスポリシーが「耐障害性ポリシー」と表示されています。
（1）委任管理者アカウントにサインインし、東京リージョンでResilience Hubのコンソールを開きます。サイドメニューの「管理」から「ポリシー」をクリックし、「ポリシーを作成」ボタンをクリックします。
（2）「ポリシーの詳細」で、ポリシー名にTier1-MultiAZ、説明にCCoE standard: Tier1 workloadsを入力します。「AWS Organizations access」の「Enable organization access」にチェックを入れると、このポリシーが組織のメンバーアカウントに共有されます。キャプチャの取得時点では日本語のコンソールでもこの項目は英語で表示されていましたが、現在は「AWS Organizations アクセス」の「組織アクセスを有効にする」と表示されます。説明には、この設定を変更できるのは管理アカウントと委任管理者アカウントのみであると記載されています。続いて、「耐障害性要件」で「ディザスタリカバリ要件」と「データ復旧要件」にチェックを入れ、「ディザスタリカバリの境界」で「マルチ AZ」にチェックを入れます。
（3）「マルチ AZ 復旧要件」で、目標復旧時間（RTO）に30分、目標復旧時点（RPO）に15分を入力し、「ディザスタリカバリアプローチ」で「アクティブ/アクティブ」を選択します。「データ復旧要件」の「データ復旧目標」には、1日1回のバックアップを表す1440分を入力します。「データ暗号化」はデフォルトのままとし、画面下部の「ポリシーを作成」ボタンをクリックします。
これで委任管理者アカウントの操作は完了です。作成済みのポリシーの共有を有効にしたい場合は、ポリシーを編集して「Enable organization access」にチェックを入れます。
メンバーアカウントでの確認
共有ポリシーの見え方
WorkloadアカウントでResilience Hubのコンソールを開き、サイドメニューの「管理」から「ポリシー」をクリックすると、Workloadアカウントでは何もポリシーを作成していないにもかかわらず、委任管理者アカウントで作成したTier1-MultiAZが表示されました。「Org managed」列は「有効化済み」となっており、ポリシーARNには委任管理者アカウントのアカウントIDが含まれています。
続いて、自アカウントのポリシーとの違いを確認するため、WorkloadアカウントでもポリシーWorkload-Ownを作成しました。作成画面の項目は委任管理者アカウントの操作で紹介したものと同じで、ここではマルチAZでRTO60分・RPO60分、ディザスタリカバリアプローチを「バックアップと復元」としています。なお、メンバーアカウントの作成画面では、「AWS Organizations access」の「Enable organization access」がグレーアウトしており、チェックを入れることはできませんでした。メンバーアカウントが自分のポリシーを組織に共有することはできない、ということです。
作成後のポリシー一覧は以下のとおりです。
ドキュメントには、自アカウントのポリシーか共有されたポリシーかを見分けられると記載されています。コンソールでは、共有されたポリシーの「Org managed」列が「有効化済み」となり、自アカウントのポリシーは「-」となっていました。一方、CLIのlist-policiesの応答では、organizationIdは自アカウントのポリシーにも設定されており、共有かどうかを示す専用の項目はありませんでした。CLIで見分ける場合は、ポリシーのARNに含まれるアカウントIDを確認するとよいでしょう。
なお、同じWorkloadアカウントでもus-east-1でlist-policiesを実行した場合、共有ポリシーは表示されませんでした。共有はポリシーを作成したリージョンの中で行われるため、Resilience Hubを複数のリージョンで利用する場合は、利用するリージョンごとにポリシーを作成して共有する必要があります。
メンバーアカウントからの操作
メンバーアカウントから共有ポリシーに対して行える操作も確認しました。
| # | 操作 | 結果 |
| 1 | 共有ポリシーの参照（get-policy） | 可能 |
| 2 | 共有ポリシーの更新（update-policy） | 拒否 |
| 3 | 共有ポリシーの削除（delete-policy） | 拒否 |
| 4 | 共有を有効にしてポリシーを作成（create-policy --sharing-enabled） | 拒否 |
| 5 | 自アカウントのサービスへの共有ポリシーの適用 | 可能 |
4の操作では、以下のエラーが表示されました。共有を有効にできるのは、ドキュメントの記載どおり委任管理者と管理アカウントのみです。
An error occurred (AccessDeniedException) when calling the CreatePolicy operation: Only the delegated administrator or management account can enable policy sharing
共有ポリシーをサービスに適用する
それでは、Workloadアカウントでサービスを作成し、共有ポリシーを適用します。
（1）WorkloadアカウントでResilience Hubのコンソールを開き、サイドメニューの「管理」から「サービス」をクリックし、「サービスを作成」ボタンをクリックします。
（2）「サービスの詳細」でサービス名に sample-service を入力します。「耐障害性ポリシー」の「サービスレベルのポリシー」では、委任管理者アカウントから共有されたTier1-MultiAZを選択できます。「アクセス許可」では「デフォルトロールを作成」を選択し、「Role name」にResilienceHubServiceRole-sample-serviceを入力します。デフォルトロールを選択した場合でもロール名は必須で、空欄のままでは「IAM ロールは必須です。」というエラーが表示されます。
（3）「サービスアーキテクチャ」の「サービスリージョン」はap-northeast-1のままとします。「サービスリソースの検出」では、リソースを検出する方法を少なくとも1つ選択する必要があり、何も選択しないと「少なくとも 1 つのリソース検出方法を選択します。」というエラーが表示されます。CLIでは検出方法を指定しなくてもサービスを作成できたので、コンソールとは動きが異なります。今回はポリシーの適用を確認することが目的のため、「リソースタグ」を選択し、キーにService、値にsample-serviceを入力しました。このタグが付いたリソースが存在しなくても、サービスは作成できました。
（4）「依存関係の検出」は有効にすると追加料金が発生するため、チェックを入れないままとします。「データ暗号化」もデフォルトのままとし、「サービスを作成する」ボタンをクリックします。
（5）サービスの作成が完了すると、サービスの詳細画面が表示されます。「Service resilience lifecycle」の「定義する」欄に「ポリシーが関連付けられました」と表示されており、共有ポリシーがサービスに関連付けられたことを確認できます。
（6）画面を下にスクロールすると、「耐障害性ターゲット」欄に、マルチ AZ RTOが30分、マルチ AZ RPOが15分、バックアップ間のデータ復旧時間が1440分と表示されており、いずれもポリシー欄はTier1-MultiAZとなっていました。委任管理者アカウントで設定した目標値が、Workloadアカウントのサービスにそのまま適用されています。また、「アクセス許可」欄には、手順2で作成したデフォルトロールがservice-role/ResilienceHubServiceRole-sample-serviceとして表示されています。
同じ内容はCLIのget-serviceでも確認できます。effectivePolicyValuesがサービスに実際に適用される目標値で、各項目のsourceがCROSS_ACCOUNTとなっていることから、他アカウントから共有されたポリシーの値であることがわかります。
~ $ aws resiliencehubv2 get-service \
> --service-arn "arn:aws:resiliencehub:ap-northeast-1:{WorkloadアカウントID}:service/sample-service:xxxxxx" \
> --region ap-northeast-1 --query 'service.effectivePolicyValues'
{
"multiAzRto": { "value": 30, "policyName": "Tier1-MultiAZ", "source": "CROSS_ACCOUNT" },
"multiAzRpo": { "value": 15, "policyName": "Tier1-MultiAZ", "source": "CROSS_ACCOUNT" },
"multiAzDrApproach": { "value": "ACTIVE_ACTIVE", "policyName": "Tier1-MultiAZ", "source": "CROSS_ACCOUNT" },
"dataRecoveryTimeBetweenBackups": { "value": 1440, "policyName": "Tier1-MultiAZ", "source": "CROSS_ACCOUNT" }
}
※ 出力は見やすいように整形しています。
なお、手順2で作成されたデフォルトロールをIAMで確認したところ、service-role/のパスに作成されており、信頼ポリシーにはresiliencehub.amazonaws.comに加えて、自アカウントのサービスに限定するaws:SourceAccountとaws:SourceArnの条件が設定されていました。アタッチされていたAWS管理ポリシーは、次世代のResilience Hub向けのAWSResilienceHubV2AssessmentExecutionPolicyと、AWS Fault Injection Serviceによるレジリエンステスト用のAWSResilienceHubResilienceTestingPolicyの2つです。
ドキュメントによると、前者は障害モード評価などのためにリソースを読み取る権限、後者はレジリエンステストでAWS Fault Injection Serviceの実験を開始・管理する権限を与えるポリシーです。つまり、デフォルトロールにはテストに必要な権限もあらかじめ含まれています。一方で、レジリエンステストを利用しない場合、後者はワークロードに障害を注入できる不要な権限ということになります。最小権限を重視する環境では、評価用のポリシーだけを付けたロールを事前に作成し、「別のロールを使用」で指定することも検討するとよいでしょう。
委任管理者アカウントでの確認
次に、委任管理者アカウントで「ポリシー」からTier1-MultiAZを開き、「関連付けられたサービス」タブをクリックすると、Workloadアカウントのsample-serviceが表示されました。共有したポリシーをどのアカウントのどのサービスが利用しているかを、委任管理者アカウントから把握できます。なお、画面の「AWS Organization access」は、現在は「AWS Organization アクセス」と表示されます。
CLIでは、list-servicesにポリシーのARNを指定すると同じ一覧を、list-policy-eventsでは適用や共有停止の履歴を確認できます。ただし、get-policyで取得できるassociatedServiceCountは、委任管理者アカウント自身のサービスだけを数え、メンバーアカウントのサービスは含みませんでした。CLIで利用状況を確認する場合は、associatedServiceCountではなくlist-servicesを使うとよいでしょう。
共有を停止したときの挙動
最後に、委任管理者アカウントでポリシーの共有を停止し、共有ポリシーを適用しているサービスがどうなるかを確認します。
（1）委任管理者アカウントで「ポリシー」からTier1-MultiAZを開き、「編集」ボタンをクリックします。「Enable organization access」のチェックを外すと、「When organization access is disabled, member accounts in your AWS Organization will lose access to this policy. Services and systems that have this policy attached will no longer be governed by it.」という警告が表示されます。
組織のメンバーアカウントはこのポリシーにアクセスできなくなり、このポリシーが関連付けられたサービスやシステムは、このポリシーによる管理の対象外になる、という内容です。内容を確認し、変更を保存します。
（2）更新が完了すると、ポリシーの詳細の「AWS Organization access」が「無効化済み」となります。
共有を停止したあと、Workloadアカウントのポリシー一覧を開くと、Tier1-MultiAZは表示されなくなり、自アカウントのWorkload-Ownのみとなりました。CLIでget-policyを実行して参照しようとしても、拒否されるようになりました。
An error occurred (AccessDeniedException) when calling the GetPolicy operation: User: arn:aws:sts::{WorkloadアカウントID}:assumed-role/... is not authorized to perform: resiliencehub:GetPolicy on resource: * with an explicit deny in a resource-based policy. The customer account ID does not match with the account ID provided in the input ARN
ドキュメントには、共有を停止するとメンバーアカウントのサービスに対する評価がただちに停止され、その後ポリシーの適用が解除されると記載されています。実際に共有停止の約20秒後にWorkloadアカウントのサービスをCLIで確認すると、effectivePolicyValuesは空になっていました。一方、サービスのpolicyArnには共有ポリシーのARNが残ったままでした。
コンソールでsample-serviceの詳細を開くと、「定義する」欄には引き続き「ポリシーが関連付けられました」と表示されていました。その一方で、「評価」欄のマルチ AZ RTO/RPOやバックアップ間のデータ復旧時間は、「ポリシーで定義されていません」に変わっていました。
画面を下にスクロールすると、「耐障害性ターゲット」欄も、適用された値とポリシーがすべて「-」になっていました。ポリシーは関連付けられていると表示される一方で、評価の基準となる目標値は何も適用されていない、という状態です。
その後もpolicyArnは解除されませんでした。サービスのイベントをlist-service-eventsで確認しても、記録されているのはサービスの作成・入力ソースの更新・ポリシーの関連付けのみで、ポリシーの解除に関するイベントはありませんでした。なお、筆者が別途同じ手順で確認した際には、共有の停止から約10時間が経過してもpolicyArnは解除されませんでした。評価の対象となる目標値が空になっているため、実質的にはポリシーが適用されていない状態ですが、policyArnだけを見ると共有ポリシーが適用されているように見えてしまいます。
委任管理者アカウントのlist-policy-eventsには、共有を停止したことがPOLICYSHARINGREVOKEDとして記録されていました。
なお、この状態で共有を再度有効にしたところ、policyArnが残っていたWorkloadアカウントのサービスには、Tier1-MultiAZの目標値が再び適用されました。
課題となりやすいポイント
最後に課題となりやすいポイントを紹介します。
（1）ポリシーの共有はリージョン単位です。東京リージョンで共有したポリシーは、同じアカウントでもus-east-1からは見えませんでした。Resilience Hubを複数のリージョンで利用する場合は、利用するリージョンごとにポリシーを作成して共有する必要があります。
（2）共有先のOUやアカウントを指定することはできず、共有したポリシーは組織内のメンバーアカウントに一律に表示されます。重要度などに応じて複数のポリシーを共有する場合は、メンバーアカウントのサービス所有者が選び間違えないよう、ポリシー名や説明から対象がわかるようにしておくとよいでしょう。
（3）CLIとマネジメントコンソールでは、同じ設定や状態に対する表示や動きに差がありました。本稿で触れたように、CLIで設定した場合に管理アカウントのサービスリンクロールが自動では作成されないことや、associatedServiceCountにメンバーアカウントのサービスが含まれないこと、共有停止後、目標値は空になる一方でpolicyArnや「ポリシーが関連付けられました」の表示は残ることなど、いくつかの差を確認しています。どちらか一方の表示だけで判断せず、必要に応じて両方で確認するとよいでしょう。
（4）共有ポリシーを適用するかどうかはメンバーアカウントのサービス所有者の判断に委ねられており、共有しただけでは組織全体に基準が適用されるわけではありません。委任管理者アカウントからポリシーの「関連付けられたサービス」タブなどで適用状況を定期的に確認し、未適用のサービスには適用を働きかけるなど、運用でカバーする必要があります。
おわりに
今回は、AWS Resilience HubのレジリエンスポリシーをAWS Organizationsで共有する機能について、委任管理者を設定し、メンバーアカウントからの見え方や共有停止時の挙動を説明しました。CCoEが定めた可用性の基準を1つのポリシーとして組織に配布できるようになったことは、マルチアカウント環境でのレジリエンス管理にとって大きな前進かと思います。
一方で、共有がリージョン単位であることや、共有しただけではサービスに適用されないこと、共有停止後もサービスにポリシーのARNが残ることなど、設計の前に把握しておきたい点もありました。本稿が、AWS Organizations環境でResilience Hubの活用を検討されている方の参考になれば幸いです。
