Skip to content

AWS 2026-10-13

Read original ↗

Scope workloads and share resilience policies with AWS Resilience Hub

Summary

A walkthrough of three capabilities added to the next generation of AWS Resilience Hub on 2026-09-18, demonstrated against a sample EKS checkout service: (1) EKS label support for scoping which Kubernetes resources belong to a service, using the labels teams already maintain rather than reorganizing namespaces; (2) generative-AI Dependency Insights, which summarizes DNS-discovered dependencies and surfaces resilience-relevant patterns (cross-Region, new, third-party, uneven usage) to prioritize review; and (3) resilience-policy sharing through AWS Organizations, letting a central SRE team define RTO/RPO/availability targets once and make them available to member accounts, with attach/detach events tracked for adoption. The throughline: a resilience plan is useful only while it reflects the running application, so Resilience Hub closes the drift between documented recovery objectives and the service's actual, discovered dependency graph.

Key takeaways

  1. The next-gen Resilience Hub model is service → system → user journey. The primary unit of assessment is a service; services group into systems; user journeys describe paths through them. Scoping a service correctly is the precondition for every downstream assessment. (Source: sources/2026-10-13-aws-scope-workloads-and-share-resilience-policies-with-aws-resilience-hub)

  2. A service input source tells Resilience Hub where to discover resources — CloudFormation stacks, Terraform state, resource tags, or an EKS cluster. For EKS, you pick namespaces and now add Kubernetes label selectors (key + operator + values; IN / NOT_IN / EXISTS / DOES_NOT_EXIST). Selectors within a namespace are AND-combined. checkout and inventory share the production namespace; app In checkout scopes to checkout's Deployment and ReplicaSet without reorganizing the namespace.

  3. Labels scope Kubernetes objects only, not shared AWS infrastructure. The discovered resource list still includes the cluster, node group, VPC, and subnets — labels do not make that shared infrastructure exclusive to the service. This is the standard shared-cluster attribution caveat.

  4. Dependency discovery is DNS-based, agentless, and bounded by history. It analyzes DNS activity through Amazon Route 53 Resolver (no agent in the workload), examines up to 35 days of available history, and keeps monitoring for change. It records each endpoint's name, location, and first/last-seen timestamps. It is a separately priced, optional feature.

  5. Generative-AI Dependency Insights prioritizes, it does not prescribe. It filters out common service activity that typically is not a resilience risk and highlights four categories: cross-Region, new (first seen in last 7 days), third-party, and uneven usage. Insights are regenerable once per 24 hours. They don't list every dependency or recommend fixes — "DNS activity alone cannot answer" whether a dependency fits the recovery design; the architecture review does.

  6. Cross-Region dependency is the headline resilience finding. In the sample, checkout reached DynamoDB in us-west-2 cross-Region with hard criticality, coupling its availability to a remote Region even when its EKS resources are healthy. The owner must verify which operations require the table and how they behave when it is unavailable. (Source: sources/2026-10-13-aws-scope-workloads-and-share-resilience-policies-with-aws-resilience-hub)

  7. Dependency criticality is a hard/soft classification. Classify a dependency hard if the service fails without it, soft if it degrades but keeps running (update-dependency --criticality HARD). This is the lever that turns a discovered endpoint into a modeled recovery assumption — one that still "requires validation through testing."

  8. A resilience policy combines four target types. Availability SLO, recovery from an AZ disruption, recovery from a Regional disruption, and data recovery. Each recovery target carries an RTO (targeted recovery time) and RPO (tolerable data loss). The sample tier-1-critical policy: availability 99.9%; multi-AZ RTO 5 min / RPO 1 min ACTIVE_ACTIVE; multi-Region RTO 15 min / RPO 5 min WARM_STANDBY; data recovery backup interval 60 min.

  9. Policy sharing centralizes definition, not enforcement. With Organizations trusted access enabled, the management account (or delegated admin) shares a policy; it appears in member accounts alongside their own, its ARN showing the owner. Each service owner chooses whether to apply it — to make a requirement mandatory, associate the policy with a system containing the services instead. Owning account reviews list-policy-events (POLICY_ATTACHED_TO_SERVICE) to track adoption. Turning sharing off removes the policy from every member service using it — a coordinate-first operation.

  10. An attachment event confirms adoption, not compliance. After applying the shared policy, each target moved from "Not defined in policy" to "Pending failure mode assessment." A failure-mode assessment plus resilience testing is still required to know whether the service actually meets the targets.

  11. Known limits of DNS-based discovery. Direct-IP connections aren't discovered; Lambda needs VPC connectivity to be covered; very infrequent calls may not appear initially; a new workload's insights reflect only the history it has generated. Plan for a build-up period before trusting insights.

