resilience-program-design

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).

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