AWS Resilience Modeling Skill

Language / 语言

• If the user speaks English, follow SKILL_EN.md
• 如果用户使用中文，请遵循 SKILL_ZH.md

Detect the language from the user's message and load the corresponding instruction file.

AWS 系统韧性分析报告

[客户名称] - [环境名称]

分析日期：2025-02-17 分析师：Claude (AWS Resilience Assessment Skill) 版本：1.0

执行摘要

概述

本报告对 [客户名称] 的 AWS 生产环境进行了全面的韧性评估，识别了潜在的故障模式，并提供了优先级排序的改进建议。

当前韧性成熟度

总体评分：⭐⭐⭐ (3/5 - 已定义)

关键发现（Top 5 风险）

优先改进建议（Top 3）

1. 迁移到 Aurora Global Database

• 预期效果：RTO < 1 分钟，RPO < 1 秒
• 实施周期：3-4 周
• 预估成本：+$500-2000/月

2. 实施 Auto Scaling 策略

• 预期效果：自动应对 3x 流量突增
• 实施周期：1-2 周
• 预估成本：变动成本（按需）

3. 建立混沌工程实践

• 预期效果：每季度验证韧性，提前发现问题
• 实施周期：持续
• 预估成本：$100-300/月

预期投资和回报

ROI 分析：

• 当前估计年度中断损失：$100,000
• 实施后预期减少：$70,000/年
• 投资回收期：6 个月

1. 系统架构可视化

1.1 当前架构总览

graph TB
    subgraph "AWS Region: us-east-1"
        subgraph "VPC: 10.0.0.0/16"
            subgraph "Public Subnet - AZ-1a"
                ALB1[Application Load Balancer]
                NAT1[NAT Gateway]
            end

            subgraph "Public Subnet - AZ-1b"
                ALB2[ALB - Standby]
            end

            subgraph "Private Subnet - AZ-1a"
                EC2_1a_1[EC2 Instance]
                EC2_1a_2[EC2 Instance]
            end

            subgraph "Private Subnet - AZ-1b"
                EC2_1b_1[EC2 Instance]
                EC2_1b_2[EC2 Instance]
            end

            subgraph "Data Subnet - AZ-1a"
                RDS_Primary[RDS Primary<br/>PostgreSQL]
                Redis_1a[ElastiCache<br/>Redis]
            end

            subgraph "Data Subnet - AZ-1b"
                RDS_Standby[RDS Standby]
                Redis_1b[ElastiCache<br/>Redis]
            end
        end
    end

    Internet[Internet] -->|HTTPS| R53[Route 53]
    R53 -->|Health Check| ALB1
    ALB1 --> EC2_1a_1
    ALB1 --> EC2_1a_2
    ALB1 --> EC2_1b_1
    ALB1 --> EC2_1b_2

    EC2_1a_1 --> RDS_Primary
    EC2_1a_2 --> RDS_Primary
    EC2_1b_1 --> RDS_Primary
    EC2_1b_2 --> RDS_Primary

    EC2_1a_1 --> Redis_1a
    EC2_1a_2 --> Redis_1a
    EC2_1b_1 --> Redis_1b
    EC2_1b_2 --> Redis_1b

    RDS_Primary -.->|Sync Replication| RDS_Standby

    EC2_1a_1 -->|Egress| NAT1
    EC2_1a_2 -->|Egress| NAT1

    classDef spof fill:#ff6b6b,stroke:#c92a2a,stroke-width:3px
    class NAT1,RDS_Primary spof

🚨 识别的单点故障：

• NAT Gateway（仅 AZ-1a）
• RDS Primary（故障转移需 60-120 秒）

1.2 组件依赖关系图

graph LR
    User[用户请求] --> R53[Route 53]
    R53 --> ALB[Application LB]
    ALB --> App[应用服务器]
    App --> Cache[ElastiCache]
    App --> RDS[RDS 数据库]
    App --> S3[S3 存储]

    App -.->|异步| SQS[SQS 队列]
    SQS -.->|异步| Worker[Worker 服务]

    classDef critical fill:#ff6b6b
    classDef important fill:#ffd93d
    classDef optional fill:#6bcf7f

    class RDS,App critical
    class Cache,ALB important
    class S3,SQS optional

依赖关系说明：

• 🔴 关键依赖（同步）：RDS、应用服务器
• 🟡 重要依赖（同步）：ElastiCache、ALB
• 🟢 可选依赖（异步）：S3、SQS

1.3 数据流图

sequenceDiagram
    participant User as 用户
    participant CF as CloudFront
    participant ALB as Application LB
    participant App as 应用服务器
    participant Cache as ElastiCache
    participant DB as RDS

    User->>CF: 1. HTTPS 请求
    CF->>ALB: 2. 转发（或缓存命中）
    ALB->>App: 3. 负载均衡
    App->>Cache: 4. 检查缓存
    alt 缓存命中
        Cache-->>App: 5a. 返回缓存数据
    else 缓存未命中
        App->>DB: 5b. 查询数据库
        DB-->>App: 6. 返回数据
        App->>Cache: 7. 更新缓存
    end
    App-->>ALB: 8. 返回响应
    ALB-->>CF: 9. 返回响应
    CF-->>User: 10. 返回（并缓存）

1.4 网络拓扑图

graph TB
    subgraph "VPC: prod-vpc (10.0.0.0/16)"
        subgraph "AZ-1a"
            PubSub1a[Public Subnet<br/>10.0.1.0/24]
            PrivSub1a[Private Subnet<br/>10.0.11.0/24]
            DataSub1a[Data Subnet<br/>10.0.21.0/24]
        end

        subgraph "AZ-1b"
            PubSub1b[Public Subnet<br/>10.0.2.0/24]
            PrivSub1b[Private Subnet<br/>10.0.12.0/24]
            DataSub1b[Data Subnet<br/>10.0.22.0/24]
        end

        IGW[Internet Gateway]
        NAT1[NAT Gateway<br/>AZ-1a]

        RouteTablePub[Public Route Table<br/>0.0.0.0/0 → IGW]
        RouteTablePriv[Private Route Table<br/>0.0.0.0/0 → NAT]

        SGWeb[Security Group: Web<br/>Allow 443 from 0.0.0.0/0]
        SGApp[Security Group: App<br/>Allow 8080 from Web SG]
        SGDB[Security Group: DB<br/>Allow 5432 from App SG]
    end

    Internet[Internet] --> IGW
    IGW --> PubSub1a
    IGW --> PubSub1b

    PubSub1a --> RouteTablePub
    PubSub1b --> RouteTablePub

    PrivSub1a --> RouteTablePriv
    PrivSub1b --> RouteTablePriv

    PrivSub1a --> NAT1
    PrivSub1b --> NAT1

    classDef spof fill:#ff6b6b
    class NAT1 spof

网络分析：

• ✅ 多 AZ 部署（1a、1b）
• ✅ 分层子网（Public、Private、Data）
• ✅ 安全组遵循最小权限原则
• 🚨 NAT Gateway 单 AZ（单点故障）
• ⚠️ 缺少 VPC Flow Logs（可观测性不足）

2. 故障模式识别与分类

📋 以下风险识别基于AWS总结的常见风险检查清单，结合客户实际环境进行评估。

2.1 单点故障 (SPOF)

详细分析：R-003 - API Gateway 单区域部署

当前配置：

Region: us-east-1
Endpoints:
  - API Gateway: https://api.example.com
  - 无跨区域复制
  - 无故障转移机制

故障场景：

• us-east-1 区域级故障（历史案例：2017 年 S3 中断）
• API Gateway 服务中断

影响：

• 所有 API 请求失败
• 100% 用户无法使用服务
• 业务完全中断

当前缓解措施：

• ❌ 无

建议改进： 参见 6.1 缓解策略 - R-003

2.2 过度延迟

2.3 过度负载

2.4 错误配置

2.5 共享命运 (Shared Fate)

3. 韧性评估（5 星评分）

3.1 RDS 数据库

综合评分：⭐⭐⭐ (3/5)

3.2 应用服务器 (EC2 / ECS)

综合评分：⭐⭐⭐ (3.2/5)

3.3 汇总评分

总体韧性评分：⭐⭐⭐ (3/5 - 已定义)

成熟度模型：
├─ Level 1: 初始（被动响应）
├─ Level 2: 可重复（有记录流程）
├─ Level 3: 已定义（标准化流程）✅ 当前
├─ Level 4: 管理（量化管理）    ← 目标
└─ Level 5: 优化（持续改进）

4. 业务影响分析

4.1 关键业务功能映射

4.2 组件故障影响矩阵

4.3 RTO/RPO 合规性分析

当前架构 vs 业务目标：

业务功能：订单处理
├─ 业务目标：RTO < 2 分钟，RPO = 0 秒
├─ 当前能力：RTO ~ 5 分钟，RPO ~ 5 分钟
└─ 差距：❌ 不符合

原因分析：
1. RDS Multi-AZ 故障转移需要 60-120 秒
2. 应用重连数据库需要 30-60 秒
3. 健康检查检测延迟 30 秒
4. RPO 取决于 RDS 备份频率（5 分钟）

改进建议：
1. 迁移到 Aurora（故障转移 < 30 秒）
2. 应用实现快速重连（连接池）
3. 减少健康检查间隔（15 秒）
4. 启用 Aurora Backtrack（RPO = 0）

合规性总结：

结论：当前架构无法满足任何业务功能的 RTO/RPO 目标，需要紧急改进。

5. 风险优先级排序

5.1 风险评分矩阵

评分公式：

风险得分 = (发生概率 × 业务影响 × 检测难度) / 修复复杂度

其中：
- 发生概率：1-5（1=极低，5=极高）
- 业务影响：1-5（1=轻微，5=严重）
- 检测难度：1-5（1=易检测，5=难检测）
- 修复复杂度：1-5（1=简单，5=复杂）

5.2 风险清单（按优先级排序）

5.3 风险可视化矩阵

影响 ↑
5 │     [R-013]           [R-003]
4 │  [R-006] [R-007]
3 │        [R-004]    [R-001]
  │                   [R-014]
2 │ [R-009]
1 │
  └─────────────────────────────→ 概率
    1    2    3    4    5

图例：
🔴 高优先级（风险得分 > 5）
🟡 中优先级（风险得分 2-5）
🟢 低优先级（风险得分 < 2）

5.4 级联效应分析

