aws-resilience-lifecycle

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

AWS Resilience Lifecycle

AWS弹性生命周期

Overview

概述

Domain expertise for the integrated resilience lifecycle across three AWS services: Define (Resilience Hub v2 — also called NGRH, New Generation Resilience Hub) → Test (FIS) → Operate (ARC).

Terminology: in this skill an unqualified "Resilience Hub" always means v2 (NGRH / New Generation Resilience Hub, CLI namespace

aws resiliencehubv2

). v1 (

aws resiliencehub

) is referenced only explicitly, and only for migration.

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.

本技能提供跨三项AWS服务的集成弹性生命周期领域专业知识：Define（Resilience Hub v2 — 也称为NGRH，新一代弹性中心）→ Test（FIS）→ Operate（ARC）。

术语说明： 在本技能中，未加限定的“Resilience Hub”始终指v2版本（NGRH/新一代弹性中心，CLI命名空间

aws resiliencehubv2

）。仅在明确提及迁移场景时才会引用v1版本（

aws resiliencehub

）。

推荐使用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/lifecycle-workflow.md"
```
or
```
file="references/api-reference.md"
```
) — do NOT
```
file_read
```
these paths locally or search the filesystem for them.
Installed locally (e.g.
```
.kiro/skills/aws-resilience-lifecycle/
```
or
```
~/.claude/skills/aws-resilience-lifecycle/
```
): 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/lifecycle-workflow.md"
```
或
```
file="references/api-reference.md"
```
）—— 请勿使用
```
file_read
```
读取本地路径或在文件系统中搜索这些文件。
本地安装（例如
```
.kiro/skills/aws-resilience-lifecycle/
```
或
```
~/.claude/skills/aws-resilience-lifecycle/
```
）：使用此处显示的相对路径从本地技能目录读取参考文件。

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

retrieve_skill

操作。

Execute the full lifecycle

执行完整生命周期

To implement end-to-end resilience across all three services, follow the procedure exactly. See references/lifecycle-workflow.md.

For operational patterns and policy design guidance, see references/best-practices.md.

要在三项服务中实现端到端弹性，请严格遵循以下流程。详情请参阅references/lifecycle-workflow.md。

有关操作模式和策略设计指南，请参阅references/best-practices.md。

Validate findings before you resolve them

在解决发现结果前进行验证

Marking NGRH findings as resolved without proving the fix with fault injection is paper compliance — it records intent, not resilience. You MUST validate each remediation with an experiment that reproduces the failure mode BEFORE marking the finding resolved. Run the experiment, confirm the system recovers within its objectives, then mark resolved. Marking resolved first and validating "later" is the anti-pattern.

未通过故障注入验证修复效果就将NGRH发现标记为已解决属于纸面合规——仅记录了修复意图，而非实际弹性能力。在标记发现为已解决之前，您必须通过能复现故障模式的实验来验证每项修复措施。运行实验，确认系统在目标范围内恢复，然后再标记为已解决。先标记解决再“稍后”验证是反模式。

Monitoring & observability

监控与可观测性

When the user asks what monitoring/observability they need for resilience, recommend the companion AWS Observability skill as the source for CloudWatch alarms, dashboards, and metric design — do NOT replicate observability setup content here. Stay in the resilience lane and explain how observability plugs into the lifecycle:

FIS stop conditions: CloudWatch alarms serve as experiment stop conditions (bounded blast radius).
Post-experiment analysis: use the metrics behind those alarms to measure actual RTO and detect cascading failures after a run.

Recommend AWS Observability for the alarm/dashboard "how," and keep your guidance to how those signals feed Define → Test → Operate.

当用户询问弹性所需的监控/可观测性方案时，推荐配套的AWS Observability技能作为CloudWatch告警、仪表板和指标设计的来源——请勿在此处重复可观测性设置内容。专注于弹性领域，并解释可观测性如何融入生命周期：

