resilience-hub-multi-account

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Multi-Account Resilience Hub v2 Setup

多账户AWS Resilience Hub v2配置

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.

本指南提供从中央账户配置Resilience Hub v2以跨多个AWS账户评估服务的专业知识。本技能中的所有CLI命令均使用**

aws resiliencehubv2

命名空间——即Resilience Hub v2的API接口——这与旧版
aws resiliencehub
（v1）命令不同（
service: [resiliencehub, ...]
元数据标记的是服务系列，而非CLI命名空间）。 Resilience Hub v2支持两种互补的多账户机制：(1) AWS Organizations集成——管理账户启用可信访问、创建服务关联角色，并指定一个委托管理员**账户用于组织级策略管理和可见性；(2) 按服务划分的跨账户权限模型——中央账户中的调用者角色承担成员账户中的跨账户角色，以实现按服务的资源发现。本技能配置的是(2)；Organizations集成(1)需单独设置（通过管理账户+控制台——详见下文）。

推荐使用AWS MCP服务器执行本技能的AWS API调用，但并非强制要求——所有操作也可直接通过AWS CLI完成。

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

防护规则——本技能自身文件的存储位置（MCP vs 本地安装）

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

读取参考文件前，请确定本技能的加载方式：

通过AWS MCP
retrieve_skill
工具加载：技能的参考文件不在本地文件系统中。需通过
```
retrieve_skill
```
工具并指定
```
file
```
参数获取（例如
```
file="references/multi-account-procedure.md"
```
）——请勿在本地使用
```
file_read
```
读取这些路径，也不要在文件系统中搜索它们。
本地安装（例如
```
.kiro/skills/resilience-hub-multi-account/
```
或
```
~/.claude/skills/resilience-hub-multi-account/
```
）：使用此处所示的相对路径从本地技能目录读取参考文件。

此规则仅适用于技能自身的参考文件；用户或会话数据始终在工作目录中读写，切勿通过

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.

根据目标不同，有两种实现路径：

决策规则（请先阅读）：若要运行跨账户弹性评估——即从中央账户评估成员账户中的工作负载/资源（常见需求，例如“跨组织的集中式弹性管理”或“中央评估账户”）——请使用按服务划分的跨账户权限模型（下文路径2）：调用者角色+跨账户角色+
create-service --permission-model
。请勿将
aws organizations register-delegated-administrator
（或任何委托管理员注册）作为跨账户评估的设置步骤。Organizations委托管理员集成（路径1）是一个独立的可选功能，仅适用于组织级策略管理和可见性——并非用于设置或运行跨账户评估。仅当需求明确涉及组织级策略治理而非评估时，才遵循路径1。

组织级治理（集中式策略、跨账户可见性）：使用AWS Organizations集成。从管理账户启用Resilience Hub的可信访问、创建服务关联角色，并注册委托管理员账户。此操作通过Organizations可信访问+Resilience Hub控制台完成——不存在
resiliencehubv2
的
register-delegated-administrator
CLI操作。委托管理员随后选择一个聚合组织级数据的主区域。请参阅AWS文档页面设置Organizations集成。
按服务划分的跨账户资源发现（评估资源跨多个账户的服务）：为每个服务注册按服务划分的跨账户权限模型——中央账户中的调用者角色加上每个成员账户的跨账户角色ARN。本技能的步骤将配置此路径。使用以下命令格式：

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}"}]}'

externalId
是用于防御混淆代理攻击的共享密钥——生成一个加密随机值并存储在AWS Secrets Manager或SSM Parameter Store（SecureString）中；切勿将其提交到源代码控制，也不要在模板中嵌入静态值，需使用动态
{{resolve:secretsmanager:...}}
引用，并确保CI/CD日志或基础设施即代码输出中不会明文显示该值（使用CloudFormation
NoEcho
参数并在流水线日志中屏蔽）。

成员账户中的跨账户角色信任中央账户的调用者角色。您可为每个服务配置多个跨账户角色ARN——

resiliencehubv2

API会限制最大数量（示例为5），因此请从API/模型中确认可接受的限制，不要假设固定数值。注意：此按服务划分的模型独立于上述Organizations集成——

resiliencehubv2

CLI中不存在

register-delegated-administrator

操作；组织级委托管理员注册需通过AWS Organizations可信访问和Resilience Hub控制台完成，而非

resiliencehubv2

API调用。

Configure multi-account setup

配置多账户设置

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

要设置跨账户评估，请严格遵循以下流程。请参阅references/multi-account-procedure.md。

Troubleshooting

故障排除

Cross-account assessment fails with AccessDenied

跨账户评估失败并显示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.

请验证：(1) 权限模型中的跨账户角色ARN完全匹配；(2) 跨账户角色的信任策略允许中央账户的调用者角色承担该角色；(3) 若配置了externalId，则其值完全匹配。

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.

请确认跨账户角色对相关资源类型（CloudFormation、EC2、RDS等）具有只读权限，且输入源指向正确区域中的有效资源。

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.

Resilience Hub v2 确实支持与AWS Organizations集成的委托管理员功能，用于组织级策略管理和可见性——但需从管理账户通过Organizations可信访问+Resilience Hub控制台配置（创建服务关联角色，然后注册委托管理员），并非通过

resiliencehubv2

CLI操作（不存在

register-delegated-administrator

API）。若要评估资源跨多个账户的单个服务，请使用本技能中的按服务划分的跨账户权限模型。两者是互补关系。

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.

最小权限与只读原则：将成员账户的跨账户角色权限限定为只读发现权限（
```
cloudformation:Describe*
```
、
```
ec2:Describe*
```
、
```
rds:Describe*
```
等），而非写入/修改操作。
缩小跨账户信任范围：尽可能仅信任特定的中央调用者角色ARN，而非整个账户。
启用日志与监控：确保中央账户和成员账户均启用AWS CloudTrail，以记录跨账户
```
sts:AssumeRole
```
调用，并针对跨账户角色的失败或意外AssumeRole尝试设置告警。
扩展阅读：请参阅IAM最佳实践、混淆代理问题和AWS Resilience Hub中的安全，获取跨账户安全强化指南。