Scope workloads and share resilience policies with AWS Resilience Hub

在 AWS 弹性中心中定义工作负载范围并共享弹性策略 | AWS 架构博客

在 AWS 弹性中心中定义工作负载范围并共享弹性策略

只有当弹性计划准确反映您运行的应用程序时，它才有价值。迁移或部署后，一项服务可能会获得新的依赖项，但其记录的恢复目标可能保持不变。在共享的 Kubernetes 集群中，即使确定哪些资源属于该服务也可能需要调查。

2026 年 9 月 18 日，下一代 AWS 弹性中心推出了三项新功能，帮助您保持工作负载范围和弹性需求与运行环境的一致性：

• Amazon Elastic Kubernetes Service（Amazon EKS）标签支持用于服务输入源选择，通过已描述工作负载的标签选择 Kubernetes 资源。

• 基于生成式 AI 的依赖洞察分析服务发现的依赖项，并突出显示需要审查的模式。

• 通过 AWS Organizations 共享弹性策略，允许中央团队一次性定义弹性需求，并将其提供给成员账户。

在本文中，您将跟随一个团队审查名为 checkout 的示例工作负载在 Amazon EKS 上的弹性情况，该工作负载代表在线商店的结账服务。团队首先使用标签来确定哪些 Kubernetes 资源属于 checkout，从而将其与同一命名空间中的库存区分开。这为弹性审查建立了资源边界。

在定义该边界后，团队检查发现的依赖项，并使用依赖洞察来确定需要调查的重点。跨区域的依赖关系成为关于 checkout 的恢复设计是否考虑了其运行所需服务的具体问题。随后，服务所有者与中央弹性团队合作验证恢复需求并应用共享策略。在中央维护这些需求可为各团队提供统一的定义，而策略事件则帮助中央团队跟踪采用情况。

您可以使用控制台或 AWS 命令行界面（AWS CLI）执行这些步骤。工作负载会生成合成流量以演示依赖项发现过程。

关于应用模型：在下一代弹性中心中，评估的基本单位是服务。服务可以分组到系统中，用户旅程描述了通过这些系统的路径。请参阅下一代弹性中心的关键变更和新层次结构概述。

先决条件

要跟随示例，您需要：

• 在支持的 AWS 区域中访问下一代 AWS 弹性中心。

• 带有示例标记工作负载并具有配置集群访问权限的 Amazon EKS 集群。

• 如果遵循 CLI 示例，请使用安装和更新说明安装或更新 AWS CLI。您的安装必须支持 resiliencehubv2 命令。这些示例使用 Bash。

• Resilience Hub 可以承担的 AWS 身份和访问管理（IAM）角色，附加了 AWSResilienceHubV2AssessmentExecutionPolicy 管理策略。控制台在创建服务时可以创建此角色。

• Kubernetes RBAC 权限和 EKS 访问条目，授予此角色对 Kubernetes 资源的访问权限。权限指南提供了清单和命令。

• 对于策略共享，一个启用了所有功能并可以访问其管理账户的组织。

以下是翻译后的 Markdown 内容：

示例中使用了两个账户：一个包含 EKS 集群和 Resilience Hub 服务的工作负载账户，以及拥有共享策略的管理账户。

对于 CLI 示例，请分别为这两个账户配置名为 workload 和 management 的配置文件。将示例中的集群 ARN 和其他占位符替换为您的实际值，并设置区域：

export AWS_REGION=us-east-1

每个命令都使用 --profile 参数来选择账户。对于每个操作，请遵循控制台步骤或对应的 CLI 等效操作。

Amazon EKS 对服务输入源的标签支持

服务输入源告诉 Resilience Hub 在何处发现服务的资源。输入源可以是 AWS CloudFormation 堆栈、Terraform 状态文件、资源标签或 Amazon EKS 集群。对于 EKS 输入源，您需要选择要包含的命名空间。通过此次发布，您还可以使用 Kubernetes 标签选择器来筛选这些命名空间内的资源。