场景：us-east-1 区域故障

graph TD
    A[us-east-1 区域故障] --> B[API Gateway 不可用]
    A --> C[RDS Primary 不可用]
    A --> D[ElastiCache 不可用]
    A --> E[NAT Gateway 不可用]

    B --> F[100% API 请求失败]
    C --> G[所有写操作失败]
    D --> H[缓存未命中，数据库负载增加]
    E --> I[无法调用第三方 API]

    F --> J[完全业务中断]
    G --> J
    H --> J
    I --> J

    J --> K[预估损失：$50,000/小时]

    classDef critical fill:#ff6b6b
    class A,J,K critical

结论：

• 单区域架构存在严重的级联故障风险
• 区域故障导致完全业务中断
• 建议：实施多区域 DR 策略（至少导航灯模式）

（报告后续部分包括：缓解策略建议、实施路线图、持续改进计划、附录等，格式类似）

说明

这是一个示例模板，展示了最终报告的格式和内容。实际分析时会根据你的具体环境和需求进行定制。

报告的其他部分（6-9 节）将包含：

• 详细的缓解策略（含架构图、代码、命令）
• 分阶段实施路线图（Gantt 图、资源需求）
• 持续改进计划（SLO/SLI、事后复盘、混沌工程）
• 附录（完整资源清单、配置审计、术语表）

完整报告通常为 30-50 页，包含大量可视化图表和可执行的代码示例。

AWS System Resilience Analysis Report

[Customer Name] - [Environment Name]

Analysis Date: 2025-02-17 Analyst: Claude (AWS Resilience Assessment Skill) Version: 1.0

Executive Summary

Overview

This report provides a comprehensive resilience assessment of [Customer Name]'s AWS production environment, identifying potential failure modes and providing prioritized improvement recommendations.

Current Resilience Maturity

Overall Score: 3/5 - Defined

Key Findings (Top 5 Risks)

Priority Improvement Recommendations (Top 3)

1. Migrate to Aurora Global Database

• Expected Outcome: RTO < 1 minute, RPO < 1 second
• Implementation Timeline: 3-4 weeks
• Estimated Cost: +$500-2000/month

2. Implement Auto Scaling Strategy

• Expected Outcome: Automatically handle 3x traffic spikes
• Implementation Timeline: 1-2 weeks
• Estimated Cost: Variable (on-demand)

3. Establish Chaos Engineering Practice

• Expected Outcome: Quarterly resilience verification, proactive issue discovery
• Implementation Timeline: Ongoing
• Estimated Cost: $100-300/month

Expected Investment and Return

ROI Analysis:

• Estimated annual outage losses: $100,000
• Expected reduction after implementation: $70,000/year
• Payback period: 6 months

1. System Architecture Visualization

1.1 Current Architecture Overview

graph TB
    subgraph "AWS Region: us-east-1"
        subgraph "VPC: 10.0.0.0/16"
            subgraph "Public Subnet - AZ-1a"
                ALB1[Application Load Balancer]
                NAT1[NAT Gateway]
            end

            subgraph "Public Subnet - AZ-1b"
                ALB2[ALB - Standby]
            end

            subgraph "Private Subnet - AZ-1a"
                EC2_1a_1[EC2 Instance]
                EC2_1a_2[EC2 Instance]
            end

            subgraph "Private Subnet - AZ-1b"
                EC2_1b_1[EC2 Instance]
                EC2_1b_2[EC2 Instance]
            end

            subgraph "Data Subnet - AZ-1a"
                RDS_Primary[RDS Primary<br/>PostgreSQL]
                Redis_1a[ElastiCache<br/>Redis]
            end

            subgraph "Data Subnet - AZ-1b"
                RDS_Standby[RDS Standby]
                Redis_1b[ElastiCache<br/>Redis]
            end
        end
    end

    Internet[Internet] -->|HTTPS| R53[Route 53]
    R53 -->|Health Check| ALB1
    ALB1 --> EC2_1a_1
    ALB1 --> EC2_1a_2
    ALB1 --> EC2_1b_1
    ALB1 --> EC2_1b_2

    EC2_1a_1 --> RDS_Primary
    EC2_1a_2 --> RDS_Primary
    EC2_1b_1 --> RDS_Primary
    EC2_1b_2 --> RDS_Primary

    EC2_1a_1 --> Redis_1a
    EC2_1a_2 --> Redis_1a
    EC2_1b_1 --> Redis_1b
    EC2_1b_2 --> Redis_1b

    RDS_Primary -.->|Sync Replication| RDS_Standby

    EC2_1a_1 -->|Egress| NAT1
    EC2_1a_2 -->|Egress| NAT1

    classDef spof fill:#ff6b6b,stroke:#c92a2a,stroke-width:3px
    class NAT1,RDS_Primary spof

Identified Single Points of Failure:

• NAT Gateway (AZ-1a only)
• RDS Primary (failover requires 60-120 seconds)

1.2 Component Dependency Diagram

graph LR
    User[User Request] --> R53[Route 53]
    R53 --> ALB[Application LB]
    ALB --> App[Application Servers]
    App --> Cache[ElastiCache]
    App --> RDS[RDS Database]
    App --> S3[S3 Storage]

    App -.->|Async| SQS[SQS Queue]
    SQS -.->|Async| Worker[Worker Service]

    classDef critical fill:#ff6b6b
    classDef important fill:#ffd93d
    classDef optional fill:#6bcf7f

    class RDS,App critical
    class Cache,ALB important
    class S3,SQS optional

Dependency Description:

• Critical dependencies (synchronous): RDS, Application Servers
• Important dependencies (synchronous): ElastiCache, ALB
• Optional dependencies (asynchronous): S3, SQS

1.3 Data Flow Diagram

sequenceDiagram
    participant User as User
    participant CF as CloudFront
    participant ALB as Application LB
    participant App as Application Server
    participant Cache as ElastiCache
    participant DB as RDS

    User->>CF: 1. HTTPS Request
    CF->>ALB: 2. Forward (or cache hit)
    ALB->>App: 3. Load Balance
    App->>Cache: 4. Check Cache
    alt Cache Hit
        Cache-->>App: 5a. Return Cached Data
    else Cache Miss
        App->>DB: 5b. Query Database
        DB-->>App: 6. Return Data
        App->>Cache: 7. Update Cache
    end
    App-->>ALB: 8. Return Response
    ALB-->>CF: 9. Return Response
    CF-->>User: 10. Return (and Cache)

1.4 Network Topology Diagram

graph TB
    subgraph "VPC: prod-vpc (10.0.0.0/16)"
        subgraph "AZ-1a"
            PubSub1a[Public Subnet<br/>10.0.1.0/24]
            PrivSub1a[Private Subnet<br/>10.0.11.0/24]
            DataSub1a[Data Subnet<br/>10.0.21.0/24]
        end

        subgraph "AZ-1b"
            PubSub1b[Public Subnet<br/>10.0.2.0/24]
            PrivSub1b[Private Subnet<br/>10.0.12.0/24]
            DataSub1b[Data Subnet<br/>10.0.22.0/24]
        end

        IGW[Internet Gateway]
        NAT1[NAT Gateway<br/>AZ-1a]

        RouteTablePub[Public Route Table<br/>0.0.0.0/0 -> IGW]
        RouteTablePriv[Private Route Table<br/>0.0.0.0/0 -> NAT]

        SGWeb[Security Group: Web<br/>Allow 443 from 0.0.0.0/0]
        SGApp[Security Group: App<br/>Allow 8080 from Web SG]
        SGDB[Security Group: DB<br/>Allow 5432 from App SG]
    end

    Internet[Internet] --> IGW
    IGW --> PubSub1a
    IGW --> PubSub1b

    PubSub1a --> RouteTablePub
    PubSub1b --> RouteTablePub

    PrivSub1a --> RouteTablePriv
    PrivSub1b --> RouteTablePriv

    PrivSub1a --> NAT1
    PrivSub1b --> NAT1

    classDef spof fill:#ff6b6b
    class NAT1 spof

Network Analysis:

• Multi-AZ deployment (1a, 1b)
• Layered subnets (Public, Private, Data)
• Security groups follow least privilege principle
• NAT Gateway single AZ (single point of failure)
• Missing VPC Flow Logs (insufficient observability)

2. Failure Mode Identification and Classification

The following risk identification is based on AWS common risk checklists, assessed against the customer's actual environment.

2.1 Single Point of Failure (SPOF)

Detailed Analysis: R-003 - API Gateway Single-Region Deployment

Current Configuration:

Region: us-east-1
Endpoints:
  - API Gateway: https://api.example.com
  - No cross-region replication
  - No failover mechanism

Failure Scenario:

• us-east-1 regional failure (historical case: 2017 S3 outage)
• API Gateway service disruption

Impact:

• All API requests fail
• 100% of users unable to use the service
• Complete business interruption

Current Mitigations:

• None

Recommended Improvements: See 6.1 Mitigation Strategy - R-003

2.2 Excessive Latency

2.3 Excessive Load

2.4 Misconfiguration

2.5 Shared Fate

3. Resilience Assessment (5-Star Rating)

3.1 RDS Database

Composite Score: 3/5

3.2 Application Servers (EC2 / ECS)

Composite Score: 3.2/5

3.3 Summary Scores

Overall Resilience Score: 3/5 - Defined

Maturity Model:
+- Level 1: Initial (reactive response)
+- Level 2: Repeatable (documented processes)
+- Level 3: Defined (standardized processes)  <- Current
+- Level 4: Managed (quantitatively managed)  <- Target
+- Level 5: Optimized (continuous improvement)

4. Business Impact Analysis

4.1 Critical Business Function Mapping

4.2 Component Failure Impact Matrix

4.3 RTO/RPO Compliance Analysis

Current Architecture vs. Business Targets:

Business Function: Order Processing
+- Business Target: RTO < 2 min, RPO = 0 sec
+- Current Capability: RTO ~ 5 min, RPO ~ 5 min
+- Gap: Does not comply

Root Cause Analysis:
1. RDS Multi-AZ failover requires 60-120 seconds
2. Application database reconnection requires 30-60 seconds
3. Health check detection delay 30 seconds
4. RPO depends on RDS backup frequency (5 minutes)

Improvement Recommendations:
1. Migrate to Aurora (failover < 30 seconds)
2. Implement fast reconnection at application layer (connection pooling)
3. Reduce health check interval (15 seconds)
4. Enable Aurora Backtrack (RPO = 0)

