resilience-program-design

Use a tiered policy model that classifies services by business criticality rather than one policy per service. Assign each tier an availability SLO, RTO/RPO targets, and a DR approach, verifying valid enum values against the Resilience Hub API before recommending them.

Run FIS single-service fault-injection experiments monthly and cross-service GameDays quarterly. Review the Resilience Hub findings dashboard weekly, keep ARC zonal autoshift practice runs continuous, and add event-driven activities after incidents and around major deployments.

Match DR approach aggressiveness to criticality: critical services like payments use ACTIVE_ACTIVE with single-digit-minute RTO, mid-tier services use WARM_STANDBY, and dev/test workloads use BACKUP_AND_RESTORE. Confirm the exact enum values via the Resilience Hub API or documentation.

Do not use it for creating or configuring a specific policy or resource for a single workload, for step-by-step lifecycle execution, or for service-specific setup. Those cases belong to getting-started, lifecycle, or service-specific skills instead.

Require least-privilege, resource-scoped IAM roles with SourceArn and SourceAccount conditions, short-lived credentials instead of long-lived access keys, SSE-KMS on report buckets with TLS enforcement, and a change-management gate for production fault injection.