Back to Details

resilience-program-design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Resilience Program Design

弹性恢复计划设计

Overview

概述

Planning-level guidance for an organization's resilience program: how to structure policies by tier, and how often to run resilience activities.
针对组织弹性恢复计划的规划级指导：如何按层级构建策略，以及弹性恢复活动的运行频率。

Structuring resilience policies across an organization

在组织范围内构建弹性恢复策略

Recommend a tiered policy model (not one policy per service): classify services by business criticality and set policy targets accordingly.
  • Availability SLO — higher as criticality rises. The API accepts only a fixed set of SLO values and rejects out-of-set ones, so confirm the valid values from the API/docs (e.g. 
    aws resiliencehubv2 create-policy help
    or the Resilience Hub documentation) rather than relying on a hardcoded list — illustratively, values such as 
    99.9
    /
    99.95
    /
    99.99
    .
  • RTO/RPO — tighten as criticality rises (single-digit minutes for critical, hours for low).
  • DR approach — match to criticality (more aggressive for more critical), using a value from the API's DR-approach enum — verify the valid set via the API/docs (e.g. 
    aws resiliencehubv2 create-policy help
    ); illustratively 
    ACTIVE_ACTIVE
    … 
    BACKUP_AND_RESTORE
    .
Example (illustrative — resolve the actual enum values against the API before recommending): payments/auth → 
99.99
+ single-digit-minute RTO + 
ACTIVE_ACTIVE
; internal tools → 
99.9
+ tens-of-minutes RTO + 
WARM_STANDBY
; dev/test → 
99.9
+ multi-hour RTO + 
BACKUP_AND_RESTORE
.
Warn against contradictory policies (e.g. the maximum SLO 
99.99
with 
BACKUP_AND_RESTORE
, or multi-region RTO shorter than multi-AZ RTO).
建议采用分层策略模型（而非每个服务单独一个策略）：根据业务关键程度对服务进行分类，并相应设置策略目标。
  • 可用性SLO — 关键程度越高，SLO值越高。API仅接受固定范围的SLO值，超出范围的值会被拒绝，因此请从API/文档中确认有效值（例如 
    aws resiliencehubv2 create-policy help
    或Resilience Hub文档），而非依赖硬编码列表——示例值包括 
    99.9
    /
    99.95
    /
    99.99
    。
  • RTO/RPO — 关键程度越高，目标越严格（关键业务为个位数分钟，低优先级业务为小时级）。
  • 灾难恢复（DR）方法 — 与关键程度匹配（关键业务采用更激进的方法），需使用API的DR方法枚举值——请通过API/文档验证有效值集合（例如 
    aws resiliencehubv2 create-policy help
    ）；示例值包括 
    ACTIVE_ACTIVE
    …… 
    BACKUP_AND_RESTORE
    。
示例（仅供参考——推荐前请先对照API确认实际枚举值）：支付/认证服务 → 
99.99
+ 个位数分钟级RTO + 
ACTIVE_ACTIVE
；内部工具 → 
99.9
+ 数十分钟级RTO + 
WARM_STANDBY
；开发/测试环境 → 
99.9
+ 数小时级RTO + 
BACKUP_AND_RESTORE
。
警告避免矛盾的策略（例如最高SLO 
99.99
搭配
BACKUP_AND_RESTORE
，或多区域RTO短于多可用区RTO）。

How often to run resilience activities (cadence)

弹性恢复活动的运行频率（节奏）

Recommend this minimum cadence when asked how often to run resilience activities:
  • Continuous: ARC zonal autoshift practice runs (automated)
  • Weekly: review the Resilience Hub findings dashboard
  • Monthly: run FIS experiments (single-service fault-injection tests)
  • Quarterly: cross-service GameDay
  • Event-driven: after every production incident and before/after major deployments
当被问及弹性恢复活动的运行频率时，建议遵循以下最低节奏：
  • 持续进行：ARC可用区自动转移练习（自动化）
  • 每周：查看Resilience Hub结果仪表板
  • 每月：运行FIS实验（单服务故障注入测试）
  • 每季度：跨服务GameDay
  • 事件驱动：每次生产事故后，以及重大部署前后

Security Considerations

安全注意事项

Program-level guidance — bake security into the standards you set:
  • Standardize least privilege: require every resilience role (Resilience Hub invoker, FIS execution, ARC operator) in your templates and policies to be least-privilege and resource-scoped, with 
    aws:SourceArn
    / 
    aws:SourceAccount
    condition keys on their trust policies to prevent confused-deputy access.
  • Mandate short-lived credentials: require all resilience automation to authenticate as IAM roles with short-lived credentials (role assumption, AWS SSO, instance profiles) — never IAM users with long-lived access keys — as a program standard, since these roles perform privileged and potentially destructive operations.
  • Mandate encryption: make SSE-KMS on report/state buckets part of your tier baseline, and enforce encryption in transit (TLS) — e.g. an 
    aws:SecureTransport
    deny-if-false condition on those bucket policies and HTTPS-only API access.
  • Govern FIS in production: define an authorization / change-management gate for production fault injection as part of the program cadence.
  • Limit exposure of resilience outputs: assessment findings, FIS logs, and GameDay reports can contain sensitive architectural detail (resource ARNs, IPs, failure modes) — make restricting their access to authorized personnel part of your program standards.
  • Further reading: point teams to the AWS Well-Architected Security Pillar, FIS Security Best Practices, and IAM Best Practices for implementing these standards.
规划级指导——将安全融入你制定的标准中：
  • 标准化最小权限原则：要求模板和策略中的每个弹性恢复角色（Resilience Hub调用者、FIS执行者、ARC操作员）都遵循最小权限原则并限定资源范围，在其信任策略中添加
    aws:SourceArn
    /
    aws:SourceAccount
    条件键，以防止混淆代理访问。
  • 强制使用短期凭证：要求所有弹性恢复自动化流程以IAM角色身份认证，使用短期凭证（角色假设、AWS SSO、实例配置文件）——绝对禁止使用带有长期访问密钥的IAM用户——作为项目标准，因为这些角色执行的是具有特权且可能具有破坏性的操作。
  • 强制加密：将报告/状态存储桶的SSE-KMS加密作为层级基线的一部分，并强制传输中加密（TLS）——例如在存储桶策略中添加
    aws:SecureTransport
    拒绝条件，以及仅允许HTTPS访问API。
  • 管控生产环境中的FIS：将生产环境故障注入的授权/变更管理 gate 纳入项目节奏中。
  • 限制弹性恢复输出的暴露范围：评估结果、FIS日志和GameDay报告可能包含敏感架构细节（资源ARN、IP地址、故障模式）——将限制授权人员访问这些内容纳入项目标准。
  • 扩展阅读：引导团队参考AWS Well-Architected安全支柱、FIS安全最佳实践和IAM最佳实践以落实这些标准。