Compliance Summary:

Conclusion: The current architecture cannot meet the RTO/RPO targets for any business function and requires urgent improvement.

5. Risk Prioritization

5.1 Risk Scoring Matrix

Scoring Formula:

Risk Score = (Probability x Business Impact x Detection Difficulty) / Remediation Complexity

Where:
- Probability: 1-5 (1=very low, 5=very high)
- Business Impact: 1-5 (1=minor, 5=critical)
- Detection Difficulty: 1-5 (1=easy to detect, 5=hard to detect)
- Remediation Complexity: 1-5 (1=simple, 5=complex)

5.2 Risk Inventory (Sorted by Priority)

5.3 Risk Visualization Matrix

Impact
5 |     [R-013]           [R-003]
4 |  [R-006] [R-007]
3 |        [R-004]    [R-001]
  |                   [R-014]
2 | [R-009]
1 |
  +--------------------------------> Probability
    1    2    3    4    5

Legend:
  High priority (risk score > 5)
  Medium priority (risk score 2-5)
  Low priority (risk score < 2)

5.4 Cascading Effect Analysis

Scenario: us-east-1 Regional Failure

graph TD
    A[us-east-1 Regional Failure] --> B[API Gateway Unavailable]
    A --> C[RDS Primary Unavailable]
    A --> D[ElastiCache Unavailable]
    A --> E[NAT Gateway Unavailable]

    B --> F[100% API Requests Fail]
    C --> G[All Write Operations Fail]
    D --> H[Cache Misses, Database Load Increases]
    E --> I[Cannot Call Third-Party APIs]

    F --> J[Complete Business Outage]
    G --> J
    H --> J
    I --> J

    J --> K[Estimated Loss: $50,000/hour]

    classDef critical fill:#ff6b6b
    class A,J,K critical

Conclusion:

• Single-region architecture has serious cascading failure risks
• Regional failure leads to complete business outage
• Recommendation: Implement multi-region DR strategy (at minimum Pilot Light)

(Subsequent report sections include: Mitigation Strategy Recommendations, Implementation Roadmap, Continuous Improvement Plan, Appendices, etc., in similar format)

Notes

This is a sample template demonstrating the format and content of the final report. The actual analysis will be customized based on your specific environment and requirements.

The remaining sections (6-9) of the report will include:

• Detailed mitigation strategies (with architecture diagrams, code, commands)
• Phased implementation roadmap (Gantt chart, resource requirements)
• Continuous improvement plan (SLO/SLI, postmortems, chaos engineering)
• Appendices (complete resource inventory, configuration audit, glossary)

A complete report typically spans 30-50 pages, with extensive visualizations and executable code examples.

English | 中文

AWS 系统韧性分析 Skill

这是一个全面的 AWS 系统韧性评估和风险分析 skill，整合了 2025 年最新的业界最佳实践。

安装

方式 A：npx skills（推荐）

# Install this skill
npx skills add aws-samples/sample-aws-resilience-skill --skill aws-resilience-modeling

# Install all 4 resilience skills
npx skills add aws-samples/sample-aws-resilience-skill --skill '*'

方式 B：Git clone

git clone https://github.com/aws-samples/sample-aws-resilience-skill.git

特性

• ✅ 基于 AWS Well-Architected Framework 可靠性支柱
• ✅ 整合 AWS 韧性分析框架（错误预算、SLO/SLI）
• ✅ 包含 混沌工程 方法论（AWS FIS）
• ✅ 采用 AWS 可观测性最佳实践（CloudWatch、X-Ray、分布式追踪）
• ✅ 应用 云设计模式（Circuit Breaker、Bulkhead、Retry）
• ✅ 内置 AWS 常见服务风险参考库（50+ 个风险点，覆盖存储/数据库/EKS/EC2/网络）

使用方式

方式 1：直接调用

/aws-resilience-modeling

Claude 会首先询问你的环境信息和业务背景，然后开始进行全面的韧性分析。

方式 2：自动触发

当你在对话中提到以下关键词时，skill 会自动激活：

• "AWS 韧性分析"
• "系统风险评估"
• "AWS 韧性评估"
• "AWS resilience assessment"

示例：

用户: 我想对我们的 AWS 生产环境进行韧性分析
Claude: [自动加载 aws-resilience-modeling skill]

准备工作

在开始分析前，请准备以下信息：

MCP 服务器配置

自动扫描 AWS 环境所需的 MCP 服务器详细配置指南，参见 references/MCP_SETUP_GUIDE_zh.md。

1. 环境信息

• AWS 账户 ID 和区域
• 访问权限（建议只读访问）
• 现有架构文档（如有）

2. 业务背景

• 关键业务流程清单
• 当前的 RTO/RPO 目标
• 现有的 SLA/SLO（如有）
• 合规要求（如 SOC2、HIPAA、PCI DSS）

3. 分析范围

• 需要分析的应用和服务
• 是否包含多账户/多区域
• 预算和时间约束

输出内容

分析完成后，你将获得：

主报告

1. 执行摘要（2 页）

• 关键发现（Top 5 风险）
• 韧性成熟度评分
• 优先改进建议

2. 系统架构可视化

• 架构总览图（Mermaid）
• 依赖关系图
• 数据流图
• 网络拓扑图

3. 风险清单（表格）

• 按优先级排序
• 包含风险评分、影响、缓解建议

4. 详细风险分析

• 每个高优先级风险的深入分析
• 故障场景
• 业务影响
• 改进建议（架构、配置、监控）

5. 业务影响分析

• 关键业务功能映射
• RTO/RPO 合规性分析

6. 缓解策略建议

• 具体的架构改进
• 配置优化（含参数和命令）
• 监控和告警配置
• AWS 服务推荐

7. 实施路线图

• Gantt 图
• 详细任务分解
• 资源需求和预算

8. 持续改进计划

• SLI/SLO 定义
• 事后复盘流程
• 混沌工程计划

附加文件

references/common-risks-reference_zh.md - AWS 常见服务风险参考手册（English）

• 覆盖存储（EBS/S3/EFS/FSx）、数据库、容器（EKS）、计算（EC2）、网络五大类
• 50+ 个常见风险点，每个包含风险原因和改进建议
• 评估检查清单，按服务类型逐项确认

references/assessment-output-spec_zh.md - 混沌工程输入规范（English）

• 定义 chaos-engineering-on-aws skill 所需的结构化输入格式
• 包含 AWS 资源清单、风险可实验性标记、监控就绪度等 8 个章节
• 不同架构模式的填写示例（EKS/Serverless/EC2/多区域）

所有参考文件均提供英文版本，英文版文件名不带后缀（如 resilience-framework.md），中文版使用 _zh.md 后缀。

目录结构

aws-resilience-modeling/
├── SKILL.md                                    # 语言路由器（加载 EN/ZH）
├── SKILL_EN.md / SKILL_ZH.md                  # Skill 指令（双语，各 ~153 行）
├── README.md / README_zh.md                    # 说明文档（双语）
├── references/                                 # 参考文档（Agent 按需加载）
│   ├── analysis-tasks.md / _zh.md              # 8 个分析任务详细指令
│   ├── resilience-framework.md / _zh.md        # 框架索引和参考资料映射
│   ├── resilience-analysis-core.md / _zh.md    # 9 维度评分方法论
│   ├── waf-reliability-pillar.md / _zh.md      # WAF 可靠性支柱 + DR 成本基线
│   ├── common-risks-reference.md / _zh.md      # 50+ 常见 AWS 风险模式
│   ├── assessment-output-spec.md / _zh.md      # Chaos Skill 桥接：8 段输出规格
│   ├── compliance-mapping.md / _zh.md          # SOC2/ISO 27001/NIST CSF 框架映射
│   ├── cloud-design-patterns.md / _zh.md       # 云韧性设计模式
│   ├── chaos-engineering-methodology.md / _zh.md # 混沌工程方法论参考
│   ├── observability-standards.md / _zh.md     # AWS 可观测性最佳实践
│   ├── report-generation.md / _zh.md           # 报告生成工作流
│   ├── HTML-TEMPLATE-USAGE.md / _zh.md         # HTML 模板使用指南
│   └── MCP_SETUP_GUIDE.md / _zh.md             # MCP 服务器配置指南
├── scripts/
│   └── generate-html-report.py                 # Python 报告生成器
└── assets/
    ├── html-report-template.html               # HTML 交互式报告模板
    └── example-report-template.md / _zh.md     # Markdown 报告示例

分析框架

故障模式分类

韧性评估维度

使用 5 星评分系统（1星=不足，5星=优秀）评估：

• 冗余设计
• AZ 容错能力
• 超时与重试策略
• 断路器机制
• 自动扩展能力
• 配置防护措施
• 故障隔离
• 备份恢复机制
• AWS 最佳实践合规性

风险优先级评分

风险得分 = (发生概率 × 业务影响 × 检测难度) / 修复复杂度

示例场景

场景 1：电商平台

环境:
- Multi-AZ RDS (PostgreSQL)
- ECS Fargate 应用
- CloudFront + S3 静态资源
- ElastiCache Redis

关键发现:
- RDS 单区域（无 Aurora Global Database）
- 缺少 Auto Scaling 策略
- 未配置 Circuit Breaker
- 监控覆盖不足

建议:
- 迁移到 Aurora Global Database
- 实施 Target Tracking Auto Scaling
- 集成 AWS X-Ray 分布式追踪
- 建立季度 DR 演练

场景 2：金融 API

环境:
- API Gateway + Lambda
- DynamoDB Global Tables
- Aurora Serverless
- Route 53 健康检查

关键发现:
- Lambda 无 Reserved Concurrency
- 缺少 API 限流策略
- 未定义 SLO/SLI
- 无混沌工程实践

建议:
- 配置 Lambda Reserved Concurrency
- 实施 API Gateway Usage Plans
- 定义 99.99% 可用性 SLO
- 建立每周混沌实验

灾难恢复策略选择

参考资源

AWS 官方文档

• AWS Resilience Analysis Framework
• AWS Well-Architected - Reliability Pillar
• AWS Fault Injection Simulator
• AWS Resilience Hub

外部资源

• AWS Observability Best Practices
• Principles of Chaos Engineering
• Chaos Engineering on AWS

高级特性

错误预算管理

基于 AWS 韧性最佳实践，计算和跟踪错误预算：