一个命名空间可能包含由不同团队拥有的工作负载。通过标签，您可以选择 checkout 的资源而不包含 inventory 或重新组织命名空间来进行评估。您可以使用团队已维护的相同标签。

实现方式

指定集群和一个或多个命名空间，然后为每个命名空间添加标签选择器以筛选资源。选择器包含键、操作符和值。命名空间内的选择器使用 AND 逻辑：对象必须匹配所有选择器。如果没有选择器，Resilience Hub 会发现所选命名空间中的所有支持对象。

checkout 和 inventory 共享 production 命名空间。它们的资源分别带有 app=checkout 和 app=inventory 标签。使用 production 命名空间并指定 app In checkout 会包含 checkout 的 Deployment 和 ReplicaSet，但会排除 inventory。

图 1：使用 Kubernetes 标签选择 checkout 资源

资源列表还包括支持的 AWS 基础设施，例如集群、节点组、虚拟私有云 (VPC) 和子网。标签选择 Kubernetes 对象，但不会使这些共享基础设施专属于 checkout。

使用方法

在 Resilience Hub 控制台中：

• 选择“创建服务”并输入名称。在“权限”部分，选择“创建默认角色”以创建具有所需 AWS 权限的 IAM 角色，或选择“使用其他角色”以选择现有角色。

• 在“服务资源发现”部分，选择“Amazon EKS 集群”并输入集群 ARN。

• 选择“配置命名空间”，输入 production，并添加一个标签选择器，键为 app，操作符为 In，值为 checkout。

• 选择“保存”，然后选择“为此服务启用依赖项发现”，最后选择“创建服务”。资源发现将自动开始。

图 2：将 checkout 服务限定到一个命名空间和一个标签

如果您更倾向于使用 AWS CLI 而不是控制台，请运行以下命令来创建服务并添加其 EKS 输入源。

如果您已经使用前面的控制台步骤创建了服务，请跳过此部分。

控制台将选择器操作符显示为 In、NotIn、Exists 和 NotExists。在 API 中，分别使用 IN、NOT_IN、EXISTS 和 DOES_NOT_EXIST。

在以下命令中，将 ResilienceHubRole 替换为您的服务的 IAM 角色名称。

# 创建启用依赖发现的 checkout 服务并保存其 ARN
SERVICE_ARN=$(aws resiliencehubv2 create-service \
  --profile workload \
  --name checkout \
  --regions "$AWS_REGION" \
  --permission-model '{"invokerRoleName": "ResilienceHubRole"}' \
  --dependency-discovery ENABLED \
  --query 'service.serviceArn' --output text)

# 添加 EKS 输入源，选择标记为 app=checkout 的生产环境资源
aws resiliencehubv2 create-input-source \
  --profile workload \
  --service-arn "$SERVICE_ARN" \
  --resource-configuration '{
    "eks": {
      "clusterArn": "arn:aws:eks:us-east-1:111122223333:cluster/resilience-demo",
      "namespaces": ["production"],
      "labelSelector": {
        "matchExpressions": [
          {"key": "app", "operator": "IN", "values": ["checkout"]}
        ]
      }
    }
  }'

# 资源发现完成后，使用以下命令列出发现的资源类型
# 如果是通过控制台创建的服务，首先将 SERVICE_ARN 设置为该服务的 ARN
aws resiliencehubv2 list-resources \
  --profile workload \
  --service-arn "$SERVICE_ARN" \
  --query 'serviceResources[].resource.resourceType'

由生成式 AI 驱动的依赖洞察

依赖洞察利用生成式 AI 对发现的依赖关系进行总结，并突出需要进行弹性审查的模式。它提供概述和分类发现结果。

资源列表描述了服务的组件。依赖列表显示通过 DNS 活动发现的端点，包括其他区域的 AWS 服务端点和外部 API。当该列表增长到数百条记录时，依赖洞察可帮助您确定需要调查的优先级。

