I built a Kiro power for AWS Resilience Hub. It told me none of my apps would survive a region failure.

Why Resilience Hub needed to live in my IDE

AWS Resilience Hub has been around for years, and the next-generation version that went GA in May 2026 is good: GenAI failure-mode assessments, automatic dependency discovery, RTO/RPO validation against live infrastructure. I'd used it maybe three times. The problem was never the service. It was where the service lives.

The workflow is: leave your editor, open the console, create a resiliency policy, register an application, import resources from a stack, publish a version, run an assessment, wait, read the findings, then translate those findings back into the CloudFormation or Terraform sitting in the tab you left twenty minutes ago. Every one of those steps is a place to stop.

So the findings stayed in the console and my IaC stayed unresilient. I knew what was wrong. I just never did anything about it, because doing something about it meant retyping console output into a template by hand, later, when I had time.

Kiro powers close that distance. A power is a bundle of MCP servers, skills, and steering files you drop into the IDE, after which the agent treats the whole workflow as native capability. So I built one for Resilience Hub. Then, since I had it sitting there, I pointed it at my own AWS account. That turned out to be the part worth writing about.

What the power actually is

It's an umbrella power: four MCP servers, each covering a different part of one question. Is this workload resilient, and what does fixing it cost?

The split matters. aws-mcp tells me a bucket has no cross-Region replication. aws-docs points at the Config rule and the CloudFormation property that fix it, aws-repost surfaces what broke for the people who tried it before me, and aws-pricing puts the number at 43 cents a month. Any one of those on its own just leaves me with homework.

Four skills

Skills are the part people underrate. An MCP server gives the agent capability. A skill gives it a procedure. Without skills/assess/SKILL.md, asking Kiro to "assess my app" produces a plausible-looking sequence of API calls that skips publishing the app version and then fails at the assessment step. With it, the ordering is fixed and the agent knows what a breached policy actually means.

The three steering files carry the judgment that doesn't belong in a skill: assessment-workflow.md for sequencing, arc-failover.md for the safety rules around moving production traffic, and wa-reliability.md for DR tier selection and mapping findings to Reliability-pillar best practices. The context-templates/ directory is deliberately user-owned. rto-rpo-targets.md is where you write down what the business actually promised, because no API can tell the agent that.

Onboarding and the prerequisite gate

Three prerequisites, and the power checks all of them before it touches anything: AWS CLI 2.32.0 or newer, uvx installed (the MCP servers launch through it), and an active AWS session.

uvx --version
aws --version
aws sts get-caller-identity
aws resiliencehub list-apps --region us-east-1

I ran this on root credentials because it was my own sandbox account, and the steering caught it and told me to use a scoped IAM role with Resilience Hub and ARC read permissions instead. Fair enough. I've since fixed it. I'm leaving the screenshot in because the power flags this rather than quietly carrying on, and "quick test on root" is how bad habits end up in production accounts.

The account scan, and the workloads nobody registered

The account-scan skill exists because of a failure mode I've hit repeatedly: Resilience Hub only assesses applications you've registered, and the applications you've registered are the ones you were already worried about. The ones that quietly matter never get added.

The scan found one registered app and three CloudFormation-based workloads that had never been near Resilience Hub. So the agent registered them, which is a five-step sequence per app that I would absolutely have gotten wrong by hand.

The assessment: where cross-scout broke

Let me walk through one app in full rather than skim four. cross-scout is a small serverless app: one Lambda, one S3 bucket, one SNS topic, EventBridge on a schedule. The kind of thing you deploy in an afternoon and never think about again. Its policy targets 4 hours RTO and 1 hour RPO at the Region level.

Read that Region row again. Target RTO 4 hours, assessed RTO 30 days. Thirty days is Resilience Hub's way of writing "never." There is no recovery path. If us-east-1 goes down, that workload is offline until I rebuild it by hand.

What I found useful is that the assessment doesn't stop at the app level. It attributes the breach to specific components:

The four findings, in the order they'd hurt:

• DraftsBucket has versioning turned on, but no cross-Region replication and no AWS Backup copy to a second region. In a regional outage the objects are gone.
• Versioning protects that bucket against overwrites, but with no Object Lock a delete still lands. Restoring from previous versions is a 4,320-second RTO, or 72 minutes against a 60-minute target.
• DigestTopic is a single-region SNS topic, so unprocessed messages are lost and RPO is effectively unrecoverable.
• ScoutFunction rides out AZ and region disruption fine because it holds no state, but it has no dead-letter queue, so failed invocations disappear with nowhere to replay them from.

That last one is the finding I care most about. A missing DLQ never comes up in a DR conversation, because it isn't a DR problem. It loses data on an ordinary Tuesday, quietly, and the only reason I saw it at all is that the assessment scores each disruption type separately instead of collapsing everything into one number.

Where the docs and re:Post servers earn their place

A finding like "enable cross-Region replication" is where most tools stop. Here the agent turns around and searches AWS documentation for each recommendation, so the fix arrives with the Config rule that enforces it and the CloudFormation property that implements it.

Remediation, alarms, and the SOPs I never wrote

The report skill converts findings into an ordered set of changes. Region-level items come first because those are the ones with no recovery path at all.

Twelve missing alarms on a three-resource app is the number that embarrassed me. Twelve isn't a lot. The problem is that the right number was never zero, and I'd never once stopped to ask. S3 4xx/5xx, request latency, Lambda errors and throttles, memory and duration anomalies, SNS delivery failures, canaries in-region and cross-region. Obvious in hindsight. None of them existed.

The SOP recommendations are runbooks: S3 object version restore, Lambda concurrency and memory adjustment, provisioned concurrency changes, alias version switching. Across the account there were 34 recommended SOPs and I had written zero of them. Recovery procedures I'd have been inventing at 3am with an outage running.

Putting a price on it

This is why v4 added the pricing MCP. Every resilience conversation I've had eventually stalls on the same question: what does this cost? Without a number, "enable cross-Region replication" loses to a feature ticket every time. So the report now prices each recommendation against the live Price List API, unit rate × quantity = monthly total.

First, the account-wide picture across all four apps:

Then the cost to close all of it:

Eleven dollars a month. That number is low for reasons worth being honest about, and the report says so itself: my data volumes are tiny (every DynamoDB table under 1 GB), and several of the highest-value fixes are free features I simply hadn't turned on.

Three of my top-priority fixes cost nothing at all. The biggest line item across the whole account was CloudWatch alarms, $8.60/month for all 86 of them, which means observability outspent replication. At production scale, say 100 GB per data store, the report projects $50-80/month. Still not a number worth losing an argument over.

The systemic view

Aggregating four apps surfaced something a single assessment can't: the same eight root causes repeating.

Rows 5 through 8 hit every app. Four separate oversights would be bad luck. One habit repeated four times is what this actually is: I deploy stateless compute carefully and treat everything around it as an afterthought. No single-app assessment would have shown me that.

What I got wrong building this

So: I built this expecting to make an existing service more convenient. What it did instead was tell me my whole account sat one region away from unrecoverable. Four apps, sixteen components, ten with no regional recovery path, for eleven dollars a month I hadn't spent because nothing had ever put the number in front of me.

The findings weren't new information. Resilience Hub could have told me all of this two years ago. The difference is that this time the finding arrived in the same window as the CloudFormation that caused it, priced, with the best-practice ID attached. That's the only thing that changed, and it was enough.

If you run this against your own account, I'd like to know what your Region row says. My guess is you already know and haven't looked.