错误预算 = (1 - SLO) × 时间周期

示例：
SLO = 99.9%（月度）
错误预算 = 43.2 分钟/月

混沌工程实验

使用 AWS FIS 进行故障注入：

• EC2 实例终止
• 网络延迟/丢包
• RDS 故障转移
• AZ 不可用模拟
• CPU/内存压力测试

可观测性三大支柱

• 日志：CloudWatch Logs + 结构化日志
• 指标：CloudWatch Metrics + 关键监控指标
• 追踪：AWS X-Ray + 分布式追踪

常见问题

Q: 分析需要多长时间？

A: 根据环境复杂度：

• 简单环境（单区域，< 10 服务）：1-2 小时
• 中等环境（多 AZ，10-50 服务）：3-5 小时
• 复杂环境（多区域，> 50 服务）：1-2 天

Q: 是否需要 AWS 账户访问权限？

A: 推荐但非必需：

• 有权限：可以自动扫描资源，分析更准确
• 无权限：基于提供的架构文档进行分析

Q: 分析会产生 AWS 费用吗？

A: 分析本身不产生费用，但实施建议可能包含：

• AWS Resilience Hub（免费）
• AWS FIS 混沌实验（按分钟计费）
• 额外的 AWS 服务（如 Aurora Global Database）

Q: 如何实施建议？

A: 分析报告包含：

• 具体的架构改进图
• AWS CLI 命令
• CloudFormation/Terraform 代码片段
• 分阶段实施路线图

Q: 是否支持多云环境？

A: 当前专注于 AWS 环境，提供基于 AWS Well-Architected Framework 的专业韧性评估。

更新日志

v1.1.0 (2026-03-14)

• ✅ 新增 common-risks-reference.md — AWS 常见服务风险参考手册
• ✅ 整合 50+ 个常见风险点（存储/数据库/EKS/EC2/网络）
• ✅ 新增按服务类型的评估检查清单
• ✅ SKILL.md 故障模式识别任务引用风险参考
• ✅ 风险分类细化对齐实际 AWS 服务

v1.0.0 (2025-02-17)

• ✅ 初始版本
• ✅ 整合 AWS Well-Architected Framework (2025)
• ✅ 整合 AWS 韧性分析框架
• ✅ 整合混沌工程方法论
• ✅ 整合 AWS 可观测性最佳实践
• ✅ 包含详细的 resilience-framework.md 参考

反馈和贡献

如有问题或建议，请通过以下方式反馈：

• 在对话中直接提出
• 更新你本地的 skill 文件

许可

本 skill 基于 AWS Well-Architected Framework 和混沌工程最佳实践编写，供学习和使用。

English | 中文

AWS System Resilience Analysis Skill

A comprehensive AWS system resilience assessment and risk analysis skill, incorporating the latest 2025 industry best practices.

Installation

Option A: npx skills (Recommended)

# Install this skill
npx skills add aws-samples/sample-aws-resilience-skill --skill aws-resilience-modeling

# Install all 4 resilience skills
npx skills add aws-samples/sample-aws-resilience-skill --skill '*'

Option B: Git clone

git clone https://github.com/aws-samples/sample-aws-resilience-skill.git

Features

• ✅ Based on the AWS Well-Architected Framework Reliability Pillar
• ✅ Integrates the AWS Resilience Analysis Framework (error budgets, SLO/SLI)
• ✅ Includes Chaos Engineering methodology (AWS FIS)
• ✅ Adopts AWS Observability Best Practices (CloudWatch, X-Ray, distributed tracing)
• ✅ Applies Cloud Design Patterns (Circuit Breaker, Bulkhead, Retry)
• ✅ Built-in AWS Common Service Risk Reference Library (50+ risk points covering storage/database/EKS/EC2/networking)

Usage

Method 1: Direct Invocation

/aws-resilience-modeling

Claude will first ask for your environment information and business context, then begin a comprehensive resilience analysis.

Method 2: Automatic Trigger

The skill activates automatically when you mention the following keywords in conversation:

• "AWS resilience analysis"
• "system risk assessment"
• "AWS resilience assessment"

Example:

User: I want to perform a resilience analysis on our AWS production environment
Claude: [auto-loads aws-resilience-modeling skill]

Prerequisites

Before starting the analysis, prepare the following information:

MCP Server Configuration

For detailed MCP server setup instructions (required for automated AWS environment scanning), see references/MCP_SETUP_GUIDE.md.

1. Environment Information

• AWS account ID and region
• Access credentials (read-only access recommended)
• Existing architecture documentation (if available)

2. Business Context

• List of critical business processes
• Current RTO/RPO targets
• Existing SLA/SLO (if available)
• Compliance requirements (e.g., SOC2, HIPAA, PCI DSS)

3. Analysis Scope

• Applications and services to be analyzed
• Whether multi-account/multi-region is included
• Budget and time constraints

Output

Upon completion of the analysis, you will receive:

Main Report

1. Executive Summary (2 pages)

• Key findings (Top 5 risks)
• Resilience maturity score
• Priority improvement recommendations

2. System Architecture Visualization

• Architecture overview diagram (Mermaid)
• Dependency diagram
• Data flow diagram
• Network topology diagram

3. Risk Inventory (table)

• Sorted by priority
• Includes risk scores, impact, and mitigation recommendations

4. Detailed Risk Analysis

• In-depth analysis of each high-priority risk
• Failure scenarios
• Business impact
• Improvement recommendations (architecture, configuration, monitoring)

5. Business Impact Analysis

• Critical business function mapping
• RTO/RPO compliance analysis

6. Mitigation Strategy Recommendations

• Specific architecture improvements
• Configuration optimizations (with parameters and commands)
• Monitoring and alerting configuration
• AWS service recommendations

7. Implementation Roadmap

• Gantt chart
• Detailed task breakdown
• Resource requirements and budget

8. Continuous Improvement Plan

• SLI/SLO definitions
• Postmortem process
• Chaos engineering plan

Additional Files

references/common-risks-reference.md - AWS Common Service Risk Reference Manual (中文)

• Covers five categories: storage (EBS/S3/EFS/FSx), databases, containers (EKS), compute (EC2), and networking
• 50+ common risk points, each with root cause and improvement recommendations
• Assessment checklist organized by service type

references/assessment-output-spec.md - Chaos Engineering Input Specification (中文)

• Defines the structured input format required by the chaos-engineering-on-aws skill
• Contains 8 sections including AWS resource inventory, risk experiment-readiness flags, and monitoring readiness
• Fill-in examples for different architecture patterns (EKS/Serverless/EC2/multi-region)

All reference files are available in both English and Chinese. Chinese versions use the _zh.md suffix (e.g., resilience-framework_zh.md).

Directory Structure

aws-resilience-modeling/
├── SKILL.md                                    # Language router (loads EN/ZH)
├── SKILL_EN.md / SKILL_ZH.md                  # Skill instructions (bilingual, ~153 lines each)
├── README.md / README_zh.md                    # Documentation (bilingual)
├── references/                                 # Reference docs (loaded on demand by Agent)
│   ├── analysis-tasks.md / _zh.md              # 8 analysis task detailed instructions
│   ├── resilience-framework.md / _zh.md        # Framework index & references map
│   ├── resilience-analysis-core.md / _zh.md    # 9-dimension scoring methodology
│   ├── waf-reliability-pillar.md / _zh.md      # WAF Reliability Pillar + DR cost baselines
│   ├── common-risks-reference.md / _zh.md      # 50+ common AWS risk patterns
│   ├── assessment-output-spec.md / _zh.md      # Chaos skill bridge: 8-section output spec
│   ├── compliance-mapping.md / _zh.md          # SOC2/ISO 27001/NIST CSF mapping
│   ├── cloud-design-patterns.md / _zh.md       # Cloud resilience design patterns
│   ├── chaos-engineering-methodology.md / _zh.md # Chaos engineering methodology reference
│   ├── observability-standards.md / _zh.md     # AWS observability best practices
│   ├── report-generation.md / _zh.md           # Report generation workflow
│   ├── HTML-TEMPLATE-USAGE.md / _zh.md         # HTML template usage guide
│   └── MCP_SETUP_GUIDE.md / _zh.md             # MCP server configuration guide
├── scripts/
│   └── generate-html-report.py                 # Python report generator
└── assets/
    ├── html-report-template.html               # HTML interactive report template
    └── example-report-template.md / _zh.md     # Markdown report example

Analysis Framework

Failure Mode Classification

Resilience Assessment Dimensions

Uses a 5-star rating system (1 star = inadequate, 5 stars = excellent) to assess:

• Redundancy design
• AZ fault tolerance
• Timeout and retry strategy
• Circuit breaker mechanism
• Auto-scaling capability
• Configuration safeguards
• Fault isolation
• Backup and recovery mechanism
• AWS best practices compliance

Risk Priority Scoring

Risk Score = (Probability × Business Impact × Detection Difficulty) / Remediation Complexity

Example Scenarios

Scenario 1: E-Commerce Platform

Environment:
- Multi-AZ RDS (PostgreSQL)
- ECS Fargate application
- CloudFront + S3 static assets
- ElastiCache Redis

Key Findings:
- RDS single-region (no Aurora Global Database)
- Missing Auto Scaling policies
- No Circuit Breaker configured
- Insufficient monitoring coverage

Recommendations:
- Migrate to Aurora Global Database
- Implement Target Tracking Auto Scaling
- Integrate AWS X-Ray distributed tracing
- Establish quarterly DR drills

Scenario 2: Financial API

Environment:
- API Gateway + Lambda
- DynamoDB Global Tables
- Aurora Serverless
- Route 53 health checks

Key Findings:
- Lambda without Reserved Concurrency
- Missing API throttling policies
- SLO/SLI not defined
- No chaos engineering practices

Recommendations:
- Configure Lambda Reserved Concurrency
- Implement API Gateway Usage Plans
- Define 99.99% availability SLO
- Establish weekly chaos experiments

Disaster Recovery Strategy Selection

Reference Resources

AWS Official Documentation

• AWS Resilience Analysis Framework
• AWS Well-Architected - Reliability Pillar
• AWS Fault Injection Simulator
• AWS Resilience Hub

External Resources

• AWS Observability Best Practices
• Principles of Chaos Engineering
• Chaos Engineering on AWS

Advanced Features

Error Budget Management

Based on AWS resilience best practices, calculate and track error budgets:

Error Budget = (1 - SLO) × Time Period

Example:
SLO = 99.9% (monthly)
Error Budget = 43.2 minutes/month

Chaos Engineering Experiments

Use AWS FIS for fault injection:

• EC2 instance termination
• Network latency/packet loss
• RDS failover
• AZ unavailability simulation
• CPU/memory stress tests

Three Pillars of Observability

• Logs: CloudWatch Logs + structured logging
• Metrics: CloudWatch Metrics + key monitoring indicators
• Traces: AWS X-Ray + distributed tracing

FAQ

Q: How long does the analysis take?

A: Depends on environment complexity:

• Simple environment (single region, < 10 services): 1–2 hours
• Medium environment (multi-AZ, 10–50 services): 3–5 hours
• Complex environment (multi-region, > 50 services): 1–2 days

Q: Is AWS account access required?

A: Recommended but not mandatory:

• With access: Resources can be scanned automatically for more accurate analysis
• Without access: Analysis is based on provided architecture documentation

Q: Will the analysis incur AWS charges?

A: The analysis itself incurs no charges, but implementing recommendations may include:

• AWS Resilience Hub (free)
• AWS FIS chaos experiments (billed per minute)
• Additional AWS services (e.g., Aurora Global Database)

Q: How do I implement the recommendations?

A: The analysis report includes:

• Specific architecture improvement diagrams
• AWS CLI commands
• CloudFormation/Terraform code snippets
• Phased implementation roadmap

Q: Is multi-cloud supported?

A: Currently focused on AWS environments, providing professional resilience assessments based on the AWS Well-Architected Framework.

Changelog

v1.1.0 (2026-03-14)

• ✅ Added common-risks-reference.md — AWS Common Service Risk Reference Manual
• ✅ Integrated 50+ common risk points (storage/database/EKS/EC2/networking)
• ✅ Added assessment checklist organized by service type
• ✅ SKILL.md failure mode identification task references the risk reference
• ✅ Risk classification refined to align with actual AWS services

v1.0.0 (2025-02-17)

• ✅ Initial release
• ✅ Integrated AWS Well-Architected Framework (2025)
• ✅ Integrated AWS Resilience Analysis Framework
• ✅ Integrated chaos engineering methodology
• ✅ Integrated AWS observability best practices
• ✅ Includes detailed resilience-framework.md reference

Feedback and Contributions

For questions or suggestions, please provide feedback by:

• Raising them directly in conversation
• Updating your local skill files

License

This skill is written based on the AWS Well-Architected Framework and chaos engineering best practices, for learning and use.

分析任务 — 详细指令

任务 1: 系统组件映射与依赖分析

使用工具：通过 MCP 服务器（aws-api-mcp-server）进行只读 API 调用（如可用）、Mermaid 图表。禁止通过 Bash 执行任何 aws CLI 命令访问 AWS 资源。

输出内容：

1. 系统架构总览图（Mermaid，展示 Region/AZ/组件层级）
2. 组件依赖关系图（标明同步/异步依赖、强/弱依赖、关键路径）
3. 数据流图（请求路径、数据流向、集成点）
4. 网络拓扑图（VPC、子网、安全组、路由表、NAT 网关、VPN/Direct Connect）

多账户注意事项（如果架构跨越多个 AWS 账户）：

• AWS Organizations SCP（服务控制策略）对韧性的影响
• 跨账户资源共享和 DR 策略（如共享 VPC、跨账户备份保管库）
• 集中式 vs 分散式备份和监控策略
• 跨账户 IAM 信任关系和故障转移权限

任务 2: 故障模式识别与分类（基于 AWS Resilience Analysis Framework）

参考资源：

• AWS Prescriptive Guidance - Resilience Analysis Framework
• 详见 resilience-framework_zh.md 索引文件。按需加载对应子文件：
• waf-reliability-pillar_zh.md — DR 策略、多 AZ/多 Region
• resilience-analysis-core_zh.md — Error Budget、SLI/SLO、黄金信号、事后复盘
• chaos-engineering-methodology_zh.md — 实验流程、FIS 模板
• observability-standards_zh.md — OpenTelemetry、日志/指标/链路
• cloud-design-patterns_zh.md — 舱壁、熔断器、重试

识别以下故障模式类别：

对每个故障模式提供：详细技术描述、当前配置问题、涉及的 AWS 服务和资源 ARN、触发条件和场景、业务影响评估。

风险分类：基础设施 / 中间件与数据库 / 容器平台 / 网络 / 数据 / 安全与合规。

任务 3: 韧性评估（5 星评分系统）

对每个关键组件进行评分（1星=不足，5星=优秀）：

评估维度：

映射：Modeling 9 维度 ↔ RMA 10 领域

如果用户同时完成了 RMA 评估（aws-rma-assessment 技能），可使用此映射交叉参考结果：

评分转换指南（近似）：

⚠️ 此映射为近似值。Modeling 评分反映特定组件的技术实现深度；RMA 级别反映人员、流程和工具的组织成熟度。

任务 4: 业务影响分析

1. 识别关键业务流程（用户注册/登录、订单处理、支付交易、数据分析等）
2. 评估组件故障影响（组件 → 故障场景 → 影响的业务功能 → 影响程度 → 用户影响 → 当前/目标 RTO）
3. RTO/RPO 合规性分析（当前架构能否满足业务目标、差距分析、优先改进领域）

任务 5: 风险优先级排序

风险评分矩阵：风险得分 = (发生概率 x 业务影响 x 检测难度) / 修复复杂度

风险得分严重性阈值：

同时进行级联效应分析：识别风险之间的关联、评估多点故障场景、最坏情况影响分析。

任务 6: 缓解策略建议

针对高优先级风险，提供具体的、可操作的建议。每个风险应包含：

1. 架构改进建议：修改前/后对比（Mermaid 图），展示改进方案
2. 配置优化建议：具体 AWS CLI 命令或 IaC 代码
3. 监控与告警建议：CloudWatch 告警配置（指标、阈值、告警级别、响应 SLA）
4. AWS 服务推荐：推荐服务、价值说明、成本影响
5. 实施评估：复杂度、预期效果、实施风险、成本范围、优先级

完整缓解策略示例参见 example-report-template_zh.md。

任务 7: 实施路线图

分阶段实施计划（基于风险优先级和依赖关系），使用 Mermaid Gantt 图展示：

• 阶段 1：基础韧性 — Multi-AZ 部署、自动备份、基础监控告警
• 阶段 2：自动化 — IaC 迁移、CI/CD 流水线、Auto Scaling
• 阶段 3：DR 和混沌工程 — Aurora Global Database、Route 53 故障转移、AWS FIS
• 阶段 4：持续改进 — SLO/SLI 定义、事后复盘流程、季度韧性评估

每阶段应包含详细任务卡（任务 ID、工作量、依赖、负责人、里程碑、成功标准）、资源需求和实施风险缓解策略。

任务 8: 持续改进机制

1. 定期韧性评估：季度执行，包含自动化扫描、手动架构审查、风险清单更新、优先级调整。

2. 韧性指标持续监控：定义 SLI/SLO，建立错误预算政策（预算耗尽时冻结非关键发布，充裕时可加速功能发布和混沌实验）。

3. 事后复盘流程（Postmortem）：遵循无责任文化原则，使用标准复盘模板（时间线、根因、影响、行动项）。复盘模板示例参见 example-report-template_zh.md。

4. 韧性知识库：建立集中式知识库，包含 Runbooks/、Postmortems/、Architecture/、Playbooks/ 等目录。

5. 团队技能培养：AWS Well-Architected 认证、SRE 实践培训、混沌工程工作坊、DR 演练、灾难角色扮演（Wheel of Misfortune）。

Analysis Tasks — Detailed Instructions

Task 1: System Component Mapping and Dependency Analysis

Tools Used: Read-only API calls via MCP servers (aws-api-mcp-server) if available, Mermaid diagrams. Do not use Bash to execute any aws CLI commands to access AWS resources.

Output:

1. System Architecture Overview (Mermaid, showing Region/AZ/component hierarchy)
2. Component Dependency Diagram (marking synchronous/asynchronous dependencies, strong/weak dependencies, critical paths)
3. Data Flow Diagram (request paths, data flows, integration points)
4. Network Topology Diagram (VPC, subnets, security groups, route tables, NAT gateways, VPN/Direct Connect)

Multi-Account Considerations (if the architecture spans multiple AWS accounts):

• AWS Organizations SCP (Service Control Policy) impact on resilience
• Cross-account resource sharing and DR strategy (e.g., shared VPC, cross-account backup vaults)
• Centralized vs. decentralized backup and monitoring strategy
• Cross-account IAM trust relationships and failover permissions

Task 2: Failure Mode Identification and Classification (Based on AWS Resilience Analysis Framework)

Reference Resources:

• AWS Prescriptive Guidance - Resilience Analysis Framework
• See resilience-framework.md for the index of all reference files. Load only the specific sub-file relevant to your current task:
• waf-reliability-pillar.md — DR strategies, Multi-AZ/Multi-Region
• resilience-analysis-core.md — Error budget, SLI/SLO, golden signals, postmortem
• chaos-engineering-methodology.md — Experiment process, FIS templates
• observability-standards.md — OpenTelemetry, logs/metrics/traces
• cloud-design-patterns.md — Bulkhead, circuit breaker, retry

Identify the following failure mode categories:

For each failure mode provide: Detailed technical description, current configuration issues, involved AWS services and resource ARNs, trigger conditions and scenarios, business impact assessment.

Risk Classification: Infrastructure / Middleware & Database / Container Platform / Network / Data / Security & Compliance.

Task 3: Resilience Assessment (5-Star Rating System)

Rate each critical component (1 star = inadequate, 5 stars = excellent):

Assessment Dimensions:

Mapping: Modeling 9 Dimensions ↔ RMA 10 Domains

If the user has also completed an RMA Assessment (aws-rma-assessment skill), use this mapping to cross-reference results:

Score Conversion Guide (approximate):

⚠️ This mapping is approximate. Modeling scores reflect technical implementation depth for specific components; RMA levels reflect organizational maturity across people, process, and tools.

Task 4: Business Impact Analysis

1. Identify Critical Business Processes (user registration/login, order processing, payment transactions, data analytics, etc.)
2. Assess Component Failure Impact (component -> failure scenario -> affected business functions -> impact severity -> user impact -> current/target RTO)
3. RTO/RPO Compliance Analysis (can the current architecture meet business objectives, gap analysis, priority improvement areas)