依赖洞察基于依赖发现功能，这是一个可选的、单独计费的功能。依赖发现通过 Amazon Route 53 Resolver 分析 DNS 活动，无需在工作负载中安装代理。它会检查最多 35 天的历史记录，并持续监控变化。依赖列表显示每个端点的名称、位置以及首次和最后一次出现的时间。

依赖洞察分析此列表，过滤掉通常不表示弹性风险的常见服务活动，并突出以下模式：

| 模式 | 需要调查的内容 | |------|----------------| | 跨区域依赖 | 调用其他区域是否是故意的，以及对恢复的影响 | | 新增依赖 | 在过去七天内首次观察到的端点是否改变了记录的架构 | | 第三方依赖 | 当外部提供商不可用时服务的行为 | | 使用不均衡 | 活动是否反映计划任务或仅在特定时间使用的依赖项 |

图 3：将依赖数据转化为有针对性的审查

洞察会优先审查事项。它们不会规定修复方案或列出所有依赖项。需要详细信息时请使用完整的依赖列表。新工作负载的洞察仅反映其生成的历史记录。

在 Resilience Hub 控制台中，等待初始依赖发现完成后生成洞察：

• 打开服务。在评估标签页中，滚动到依赖部分查看发现的依赖项。
• 选择生成洞察。
• 阅读概述并逐一将每个发现结果与预期架构进行比较。

每天可以重新生成一次洞察。无论通过控制台还是 AWS CLI 生成，此限制均适用。

图 4：结账服务的依赖洞察

如果您更倾向于使用 AWS CLI，请使用以下命令代替控制台操作步骤。将 SERVICE_ARN 设置为您的服务的 ARN。

仅在依赖发现功能尚未启用时启用该功能。初始发现完成后，请查看依赖列表并生成洞察。如果已在控制台生成过洞察，请跳过 start-dependency-insights 命令，改用 get-dependency-insights 获取现有结果。

生成过程可能异步完成。如果返回状态为 IN_PROGRESS，请再次运行 get-dependency-insights。

# 如果尚未启用依赖发现功能，请启用
aws resiliencehubv2 update-service \
  --profile workload \
  --service-arn "$SERVICE_ARN" \
  --dependency-discovery ENABLED

# 查看依赖列表
aws resiliencehubv2 list-dependencies \
  --profile workload \
  --service-arn "$SERVICE_ARN" \
  --query 'dependencySummaries[].[dependencyName, location, dependencyId]' \
  --output table

# 开始生成依赖洞察
aws resiliencehubv2 start-dependency-insights \
  --profile workload \
  --service-arn "$SERVICE_ARN"

# 获取洞察；如果状态为 IN_PROGRESS，请稍后再次运行此命令
aws resiliencehubv2 get-dependency-insights \
  --profile workload \
  --service-arn "$SERVICE_ARN"

结账服务在 29 个依赖项中共生成了 5 个洞察。以下响应显示了生成的概览和所有 5 个发现结果：

{
    "overview": "针对 'checkout' 服务的 29 个依赖项共生成了 5 个洞察，揭示了跨区域、第三方依赖以及使用模式不均等问题。",
    "insights": [
        {
            "category": "CROSS_REGION",
            "description": "us-west-2 区域的 DynamoDB 跨区域访问具有高关键性，使该服务的可用性依赖于远程区域。此依赖项具有中等 DNS 查询量且使用模式稳定。"
        },
        {
            "category": "CROSS_REGION",
            "description": "PagerDuty (api.pagerduty.com) 跨区域访问 us-west-2，创建了对该远程区域的可用性依赖。"
        },
        {
            "category": "THIRD_PARTY",
            "description": "三个第三方依赖项 — example.com、example.net 和 example.org — 具有中等 DNS 查询量且使用模式稳定。"
        },
        {
            "category": "THIRD_PARTY",
            "description": "GitHub 是一个具有低 DNS 查询量的第三方依赖项。"
        },
        {
            "category": "UNEVEN_USAGE",
            "description": "两个区域内部依赖项显示每日使用率高度不均：一个 S3 存储桶 (amzn-s3-demo-bucket) 和一个 ECR 仓库 (602401143452.dkr.ecr.us-east-1.amazonaws.com)。"
        }
    ],
    "status": "COMPLETED",
    "createdAt": "2026-10-08T14:24:27.372000-05:00"
}

