Name: aws-resilience-lifecycle
Author: aws

Guides the end-to-end AWS resilience lifecycle integrating Resilience Hub v2, Fault Injection Service, and Application Recovery Controller. Covers the Define → Test → Operate workflow: from policy creation through failure mode assessment, to FIS experiment validation, to ARC operational controls. Ap

AWS Resilience Lifecycle 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. Guardrail — where this skill's own files live (MCP vs local install) 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 . Execute the full lifecycle To implement end to end resilience across all three services, follow the procedure exactly. See [references/lifecycle workflow.md](references/lifecycle workflow.md). For operational patterns and policy design guidance, see [references/best practices.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. 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. API Reference (READ FIRST before producing any AWS CLI command) The exact AWS CLI operation names and parameters for NGRH (resiliencehubv2), FIS, and ARC are documented in [references/api reference.md](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. 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). 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 experiments pass but production still fails 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). 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](https://docs.aws.amazon.com/fis/latest/userguide/security.html), [IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best practices.html), and the [AWS Well Architected Security Pillar](https://docs.aws.amazon.com/wellarchitected/latest/security pillar/welcome.html) for authoritative guidance on securing this lifecycle.