Multi-Account Resilience Hub v2 Setup

Overview

Domain expertise for configuring Resilience Hub v2 to assess services across multiple AWS accounts from a central account. All CLI commands in this skill use the aws resiliencehubv2 namespace — the Resilience Hub v2 API surface — which is distinct from the legacy aws resiliencehub (v1) commands (the service: [resiliencehub, ...] metadata tags the service family, not the CLI namespace). Resilience Hub v2 supports two complementary multi-account mechanisms: (1) an AWS Organizations integration — the management account enables trusted access, creates the service-linked role, and designates a delegated administrator account for organization-wide policy management and visibility; and (2) the per-service cross-account permission model — an invoker role in the central account that assumes cross-account roles in member accounts for per-service resource discovery. This skill configures (2); the Organizations integration (1) is set up separately (management account + console — see below).

The AWS MCP server is recommended for executing this skill's AWS API calls, but it is not required — all operations also work with the AWS CLI directly.

Guardrail — where this skill's own files live (MCP vs local install)

Before reading a reference file, determine how this skill was loaded:

• Loaded via the AWS MCP retrieve_skill tool: the skill's reference files are not on the local filesystem. Fetch each one through retrieve_skill with the file parameter (e.g. file="references/multi-account-procedure.md") — do NOT file_read these paths locally or search the filesystem for them.
• Installed locally (e.g. .kiro/skills/resilience-hub-multi-account/ or ~/.claude/skills/resilience-hub-multi-account/): read reference files from the local skill directory using the relative paths shown here.

This applies only to the skill's own reference files; always read and write user or session data in the working directory, never through retrieve_skill.

How centralized multi-account assessment works

Two paths, used depending on your goal:

Decision rule (read first): To run cross-account resilience assessments — i.e. assess workloads/resources that live in member accounts from a central account (the common request, including phrasings like "centralized resilience management across my Organization" or "central assessment account") — use the per-service cross-account permission model (path 2 below): an invoker role + cross-account roles + create-service --permission-model. Do NOT use or recommend aws organizations register-delegated-administrator (or any delegated-administrator registration) as the setup step for cross-account assessments. The Organizations delegated-administrator integration (path 1) is a separate, optional feature scoped to organization-wide policy management and visibility only — it is not how you set up or run cross-account assessments. Only follow path 1 when the request is explicitly about org-wide policy governance, not assessment.

• Organization-wide governance (centralized policies, cross-account visibility): use the AWS Organizations integration. From the management account, enable trusted access for Resilience Hub, create the service-linked role, and register a delegated administrator account. This is done via Organizations trusted access + the Resilience Hub console — there is no resiliencehubv2 register-delegated-administrator CLI operation. The delegated administrator then selects a home Region where organization-level data is aggregated. See the AWS docs page Setting up Organizations integration.
• Per-service cross-account resource discovery (assessing a service whose resources span accounts): register each service with a per-service cross-account permission model — an invoker role in the central account plus cross-account role ARNs for each member account. This skill's steps configure this path. Use this command form:

aws resiliencehubv2 create-service --name {service} --regions {regions} \
  --permission-model '{"invokerRoleName":"ResilienceHubAssessmentRole","crossAccountRoles":[{"crossAccountRoleArn":"arn:aws:iam::{member_account_id}:role/ResilienceHubAccess","externalId":"{external_id}"}]}'

The externalId is a shared secret that defends against confused-deputy attacks — generate a cryptographically random value and store it in AWS Secrets Manager or SSM Parameter Store (SecureString); never commit it to source control or embed it in templates without a dynamic {{resolve:secretsmanager:...}} reference, and ensure it is not emitted in plaintext by CI/CD logs or infrastructure-as-code output (use CloudFormation NoEcho parameters and mask it in pipeline logs).

The cross-account role (in the member account) trusts the central account's invoker role. You can configure multiple cross-account role ARNs per service — the resiliencehubv2 API enforces a maximum (illustratively 5), so verify the accepted limit from the API/model rather than assuming a fixed number. Note: this per-service model is independent of the Organizations integration above — there is no register-delegated-administrator operation in the resiliencehubv2 CLI; organization-wide delegated-administrator registration is performed via AWS Organizations trusted access and the Resilience Hub console, not a resiliencehubv2 API call.

Configure multi-account setup

To set up cross-account assessment, follow the procedure exactly. See references/multi-account-procedure.md.

Troubleshooting

Cross-account assessment fails with AccessDenied

Verify: (1) the cross-account role ARN in the permission model matches exactly, (2) the cross-account role trust policy allows the central account's invoker role to assume it, (3) the externalId matches if configured.

No resources discovered in a member account

Confirm the cross-account role has read permissions for the in-scope resource types (CloudFormation, EC2, RDS, etc.) and that input sources point to valid resources in the correct region.

Looking for a delegated-administrator setup

Resilience Hub v2 does support an AWS Organizations integration with a delegated administrator for organization-wide policy management and visibility — but it's configured from the management account via Organizations trusted access + the Resilience Hub console (create the service-linked role, then register the delegated administrator), not through a resiliencehubv2 CLI operation (there is no register-delegated-administrator API). To assess a single service whose resources span accounts, use the per-service cross-account permission model in this skill. The two are complementary.

Security Considerations

• Least privilege & read-only: scope member-account cross-account roles to read-only discovery permissions (cloudformation:Describe*, ec2:Describe*, rds:Describe*, etc.) rather than write/mutate actions.
• Scope cross-account trust narrowly: trust only the specific central invoker role ARN rather than the whole account where possible.
• Enable logging & monitoring: ensure AWS CloudTrail is enabled in both the central and member accounts to log cross-account sts:AssumeRole calls, and alarm on failed or unexpected AssumeRole attempts against the cross-account roles.
• Further reading: see IAM best practices, The confused deputy problem, and Security in AWS Resilience Hub for cross-account hardening guidance.