Task 5: Risk Prioritization

Risk Scoring Matrix: Risk Score = (Probability x Business Impact x Detection Difficulty) / Remediation Complexity

Risk Score Severity Thresholds:

Also perform Cascading Effect Analysis: Identify correlations between risks, assess multi-point failure scenarios, worst-case impact analysis.

Task 6: Mitigation Strategy Recommendations

For high-priority risks, provide specific, actionable recommendations. Each risk should include:

1. Architecture Improvement: Before/after comparison (Mermaid diagrams) showing the improvement plan
2. Configuration Optimization: Specific AWS CLI commands or IaC code
3. Monitoring & Alerting: CloudWatch alarm configuration (metrics, thresholds, alarm levels, response SLA)
4. AWS Service Recommendations: Recommended services, value proposition, cost impact
5. Implementation Assessment: Complexity, expected outcomes, implementation risks, cost range, priority

See example-report-template.md for complete mitigation strategy examples.

Task 7: Implementation Roadmap

Phased Implementation Plan (based on risk priority and dependencies), using Mermaid Gantt charts:

• Phase 1: Foundational Resilience -- Multi-AZ deployment, automated backup, basic monitoring and alerting
• Phase 2: Automation -- IaC migration, CI/CD pipelines, Auto Scaling
• Phase 3: DR and Chaos Engineering -- Aurora Global Database, Route 53 failover, AWS FIS
• Phase 4: Continuous Improvement -- SLO/SLI definition, postmortem process, quarterly resilience reviews

Each phase should include detailed task cards (task ID, effort, dependencies, owner, milestones, success criteria), resource requirements, and implementation risk mitigation strategies.

Task 8: Continuous Improvement Mechanisms

1. Regular Resilience Assessments: Quarterly execution including automated scanning, manual architecture review, risk inventory updates, priority adjustments.

2. Continuous Resilience Metrics Monitoring: Define SLI/SLO, establish error budget policies (freeze non-critical releases when budget is exhausted; accelerate feature releases and chaos experiments when budget is ample).

3. Postmortem Process: Follow blameless culture principles, use a standard postmortem template (timeline, root cause, impact, action items). See example-report-template.md for postmortem template examples.

4. Resilience Knowledge Base: Build a centralized knowledge base including Runbooks/, Postmortems/, Architecture/, Playbooks/ directories.

5. Team Skill Development: AWS Well-Architected certification, SRE practice training, Chaos Engineering workshops, DR drills, Wheel of Misfortune exercises.

Chaos Engineering 输入规范模板

用途：本文件定义 chaos-engineering-on-aws skill 所需的结构化输入格式。 请 aws-resilience-modeling skill 在生成韧性评估报告时，按照本规范的结构组织报告内容，确保混沌工程阶段可直接消费。

两种输出方式（任选）： 1. 独立文件模式（推荐）：单独生成 {project}-chaos-input-{date}.md，主报告中仅保留简要引用 2. 嵌入模式：在现有评估报告末尾添加 ## Chaos Engineering Ready Data 附录章节（仅当用户明确要求嵌入时使用）

推荐方式 1（独立文件，便于下游 chaos-engineering-on-aws skill 直接消费，同时避免主报告过于臃肿）

⚠️ 本规范定义的是结构（表头 + 字段 + 枚举值），不绑定任何特定系统。 附录 A 提供了不同架构模式的填写示例。

1. 为什么需要这个规范？

Assessment 的自由格式 Markdown 报告面向人类阅读，但混沌工程 Skill 需要一致的结构来自动化以下步骤：

• 从风险清单中筛选可实验的风险
• 将逻辑资源名映射为真实 AWS 资源（ARN）
• 生成 FIS / Chaos Mesh 实验配置
• 设定稳态假设阈值和停止条件

现有 Assessment 输出的问题：

2. 规范定义

以下为 Assessment 报告应包含的结构化章节。表头和字段名是固定的，内容按客户实际环境填写。

2.1 项目元数据

放在报告开头。

架构模式枚举：

2.2 AWS 资源清单

核心输入——没有 ARN 就无法创建 FIS 实验。列出评估中涉及的所有 AWS 资源。

固定表头：

资源类型标准名（优先使用以下名称；如果客户使用了不在列表中的 AWS 服务，自行添加类型名即可，格式为 {服务} {资源}）：

2.3 关键业务功能与依赖链

列出系统的关键业务功能、依赖的组件链、以及 RTO/RPO。

固定表头：

字段规范：

2.4 风险清单（含可实验性标记）

在现有风险清单基础上增加两列：可实验 和 建议注入方式。

固定表头：

字段枚举值：

2.5 风险详情（可实验风险补充信息）

对每个 可实验 = ✅/⚠️ 的风险，在详细分析中增加以下结构化内容：

必须包含的子表格：

涉及资源表

建议实验表

其他必须字段

• 影响的业务功能：引用 2.3 中的功能名称
• 现有缓解措施：列表或 无

2.6 监控就绪度

新增章节。混沌工程必须有监控才能定义稳态假设和停止条件。

固定结构：

## 监控就绪度

**整体就绪状态**: 🟢 就绪 / 🟡 部分就绪 / 🔴 未就绪

现有 CloudWatch 告警表

可用 CloudWatch 指标表

监控缺口（列表）

就绪状态判断标准：

2.7 韧性评分（9 维度）

使用固定的维度名称和 1-5 评分。

固定表头：

维度名称固定为以上 9 个，不可更改或增减。如果发现了不属于以上 9 维度的韧性问题，在评分表之后用自由文本记录。

2.8 约束和偏好（可选）

如果 Assessment 过程中用户提到了实验偏好，记录在此。

固定表头：

3. testable（可实验性）判断指南

供 Assessment Skill 判断每个风险是否适合混沌实验：

4. 建议注入方式速查表

供 Assessment Skill 为可实验风险推荐工具和 action：

5. Assessment 输出检查清单

Assessment 完成后，对照以下清单确认输出完整性：

• [ ] 项目元数据完整（账号 ID、区域、环境类型、架构模式、韧性评分）
• [ ] AWS 资源清单包含所有涉及资源的 完整 ARN
• [ ] 业务功能表列出依赖链和 RTO/RPO（单位：秒）
• [ ] 风险清单包含 可实验 和 建议注入方式 两列
• [ ] 所有 可实验 = ✅/⚠️ 的风险详情中包含涉及资源表和建议实验表
• [ ] 监控就绪度章节完整（就绪状态 + 现有告警 + 可用指标 + 缺口）
• [ ] 韧性评分 9 维度表格完整，维度名称未更改
• [ ] 约束和偏好已记录（如用户在评估过程中提到）
• [ ] 开放发现章节已记录（超出模板框架的新发现）

6. 开放发现（鼓励 LLM 超越模板）

⚠️ 本规范定义的是最低要求，不是能力上限。 以下三个开放章节鼓励 Assessment 和 Chaos Skill 的 LLM 记录超出模板框架的发现。

6.1 Assessment 阶段：额外发现的风险

如果 Assessment LLM 在分析过程中发现了不属于 5 种标准故障类别的风险，或速查表中没有对应注入方式的风险，不要丢弃，记录在此。

## 额外发现

### 超出标准分类的风险

| 风险 ID | 风险描述 | 自定义类别 | 为什么现有分类不适用 | 建议的验证方式（自由文本） |
|---------|---------|-----------|-------------------|----------------------|
| R-EXT-001 | 第三方 API 供应商 SLA 不透明 | 供应链风险 | 非 AWS 资源，不属于 5 类 | 模拟第三方 API 超时/错误，观测降级行为 |
| R-EXT-002 | DNS TTL 过长导致故障转移延迟 | 恢复延迟 | 介于"配置"和"延迟"之间 | 修改 TTL 后用 FIS 模拟 AZ 故障，测量实际切换时间 |

### 实验过程中新发现的风险

> 混沌工程 Skill 在执行实验时发现的、Assessment 阶段未识别的新风险。**实验后回填此表。**

| 发现来源（实验 ID） | 新风险描述 | 严重度 | 建议 |
|-------------------|-----------|--------|------|
| *(实验执行后填写)* | | | |

6.2 自定义实验方法

如果 LLM 认为某个风险可以通过非 FIS / 非 Chaos Mesh 的方式验证（如 AWS CLI 脚本、SSM Run Command、自定义 Lambda 等），在此记录。

### 自定义实验建议

| 风险 ID | 验证方法 | 工具/脚本 | 说明 | 安全风险 |
|---------|---------|----------|------|---------|
| R-XXX | AWS CLI 脚本 | `aws ec2 modify-instance-attribute --no-source-dest-check` | 修改网络属性观测影响 | 需回滚 |
| R-XXX | SSM Run Command | stress-ng 内存压力 | 在实例上直接注入压力 | 影响范围可控 |

6.3 架构层面的开放观察

Assessment 过程中发现的、不直接对应某个风险 ID 的架构层面观察。例如： - 架构反模式（但不确定是否构成风险） - 潜在的改进机会（非风险但值得关注） - 与行业最佳实践的差距（非直接风险）

### 开放观察

1. **观察**: EKS 集群使用 managed node group 但未配置 Cluster Autoscaler，高峰期可能资源不足
   **建议**: 考虑在混沌实验中加入负载压力测试，验证韧性边界

2. **观察**: 所有微服务共享同一个 DynamoDB 表，缺乏数据隔离
   **建议**: 可作为"共享命运"风险进一步评估

附录 A：不同架构模式的填写示例

以下示例展示不同类型客户系统如何填写本规范。仅展示关键差异部分。

A.1 EKS 微服务架构（如 VotingApp）

元数据：

架构模式: EKS 微服务

资源清单典型行：

典型可实验风险：

A.2 Serverless 架构（如电商后端）

元数据：

架构模式: Serverless

资源清单典型行：

典型可实验风险：

监控就绪度典型差异：

• Serverless 通常自带 CloudWatch 指标（Lambda Duration/Errors/Throttles）
• 监控就绪度更可能是 🟡 部分就绪

A.3 传统 EC2 三层架构（如企业内部系统）

元数据：

架构模式: 传统 EC2

资源清单典型行：

典型可实验风险：

A.4 多区域架构（如全球 SaaS 平台）

元数据：

