AI Infrastructure
AWS Resilience Hub Lets Teams Define the Workload Before AI Assesses It
An AI-assisted resilience assessment starts with what it can see. AWS's September 18 Resilience Hub update adds Kubernetes label-based workload scoping, dependency insights and policy sharing across AWS Organizations. These controls address different parts of a reliability review.
Citation-ready: AWS Resilience Hub now combines EKS-label scoping, dependency insights and shared policies; an assessment finding is not evidence that a workload has survived a failure test.
Evidence boundary: AWS product announcement and editorial validation criteria. No cloud account connected, policy changed, failure injected or reliability improvement independently measured.

What happened and why it matters
A detailed report can still be about the wrong system. Label scoping makes the selection boundary explicit before dependency analysis and organizational policy are applied.
Primary evidence
Primary reference: AWS September 18 Resilience Hub changelog. Kaleido Field checked the event date and the article's attributed facts against this source.
| Source date | September 18, 2026 |
|---|---|
| Checked by Kaleido Field | September 20, 2026, CST |
| Source function | AI infrastructure -> assessment scope and operational resilience |
Discovery has a boundary
AWS says dependency insights require dependency discovery and can highlight new or cross-Region dependencies and unusual usage. Shared policies let central teams see which services use a policy across accounts. The release lists supported Regions rather than claiming worldwide availability.
A team can first compare the discovered inventory with the service it intended to assess. Missing dependencies and unrelated resources can both distort the result. Review the selection before interpreting the severity of any finding.
A shared policy is not a recovered service
Policy adoption can establish that an account uses the same rule as its peers. It cannot establish that the application's recovery steps work or that its dependencies recover in a useful order.
Keep the policy, assessment, remediation and observed test outcome as separate records. This is the same measurement discipline used in our coverage-policy report: a centrally managed threshold is valuable, but the underlying behavior still needs evidence.
Evidence boundary
AWS product announcement and editorial validation criteria. No cloud account connected, policy changed, failure injected or reliability improvement independently measured.
FAQ
Does an AI dependency insight prove that a service will recover from an outage?
No. It is an analysis input; recovery behavior requires an appropriately scoped test and observed result.