Systems / concepts / patterns extracted

  • AWS Resilience Hub (next generation) — primary subject. Service/system/user-journey model; input sources; dependency discovery; Dependency Insights; policy sharing. resiliencehubv2 CLI.
  • Amazon EKS — label-selector-based service scoping (namespace + matchExpressions); shared-cluster attribution caveat.
  • Amazon Route 53 Resolver — the DNS data source for agentless dependency discovery (35-day lookback).
  • DynamoDB — the cross-Region, hard-criticality dependency in the worked example.
  • AWS Organizations — trusted access + service-linked role (AWSServiceRoleForResilienceHub) enabling cross-account policy sharing.
  • RPO / RTO — the policy target vocabulary (per-target RTO/RPO across AZ, Region, and data-recovery dimensions).
  • Regional failover — the WARM_STANDBY / ACTIVE_ACTIVE multi-Region recovery approaches named as policy disasterRecoveryApproach values.
  • Blast radius — cross-Region hard dependency widens the failure domain beyond the service's own Region.
  • Centralized governance (adjacent) — the define-once / adopt-across-accounts policy-sharing pattern mirrors the central-team-defines-standards governance shape.
  • cross-region-dependency (tag; not minted as a page) — DNS-discovered calls to another Region that silently couple availability; recorded here and on the Resilience Hub page as prose, pending a second source.
  • Pattern: pilot light / async cross-region replication — the recovery approaches the multi-region and multi-az policy targets codify (WARM_STANDBY ≈ warm standby tier; ACTIVE_ACTIVE ≈ multi-site).

Operational numbers

Quantity Value
Capabilities launch date 2026-09-18
DNS discovery history window up to 35 days
Dependency Insights regeneration limit once / 24 hours
Sample result 5 insights across 29 dependencies
"New dependency" window first seen in last 7 days
Sample policy — availability SLO 99.9%
Sample policy — multi-AZ RTO 5 min, RPO 1 min, ACTIVE_ACTIVE
Sample policy — multi-Region RTO 15 min, RPO 5 min, WARM_STANDBY
Sample policy — data recovery backup interval 60 min
Service-linked role AWSServiceRoleForResilienceHub
Assessment execution policy AWSResilienceHubV2AssessmentExecutionPolicy

Insight categories (Dependency Insights)

Pattern What to investigate
Cross-Region Whether the remote-Region call is intentional and how it affects recovery
New Whether a <7-day-old endpoint changes the documented architecture
Third-party How the service behaves when an external provider is unavailable
Uneven usage Whether activity is a scheduled job or a time-bounded dependency

Caveats

  • Feature-walkthrough post, not an architecture deep-dive. Ingested for the reusable resilience-engineering vocabulary it exercises (RTO/RPO policy targets, hard/soft dependency criticality, agentless DNS dependency discovery, centralized-policy governance), not for novel internals of Resilience Hub.
  • DNS discovery blind spots (direct-IP, Lambda-without-VPC, rare calls) mean the discovered graph is a floor, not a complete inventory.
  • Attachment ≠ compliance — a policy applied to a service does not mean the service meets the targets; a failure-mode assessment and testing are still required.
  • Insights are a 24-hour-cached, history-bounded summary — low-confidence on brand-new workloads.

Source

Last updated · 854 distilled / 2,448 read