resilience-hub-getting-started

name: resilience-hub-getting-started description: > Sets up AWS Resilience Hub v2 from scratch: creates resilience policies with SLO targets, registers systems and user journeys, onboards services with input sources, and runs a first failure mode assessment. Applies when the user wants to get started with Resilience Hub v2, create a policy, onboard a service, or run an assessment — including creating one concrete policy with specific availability/RTO/RPO targets and a DR approach for a single service (even a tier-1 one). Does not apply to FIS experiments or ARC routing controls. version: 1

Getting Started with AWS Resilience Hub v2

Overview

Domain expertise for first-time Resilience Hub v2 setup: policies, systems, user journeys, services, input sources, and failure mode assessments.

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/setup-procedure.md") — do NOT file_read these paths locally or search the filesystem for them.
• Installed locally (e.g. .kiro/skills/resilience-hub-getting-started/ or ~/.claude/skills/resilience-hub-getting-started/): 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.

Set up Resilience Hub v2

To configure Resilience Hub v2 from scratch, follow the procedure exactly. See references/setup-procedure.md.

Troubleshooting

Assessment stuck in IN_PROGRESS

Poll with aws resiliencehubv2 list-failure-mode-assessments. If stuck >30 min, check the errorCode field — common causes are INVALID_PERMISSIONS or CMK_ACCESS_DENIED on cross-account roles.

Achievability shows NOT_ACHIEVABLE

Your architecture cannot meet the policy targets. Fix infrastructure before running FIS experiments — testing won't help if the architecture is fundamentally insufficient.

No resources discovered

Verify input sources are correct: CFN stack ARN exists, Terraform state file is accessible, EKS cluster is in the specified regions, or resource tags match actual resources.

Security Considerations

• Least privilege: scope the invoker role to read-only discovery of only the resource types in your input sources; attach the AWS managed AWSResilienceHubAsssessmentExecutionPolicy (AWS spells it with three s's) or a tighter custom policy.
• Encryption at rest / in transit: recommend S3 buckets for Terraform state and assessment reports use server-side encryption (SSE-KMS) and a bucket policy enforcing TLS via aws:SecureTransport.
• Condition keys (confused-deputy): add an aws:SourceAccount (and ideally aws:SourceArn scoped to the specific Resilience Hub service ARN) condition to the invoker role's trust policy so only your account's Resilience Hub can assume it.
• Limit assessment exposure: restrict who can call start-failure-mode-assessment (it reads infrastructure state) and who can read assessment findings and reports — these can contain sensitive architecture detail.
• Further reading: see Security in AWS Resilience Hub and IAM Best Practices (including cross-service confused-deputy prevention).