架构模式: 多区域
主要区域: us-east-1
其他区域: eu-west-1, ap-southeast-1

资源清单需包含多区域资源：

典型可实验风险：

本规范由 chaos-engineering-on-aws skill 定义，反馈给 aws-resilience-modeling skill 设计者 版本：1.2 | 日期：2026-03-23

Chaos Engineering Input Specification Template

Purpose: This document defines the structured input format required by the chaos-engineering-on-aws skill. The aws-resilience-modeling skill should organize report content according to this specification when generating resilience assessment reports, ensuring the chaos engineering phase can directly consume the data.

Two Output Methods (choose one): 1. Standalone File Mode (Recommended): Generate a separate {project}-chaos-input-{date}.md. The main report should only include a brief reference, without duplicating the full data. 2. Embedded Mode: Add a ## Chaos Engineering Ready Data appendix section at the end of the existing assessment report (only when user explicitly requests embedding)

Method 1 is recommended (standalone file, easier for downstream chaos-engineering-on-aws skill to consume directly, and keeps the main report concise)

This specification defines structure (table headers + fields + enum values) and is not tied to any specific system. Appendix A provides fill-in examples for different architecture patterns.

1. Why Is This Specification Needed?

Assessment free-format Markdown reports are designed for human reading, but the Chaos Engineering Skill needs consistent structure to automate the following steps:

• Filter experimentable risks from the risk inventory
• Map logical resource names to actual AWS resources (ARN)
• Generate FIS / Chaos Mesh experiment configurations
• Set steady-state hypothesis thresholds and stop conditions

Issues with Current Assessment Output:

2. Specification Definition

The following are structured sections that should be included in Assessment reports. Table headers and field names are fixed; content is filled based on the customer's actual environment.

2.1 Project Metadata

Place at the beginning of the report.

Architecture Pattern Enum:

2.2 AWS Resource Inventory

Core input -- FIS experiments cannot be created without ARNs. List all AWS resources involved in the assessment.

Fixed Table Headers:

Standard Resource Type Names (prefer the following names; if the customer uses an AWS service not on this list, add the type name as needed, format: {Service} {Resource}):

2.3 Critical Business Functions and Dependency Chains

List the system's critical business functions, dependency component chains, and RTO/RPO.

Fixed Table Headers:

Field Specifications:

2.4 Risk Inventory (With Experiment-Readiness Flags)

Add two columns to the existing risk inventory: Testable and Suggested Injection Method.

Fixed Table Headers:

Field Enum Values:

2.5 Risk Details (Supplementary Info for Testable Risks)

For each risk with Testable = Yes/Conditional, add the following structured content in the detailed analysis:

Required Sub-tables:

Involved Resources Table

Suggested Experiments Table

Other Required Fields

• Affected Business Functions: Reference function names from Section 2.3
• Existing Mitigations: List or None

2.6 Monitoring Readiness

New section. Chaos engineering requires monitoring to define steady-state hypotheses and stop conditions.

Fixed Structure:

## Monitoring Readiness

**Overall Readiness Status**: Ready / Partially Ready / Not Ready

Existing CloudWatch Alarms Table

Available CloudWatch Metrics Table

Monitoring Gaps (List)

Readiness Status Criteria:

2.7 Resilience Scores (9 Dimensions)

Use fixed dimension names and 1-5 scoring.

Fixed Table Headers:

Dimension names are fixed to the above 9 and cannot be modified or added/removed. If resilience issues outside these 9 dimensions are found, record them in free text after the scoring table.

2.8 Constraints and Preferences (Optional)

If the user mentions experiment preferences during the Assessment, record them here.

Fixed Table Headers:

3. testable (Experiment-Readiness) Assessment Guide

For the Assessment Skill to determine whether each risk is suitable for chaos experiments:

4. Suggested Injection Method Quick Reference

For the Assessment Skill to recommend tools and actions for testable risks:

5. Assessment Output Checklist

After Assessment completion, verify output completeness against this checklist:

• [ ] Project metadata is complete (account ID, region, environment type, architecture pattern, resilience score)
• [ ] AWS resource inventory contains complete ARNs for all involved resources
• [ ] Business function table lists dependency chains and RTO/RPO (unit: seconds)
• [ ] Risk inventory includes Testable and Suggested Injection Method columns
• [ ] All Testable = Yes/Conditional risk details contain involved resources table and suggested experiments table
• [ ] Monitoring readiness section is complete (readiness status + existing alarms + available metrics + gaps)
• [ ] Resilience scores 9-dimension table is complete, dimension names unchanged
• [ ] Constraints and preferences recorded (if user mentioned during assessment)
• [ ] Open findings section recorded (new findings beyond template framework)

6. Open Findings (Encouraging LLMs to Go Beyond the Template)

This specification defines minimum requirements, not capability limits. The following three open sections encourage Assessment and Chaos Skill LLMs to record findings beyond the template framework.

6.1 Assessment Phase: Additional Discovered Risks

If the Assessment LLM discovers risks that don't belong to the 5 standard failure categories, or risks without corresponding injection methods in the quick reference, do not discard them -- record them here.

## Additional Findings

### Risks Beyond Standard Classification

| Risk ID | Risk Description | Custom Category | Why Existing Classification Doesn't Apply | Suggested Verification Method (free text) |
|---------|-----------------|----------------|------------------------------------------|------------------------------------------|
| R-EXT-001 | Third-party API provider SLA is opaque | Supply Chain Risk | Not an AWS resource, doesn't fit 5 categories | Simulate third-party API timeout/errors, observe degradation behavior |
| R-EXT-002 | DNS TTL too long causing failover delay | Recovery Delay | Between "configuration" and "latency" | Modify TTL then use FIS to simulate AZ failure, measure actual switchover time |

### Risks Newly Discovered During Experiments

> New risks discovered by the Chaos Engineering Skill during experiment execution that were not identified during the Assessment phase. **Fill in this table after experiments.**

| Discovery Source (Experiment ID) | New Risk Description | Severity | Recommendation |
|--------------------------------|---------------------|----------|----------------|
| *(fill after experiment execution)* | | | |

6.2 Custom Experiment Methods

If the LLM believes a risk can be verified through methods other than FIS / Chaos Mesh (e.g., AWS CLI scripts, SSM Run Command, custom Lambda, etc.), record here.

### Custom Experiment Suggestions

| Risk ID | Verification Method | Tool/Script | Description | Safety Risk |
|---------|-------------------|-------------|-------------|-------------|
| R-XXX | AWS CLI Script | `aws ec2 modify-instance-attribute --no-source-dest-check` | Modify network attribute and observe impact | Needs rollback |
| R-XXX | SSM Run Command | stress-ng memory stress | Inject stress directly on instance | Controllable impact scope |

6.3 Architecture-Level Open Observations

Architecture-level observations discovered during the Assessment that don't directly correspond to a specific risk ID. For example: - Architecture anti-patterns (uncertain if they constitute risks) - Potential improvement opportunities (not risks but worth noting) - Gaps from industry best practices (not direct risks)

### Open Observations

1. **Observation**: EKS cluster uses managed node group but has not configured Cluster Autoscaler; may run out of resources during peaks
   **Suggestion**: Consider adding load stress testing in chaos experiments to verify resilience boundaries

2. **Observation**: All microservices share a single DynamoDB table, lacking data isolation
   **Suggestion**: Can be further assessed as a "Shared Fate" risk

Appendix A: Fill-in Examples for Different Architecture Patterns

The following examples show how different types of customer systems fill in this specification. Only key differences are shown.

A.1 EKS Microservices Architecture (e.g., VotingApp)

Metadata:

Architecture Pattern: EKS Microservices

Typical Resource Inventory Rows:

Typical Testable Risks:

A.2 Serverless Architecture (e.g., E-Commerce Backend)

Metadata:

Architecture Pattern: Serverless

Typical Resource Inventory Rows:

Typical Testable Risks:

Typical Monitoring Readiness Differences:

• Serverless typically has built-in CloudWatch metrics (Lambda Duration/Errors/Throttles)
• Monitoring readiness is more likely to be Partially Ready

A.3 Traditional EC2 Three-Tier Architecture (e.g., Enterprise Internal System)

Metadata:

Architecture Pattern: Traditional EC2

Typical Resource Inventory Rows:

Typical Testable Risks:

A.4 Multi-Region Architecture (e.g., Global SaaS Platform)

Metadata:

Architecture Pattern: Multi-Region
Primary Region: us-east-1
Other Regions: eu-west-1, ap-southeast-1

Resource inventory needs to include multi-region resources:

Typical Testable Risks:

This specification is defined by the chaos-engineering-on-aws skill, provided as feedback to the aws-resilience-modeling skill designers Version: 1.2 | Date: 2026-03-23

属于 AWS 韧性分析框架参考 的一部分。

3. 混沌工程方法论

3.1 核心定义

"混沌工程是通过在系统上进行实验来建立对系统能力的信心，使其能够承受生产环境中的动荡条件"

—— Principles of Chaos Engineering

目标：

• 发现系统弱点在造成实际影响前
• 建立对系统韧性的信心
• 验证监控和告警是否有效
• 改进事故响应流程

3.2 四步实验流程

步骤 1: 建立稳态基线
  定义:
    - "稳态"为可测量的系统输出
    - 表示正常行为

  示例:
    - 请求成功率: > 99.9%
    - P95 延迟: < 200ms
    - 吞吐量: 1000 req/s
    - 错误率: < 0.1%

步骤 2: 形成假设
  预测:
    - 稳态将在控制组和实验组中持续
    - 基于系统理解

  示例:
    "假设：终止 2 个 EC2 实例后，
     Auto Scaling 将在 5 分钟内恢复容量，
     用户体验影响 < 1%"

步骤 3: 引入变量
  模拟真实世界破坏:
    - 服务器崩溃
    - 网络故障
    - 磁盘满
    - 时钟偏移

  评估影响:
    - 观测稳态指标
    - 记录系统行为

步骤 4: 验证或反驳
  对比:
    - 控制组 vs 实验组
    - 识别稳态偏差

  结果:
    - 假设正确：系统韧性得到验证
    - 假设错误：发现弱点，改进系统

3.3 高级实施原则

3.4 常见混沌实验场景

AWS 环境常见场景：

3.5 AWS FIS 实验模板示例

实验 1：EC2 实例终止

