| name | resilience-hub-multi-account |
| description | Configures AWS Resilience Hub v2 for multi-account resilience management across an AWS Organization. Covers the per-service cross-account permission model, cross-account IAM roles, and centralized assessment from a single account. Applies when the user wants to set up org-wide resilience or assess workloads that span multiple AWS accounts.
|
| version | 1 |
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.