第一个发现指出了跨区域的 Amazon DynamoDB 依赖关系。如果结账流程需要该依赖项来接受订单，远程区域的中断可能会导致其无法正常运行，即使其 Amazon EKS 资源保持健康。服务所有者应验证哪些操作需要使用该表，并审查这些操作在表不可用时的表现。该审查将确定该依赖项是否符合恢复设计，或者是否需要调整架构。仅凭 DNS 活动无法回答这个问题。

不均衡使用发现指向容器镜像基础设施。在 Pod 启动期间下载镜像可能会产生突发的 DNS 活动。这是一个需要调查的模式，而不是证明您的应用程序存在故障的证据。

如果服务在没有依赖项时无法运行，则将依赖项分类为硬依赖；如果服务性能下降但仍能运行，则分类为软依赖。在示例环境中，我们使用以下命令将 DynamoDB 依赖项分类为硬依赖。注释描述了一个说明性故障假设，需要通过测试进行验证：

# 将选定的依赖项分类为硬依赖并记录原因
aws resiliencehubv2 update-dependency \
  --profile workload \
  --service-arn "$SERVICE_ARN" \
  --dependency-id "<dependency-id>" \
  --criticality HARD \
  --comment "结账流程将订单写入此表，没有它就无法接受订单。"

通过 AWS Organizations 共享恢复策略

在审查结账流程的依赖项后，服务所有者可以与业务部门和中央站点可靠性工程（SRE）团队一起验证其恢复需求。依赖项发现结果将为这些讨论提供信息支持，但不会自动确定策略目标。

中央 SRE 团队可以将达成一致的要求编码为恢复策略，为关键服务定义可用性和恢复目标。管理账户或委托管理员可以将该策略跨组织共享，使服务所有者能够应用集中维护的要求，而无需创建单独的副本。

策略所有者可以查看附加和分离事件以跟踪采用情况。如果某个服务停止使用策略，SRE 团队可以联系其所有者了解原因，并判断是否需要调整要求。应用程序所有者仍需负责满足目标。

策略可以结合四种目标类型：可用性、从可用区中断中恢复、从区域中断中恢复和数据恢复。恢复时间目标（RTO）指定目标恢复时间。恢复点目标（RPO）指定可容忍的数据丢失时间。

当共享功能开启时，策略会显示在每个成员账户中，与账户自身的策略并列，其 ARN 会显示拥有该策略的账户。每个服务所有者可以选择是否应用该策略。如果某个要求必须无论选择如何都适用，请将策略与包含相关服务的系统关联，如《跨账户应用恢复策略》中所述。

拥有账户可以查看服务开始或停止使用策略的时间线。关闭共享功能将停止对成员服务进行策略评估，并从使用过该策略的服务中移除它，因此需要与相关团队协调变更。

图 5：一个策略定义，与成员账户共享

组织集成是在管理账户中进行的一次性设置：

• 在 Resilience Hub 控制台中，打开 AWS Organizations 设置。

• 选择“启用受信任访问并创建服务关联角色”，然后选择“创建集成”。

确认成员账户中是否存在服务关联角色：

# 确认服务关联角色存在于工作负载账户中
aws iam get-role \
  --profile workload \
  --role-name AWSServiceRoleForResilienceHub \
  --query 'Role.Arn'

接下来，在管理账户中创建共享策略。策略名称可以包含字母、数字、连字符和下划线，但不能包含空格。以下目标仅为示例，实际值需与业务和服务负责人协商确定。本示例使用 99.9% 的可用性目标。