{
  "description": "Terminate 30% of EC2 instances to test Auto Scaling",
  "targets": {
    "ec2-instances": {
      "resourceType": "aws:ec2:instance",
      "resourceTags": {
        "Environment": "production",
        "AutoScaling": "enabled"
      },
      "filters": [
        {
          "path": "State.Name",
          "values": ["running"]
        }
      ],
      "selectionMode": "PERCENT(30)"
    }
  },
  "actions": {
    "terminate-instances": {
      "actionId": "aws:ec2:terminate-instances",
      "parameters": {},
      "targets": {
        "Instances": "ec2-instances"
      }
    }
  },
  "stopConditions": [
    {
      "source": "aws:cloudwatch:alarm",
      "value": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:high-error-rate"
    }
  ],
  "roleArn": "arn:aws:iam::123456789012:role/FISExperimentRole",
  "tags": {
    "Name": "EC2-Instance-Termination-Test"
  }
}

实验 2：网络延迟注入

{
  "description": "Inject 200ms latency to 50% of API calls",
  "targets": {
    "api-gw-targets": {
      "resourceType": "aws:ec2:instance",
      "resourceTags": {
        "Service": "api-gateway"
      },
      "selectionMode": "PERCENT(50)"
    }
  },
  "actions": {
    "inject-latency": {
      "actionId": "aws:ec2:api-network-latency",
      "parameters": {
        "duration": "PT10M",
        "latencyMs": "200",
        "jitterMs": "50",
        "apiList": "ec2,rds,dynamodb"
      },
      "targets": {
        "Instances": "api-gw-targets"
      }
    }
  },
  "stopConditions": [
    {
      "source": "aws:cloudwatch:alarm",
      "value": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:high-p95-latency"
    }
  ],
  "roleArn": "arn:aws:iam::123456789012:role/FISExperimentRole"
}

实验 3：RDS 故障转移

{
  "description": "Test RDS Multi-AZ failover",
  "targets": {
    "rds-cluster": {
      "resourceType": "aws:rds:cluster",
      "resourceArns": [
        "arn:aws:rds:us-east-1:123456789012:cluster:production-db"
      ],
      "selectionMode": "ALL"
    }
  },
  "actions": {
    "failover-cluster": {
      "actionId": "aws:rds:failover-db-cluster",
      "parameters": {
        "targetInstance": "production-db-instance-2"
      },
      "targets": {
        "Clusters": "rds-cluster"
      }
    }
  },
  "stopConditions": [
    {
      "source": "none"
    }
  ],
  "roleArn": "arn:aws:iam::123456789012:role/FISExperimentRole",
  "tags": {
    "Name": "RDS-Failover-Test",
    "Frequency": "monthly"
  }
}

Part of the AWS Resilience Analysis Framework Reference.

3. Chaos Engineering Methodology

3.1 Core Definition

"Chaos Engineering is the discipline of experimenting on a system to build confidence in the system's capability to withstand turbulent conditions in production."

-- Principles of Chaos Engineering

Goals:

• Discover system weaknesses before they cause real impact
• Build confidence in system resilience
• Verify monitoring and alerting effectiveness
• Improve incident response processes

3.2 Four-Step Experiment Process

Step 1: Establish Steady-State Baseline
  Definition:
    - "Steady state" is a measurable system output
    - Represents normal behavior

  Examples:
    - Request success rate: > 99.9%
    - P95 latency: < 200ms
    - Throughput: 1000 req/s
    - Error rate: < 0.1%

Step 2: Form Hypothesis
  Prediction:
    - Steady state will continue in both control and experimental groups
    - Based on system understanding

  Example:
    "Hypothesis: After terminating 2 EC2 instances,
     Auto Scaling will restore capacity within 5 minutes,
     user experience impact < 1%"

Step 3: Introduce Variables
  Simulate Real-World Disruptions:
    - Server crashes
    - Network failures
    - Disk full
    - Clock skew

  Assess Impact:
    - Observe steady-state metrics
    - Record system behavior

Step 4: Validate or Refute
  Compare:
    - Control group vs. experimental group
    - Identify steady-state deviations

  Results:
    - Hypothesis correct: System resilience verified
    - Hypothesis incorrect: Weakness discovered, improve system

3.3 Advanced Implementation Principles

3.4 Common Chaos Experiment Scenarios

Common AWS Scenarios:

3.5 AWS FIS Experiment Template Examples

Experiment 1: EC2 Instance Termination

{
  "description": "Terminate 30% of EC2 instances to test Auto Scaling",
  "targets": {
    "ec2-instances": {
      "resourceType": "aws:ec2:instance",
      "resourceTags": {
        "Environment": "production",
        "AutoScaling": "enabled"
      },
      "filters": [
        {
          "path": "State.Name",
          "values": ["running"]
        }
      ],
      "selectionMode": "PERCENT(30)"
    }
  },
  "actions": {
    "terminate-instances": {
      "actionId": "aws:ec2:terminate-instances",
      "parameters": {},
      "targets": {
        "Instances": "ec2-instances"
      }
    }
  },
  "stopConditions": [
    {
      "source": "aws:cloudwatch:alarm",
      "value": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:high-error-rate"
    }
  ],
  "roleArn": "arn:aws:iam::123456789012:role/FISExperimentRole",
  "tags": {
    "Name": "EC2-Instance-Termination-Test"
  }
}

Experiment 2: Network Latency Injection

{
  "description": "Inject 200ms latency to 50% of API calls",
  "targets": {
    "api-gw-targets": {
      "resourceType": "aws:ec2:instance",
      "resourceTags": {
        "Service": "api-gateway"
      },
      "selectionMode": "PERCENT(50)"
    }
  },
  "actions": {
    "inject-latency": {
      "actionId": "aws:ec2:api-network-latency",
      "parameters": {
        "duration": "PT10M",
        "latencyMs": "200",
        "jitterMs": "50",
        "apiList": "ec2,rds,dynamodb"
      },
      "targets": {
        "Instances": "api-gw-targets"
      }
    }
  },
  "stopConditions": [
    {
      "source": "aws:cloudwatch:alarm",
      "value": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:high-p95-latency"
    }
  ],
  "roleArn": "arn:aws:iam::123456789012:role/FISExperimentRole"
}

Experiment 3: RDS Failover

{
  "description": "Test RDS Multi-AZ failover",
  "targets": {
    "rds-cluster": {
      "resourceType": "aws:rds:cluster",
      "resourceArns": [
        "arn:aws:rds:us-east-1:123456789012:cluster:production-db"
      ],
      "selectionMode": "ALL"
    }
  },
  "actions": {
    "failover-cluster": {
      "actionId": "aws:rds:failover-db-cluster",
      "parameters": {
        "targetInstance": "production-db-instance-2"
      },
      "targets": {
        "Clusters": "rds-cluster"
      }
    }
  },
  "stopConditions": [
    {
      "source": "none"
    }
  ],
  "roleArn": "arn:aws:iam::123456789012:role/FISExperimentRole",
  "tags": {
    "Name": "RDS-Failover-Test",
    "Frequency": "monthly"
  }
}

合规框架映射

将韧性分析任务映射到合规框架的参考指引。这不是正式的合规认证。

使用说明

• 此映射为参考指引，帮助识别哪些分析任务与特定合规要求相关
• 不构成正式的合规认证或审计证据
• 某些合规要求可能限制架构选项（如数据驻留）
• 确保 DR 策略符合审计要求
• 文档和审计跟踪对合规至关重要

Compliance Framework Mapping

Reference guide for mapping resilience analysis tasks to compliance frameworks. This is not a formal compliance certification.

Usage Notes

• This mapping is a reference guide to help identify which analysis tasks are relevant for specific compliance requirements
• It does not constitute formal compliance certification or audit evidence
• Certain compliance requirements may limit architecture options (e.g., data residency)
• Ensure DR strategies meet audit requirements
• Documentation and audit trails are critical for compliance

AWS 韧性分析框架 - 参考文件索引

本文档是韧性分析详细参考资料的索引。每个部分作为独立文件维护，按需加载。

参考文件

使用方法

仅加载与当前分析任务相关的参考文件，不要一次性加载所有文件。

按任务快速查找：

• 任务 1（架构映射）→ observability-standards_zh.md 检查监控缺口
• 任务 2（故障模式）→ resilience-analysis-core_zh.md、common-risks-reference_zh.md、cloud-design-patterns_zh.md
• 任务 3（韧性评分）→ analysis-tasks_zh.md 获取评分维度和 RMA 交叉映射
• 任务 4（业务影响）→ waf-reliability-pillar_zh.md 获取 RTO/RPO 和 DR 策略
• 任务 5（风险排序）→ analysis-tasks_zh.md 获取风险评分矩阵
• 任务 6（缓解策略）→ cloud-design-patterns_zh.md、waf-reliability-pillar_zh.md
• 任务 7（路线图）→ analysis-tasks_zh.md 获取分阶段计划结构
• 任务 8（持续改进）→ resilience-analysis-core_zh.md 获取 SLI/SLO 和复盘
• 混沌工程输出 → assessment-output-spec_zh.md
• 合规 → compliance-mapping_zh.md
• 报告生成 → report-generation_zh.md、HTML-TEMPLATE-USAGE_zh.md

AWS Resilience Analysis Framework - Reference Index

This document serves as an index to the detailed resilience analysis reference materials. Each section is maintained as a separate file for efficient access.

Reference Files

How to Use

Load only the specific reference file relevant to your current analysis task. Do not load all files at once.

Quick lookup by task:

• Task 1 (Architecture Mapping) → observability-standards.md for monitoring gaps
• Task 2 (Failure Modes) → resilience-analysis-core.md, common-risks-reference.md, cloud-design-patterns.md
• Task 3 (Resilience Rating) → analysis-tasks.md for scoring dimensions and RMA cross-mapping
• Task 4 (Business Impact) → waf-reliability-pillar.md for RTO/RPO and DR strategies
• Task 5 (Risk Prioritization) → analysis-tasks.md for risk scoring matrix
• Task 6 (Mitigation) → cloud-design-patterns.md, waf-reliability-pillar.md
• Task 7 (Roadmap) → analysis-tasks.md for phased plan structure
• Task 8 (Continuous Improvement) → resilience-analysis-core.md for SLI/SLO and postmortem
• Chaos Engineering Output → assessment-output-spec.md
• Compliance → compliance-mapping.md
• Report Generation → report-generation.md, HTML-TEMPLATE-USAGE.md