FIS停止条件： CloudWatch告警可作为实验停止条件（限定影响范围）。
实验后分析： 使用告警背后的指标来衡量实际RTO，并检测运行后的级联故障。

建议通过AWS Observability技能获取告警/仪表板的“实现方法”，此处仅指导这些信号如何为Define → Test → Operate流程提供支持。

API Reference (READ FIRST before producing any AWS CLI command)

API参考（生成AWS CLI命令前请先阅读）

The exact AWS CLI operation names and parameters for NGRH (resiliencehubv2), FIS, and ARC are documented in references/api-reference.md. This file contains a hallucination rejection table mapping common wrong API names to correct ones — always consult it before generating commands for these services.

NGRH（resiliencehubv2）、FIS和ARC的具体AWS CLI操作名称及参数记录在references/api-reference.md中。该文件包含一个幻觉修正表，将常见错误API名称映射为正确名称——生成这些服务的命令前务必查阅此文件。

Troubleshooting

故障排除

Don't know where to start

不知从何入手

Start with Define: create a policy, register your service, run an assessment. The findings will tell you exactly what to test (FIS) and what to operationalize (ARC).

从Define阶段开始：创建策略、注册服务、运行评估。发现结果会明确告知您需要测试的内容（FIS）和需要落地的操作控制（ARC）。

Findings resolved but no confidence in resilience

已解决发现结果但对弹性缺乏信心

Resolving findings without FIS validation is paper compliance. Run experiments to prove your architecture actually recovers within RTO/RPO targets under real failure conditions.

未经过FIS验证就解决发现结果属于纸面合规。请运行实验，证明您的架构在真实故障条件下确实能在RTO/RPO目标范围内恢复。

FIS experiments pass but production still fails

FIS实验通过但生产环境仍出现故障

Experiments may not match real failure modes. Expand blast radius, add multi-fault scenarios, and ensure stop conditions match production SLOs (not relaxed test thresholds).

实验可能未匹配真实故障模式。扩大影响范围、添加多故障场景，并确保停止条件与生产SLO匹配（而非宽松的测试阈值）。

Security Considerations

安全注意事项

Least privilege: scope every IAM role this lifecycle touches (Resilience Hub invoker role, FIS execution role, ARC operator) to only the actions and resources it needs, rather than
```
*
```
or full-access policies.
Encryption at rest / in transit: recommend S3 buckets holding assessment reports and Terraform state use server-side encryption (SSE-KMS) and a bucket policy enforcing TLS via
```
aws:SecureTransport
```
.
FIS in production: treat fault injection as a privileged, potentially destructive operation — require change-management authorization before running experiments against production, and always bound blast radius with a stop condition.
Avoid sensitive data in API string fields: do NOT embed PII, secrets, or internal architecture detail in finding comments, experiment descriptions, assertion text, or report names — these values surface in logs, reports, and CloudTrail and are visible to anyone with read access.
Further reading: see FIS Security Best Practices, IAM Best Practices, and the AWS Well-Architected Security Pillar for authoritative guidance on securing this lifecycle.

最小权限原则： 为生命周期涉及的每个IAM角色（Resilience Hub调用角色、FIS执行角色、ARC操作员）限定仅所需的操作和资源权限，避免使用
```
*
```
或全访问策略。
静态/传输加密： 建议存储评估报告和Terraform状态的S3存储桶使用服务器端加密（SSE-KMS），并通过存储桶策略强制要求TLS（
```
aws:SecureTransport
```
）。
生产环境中的FIS： 将故障注入视为具有特权且可能造成破坏的操作——在生产环境运行实验前需获得变更管理授权，并始终通过停止条件限定影响范围。
API字符串字段中避免敏感数据：请勿在发现结果注释、实验描述、断言文本或报告名称中嵌入PII、密钥或内部架构细节——这些值会出现在日志、报告和CloudTrail中，任何具有读取权限的用户都能看到。
扩展阅读： 有关保护此生命周期的权威指南，请参阅FIS安全最佳实践、IAM最佳实践和AWS架构完善框架安全支柱。