# 创建组织共享的弹性策略并保存其 ARN
POLICY_ARN=$(aws resiliencehubv2 create-policy \
  --profile management \
  --name tier-1-critical \
  --availability-slo '{"target": 99.9}' \
  --multi-az '{"rtoInMinutes": 5, "rpoInMinutes": 1, "disasterRecoveryApproach": "ACTIVE_ACTIVE"}' \
  --multi-region '{"rtoInMinutes": 15, "rpoInMinutes": 5, "disasterRecoveryApproach": "WARM_STANDBY"}' \
  --data-recovery '{"timeBetweenBackupsInMinutes": 60}' \
  --sharing-enabled \
  --query 'policy.policyArn' --output text)

在工作负载账户中，找到共享策略并将其应用到服务。在控制台中，选择服务的“更改策略”并选择共享策略。使用 AWS CLI：

# 列出工作负载账户中的策略（包括共享策略）
aws resiliencehubv2 list-policies \
  --profile workload \
  --query 'policySummaries[].[name, policyArn, sharingEnabled]' \
  --output table

# 将共享弹性策略应用到结账服务
aws resiliencehubv2 update-service \
  --profile workload \
  --service-arn "$SERVICE_ARN" \
  --policy-arn "<shared-policy-arn>"

图 6：已定义策略目标。这些目标的评估仍处于待处理状态

回到管理账户，策略所有者可以确认采用情况：

# 查看共享策略的服务附加事件
aws resiliencehubv2 list-policy-events \
  --profile management \
  --policy-arn "$POLICY_ARN" \
  --event-types POLICY_ATTACHED_TO_SERVICE

附加事件确认了采用情况，而非合规性。在我们应用共享策略后，控制台将每个目标从“未在策略中定义”更改为“待故障模式评估”。需要进行故障模式评估和适当的弹性测试，以确定服务是否满足这些目标。

需要了解的内容

• 共享集群。标签决定哪些 Kubernetes 对象属于某个服务。在多个工作负载共享的集群中，请按照共享 EKS 集群的指南，检查发现的依赖项是否确实属于该服务。

• DNS 基于发现的局限性。直接通过 IP 地址建立的连接无法被发现，AWS Lambda 函数需要 VPC 连接才能被覆盖，非常罕见的调用可能不会出现在初始结果中。请参阅覆盖率和已知限制。

• 时间因素。结果反映服务可用的历史记录。在对新工作负载得出结论前，请给予其时间建立历史记录。每天可以重新生成洞察一次。

清理

如果你创建了资源来尝试这些功能，请在完成时将其删除。关闭共享功能还会将策略从所有使用该策略的成员服务中移除，因此仅对演示策略执行此操作：

# 停止共享演示策略；这也会将其从成员服务中移除
aws resiliencehubv2 update-policy --profile management --policy-arn "$POLICY_ARN" --no-sharing-enabled
# 删除演示策略
aws resiliencehubv2 delete-policy --profile management --policy-arn "$POLICY_ARN"
# 删除演示 Resilience Hub 服务
aws resiliencehubv2 delete-service --profile workload --service-arn "$SERVICE_ARN"

如果你仅为了本操作指南创建了 EKS 集群，也要将其删除。

结论

从你熟悉其架构和所有权的服务开始。使用 EKS 标签检查其 Kubernetes 资源边界，然后将其依赖关系洞察与预期行为进行对比。如果多个团队各自独立维护相同的运维要求，请考虑使用共享策略。

你可以将这些功能组合使用或单独使用。标签支持适用于 EKS 工作负载。依赖关系洞察和策略共享功能也支持除 EKS 以外的服务。洞察功能聚焦调查方向，而架构审查决定需要进行哪些修改。

进一步阅读

• 下一代 Resilience Hub 的变化
• 查看发现的依赖关系
• 依赖关系洞察注意事项
• 在组织内共享策略
• 设置 Organizations 集成

作者简介

'"`