AWS Resilience Hub for EKS: Labels, Dependency Insights, and Shared Policies

AWS Resilience Hub added three capabilities that make it more practical for platform teams operating many EKS workloads and AWS accounts: EKS label-based service inputs, generative AI dependency insights, and resilience-policy sharing through AWS Organizations.

Together they address three different problems: defining an application boundary, understanding what it depends on, and applying consistent resilience expectations.

Scope EKS Services with Existing Labels

Resilience Hub can now use EKS labels within a namespace as a service input source. Instead of treating every resource in a namespace as one service, teams can align discovery with labels they already use for ownership and application identity.

A useful convention might include:

metadata:
  labels:
    app.kubernetes.io/name: checkout
    app.kubernetes.io/part-of: storefront
    platform.devopsboys.com/owner: payments
    platform.devopsboys.com/tier: critical

Before using labels as assessment boundaries, audit their consistency. A selector that omits a worker, CronJob, or supporting service produces an incomplete failure model. A selector that is too broad mixes unrelated dependencies and owners.

Manage identity labels through Helm, Kustomize, or policy instead of adding them manually after deployment.

Turn Discovered Dependencies into Reviewable Evidence

When dependency discovery is enabled, Resilience Hub can observe application dependencies and attribute them to compute resources. The dependency view includes type, location, criticality, query frequency, first seen, and last seen.

Dependency Insights analyzes that data and highlights patterns such as:

• newly observed dependencies;
• cross-Region dependencies;
• unusual usage patterns.

This is valuable because architecture diagrams frequently lag behind runtime behavior. A service may begin calling a third-party API or a resource in another Region without the resilience plan changing.

Treat generated insights as investigation leads. Discovery cannot decide whether a dependency is contractually critical, whether the application has a fallback, or whether an unusual call is a release, incident, or attack. Assign a human owner to classify hard and soft dependencies.

Review Cross-Region Dependencies Carefully

A cross-Region dependency is not automatically bad. It may implement disaster recovery or access a centralized service. But it changes latency, data residency, failure correlation, and recovery assumptions.

For each flagged dependency, ask:

1. Is the dependency intentional and documented?
2. What happens if the remote Region is unavailable?
3. Does DNS, identity, or network routing create another shared failure point?
4. Is the dependency inside the application's recovery time and recovery point objectives?
5. Has the fallback path been tested recently?

Use resilience testing to validate the answer rather than accepting the diagram.

Share Policies Across AWS Organizations

Central teams can now share resilience policies through AWS Organizations. This lets a platform or resilience team define expectations once and make them available across accounts while retaining visibility into adoption.

Avoid a single universal policy. A development service, internal tool, customer-facing API, and payment system should not inherit identical RTO and RPO expectations.

Define policy tiers such as:

Map the service tier label to the intended policy and report exceptions with an owner and expiry.

A Practical Rollout

Start with one service whose Kubernetes labels, owners, and architecture are understood:

1. Verify label completeness inside the namespace.
2. Add the EKS label selector as the service input.
3. Enable dependency discovery and allow enough time to observe normal traffic cycles.
4. Review new, cross-Region, and unusual dependencies with the service owner.
5. Assign criticality and document fallback behavior.
6. Apply a resilience policy matching business impact.
7. Run a controlled resilience test and update the runbook.
8. Expand to another account only after the model is repeatable.

The feature is available only in the AWS Regions listed by AWS for the next-generation Resilience Hub. Verify current regional availability before designing an organization-wide rollout.

What This Does Not Replace

Resilience Hub does not replace observability, incident response, backups, workload-level availability design, or chaos testing. It helps organize evidence and assessment around them.

The best outcome is not a dashboard full of green policies. It is a dependency model that matches runtime reality and produces specific engineering work before an outage exposes the gap.

For experiment design fundamentals, read what chaos engineering is.

Sources

• AWS: Resilience Hub adds three capabilities
• AWS Docs: Viewing discovered dependencies
• AWS Docs: Add resource collections