AWS Resilience Hub adds dependency insights and shared policies

AWS Resilience Hub has gained three capabilities: EKS resource selection through labels, insights over discovered dependencies, and resilience-policy sharing through AWS Organizations.

Defining an application with EKS labels

Resilience Hub can treat labels inside a namespace as a service input source. Teams can reuse their Kubernetes conventions to scope an assessment to the resources owned by one application.

The operational risk is label quality. If labels are optional, change without review, or serve several unrelated purposes, the discovered application boundary will be incomplete. Audit coverage and assign ownership of the labelling scheme before depending on automated discovery.

Dependency insights

The new feature analyses discovered relationships, highlights new and cross-Region dependencies, and flags unusual usage patterns. AWS describes it as generative AI-powered, so an insight should be treated as an engineering hypothesis, not proof of resilience.

Validate the dependency graph against data flows, network telemetry, DNS configuration, queues, and external APIs. Shared supporting systems deserve particular attention: one identity service, image registry, or configuration store can create a common failure point across otherwise independent applications.

Organisation-wide policies

A central team can share modular resilience policies across accounts and see where they are used. This can establish a consistent minimum, but policies still need workload classes. Applying the same RTO and RPO to an internal test environment and a critical service creates superficial consistency rather than useful governance.

Start with one representative application, measure discovery accuracy, record exceptions, link the assessment to a recovery plan, and run a real failure exercise. An assessment report supports that exercise; it cannot replace it.

Source: the official AWS announcement dated 18 September 2026.