AWS为EC2 Capacity Manager新增实时可支持性检查和容量满足率指标：随AWS Unified Operations提供，分数只是指导而非容量承诺，博客数字来自虚构的示例公司

2026年11月4日，AWS在“What's New”发布公告，说Amazon EC2 Capacity Manager新增两项能力：实时“可支持性检查”和“容量满足率指标”。可支持性检查在不启动、不预留实例的前提下，为每种实例类型和可用区的组合打分，说明它能多大程度满足一个请求，结果是High、Medium、Low三档，外加一个整体分数。满足率指标则显示实际交付了多少容量，可以按AWS组织、账号、区域和带标签的工作负载统计，并细分到实例类型和可用区。公告称两项能力包含在AWS Unified Operations中，也就是面向运行关键业务的大型企业的AWS支持计划，并在所有商业区域可用。也就是说，它不是所有EC2用户默认可用的功能。

AWS同日发布的计算博客给出了操作细节，但它以一家名为AnyCompany的虚构公司为例，博客里的所有具体数字都是示例，不是真实客户的测量结果。使用前需要在组织层级（管理账号或委派管理员）或单个账号启用Capacity Manager，账号必须被AWS Unified Operations覆盖；若想按工作负载查看，还可以把某个标签激活为受监控的标签键。容量以vCPU计量。

满足率指标分四个请求级指标：请求的vCPU、交付的vCPU、请求满足率（交付除以请求，按vCPU加权），以及每个请求平均配置了多少个“实例类型×可用区”组合，大于1表示请求有灵活性。博客说明，同一配置在五分钟内的重试只算一次，这些指标衡量的是真实的启动，而不是检查结果的准确度。示例里，search-index工作负载请求了51,712个vCPU，得到45,632个，满足率88.2%，平均可用21个组合；batch-etl只能用一个组合，满足率72.8%。按组合单独看，满足率通常低于请求满足率，因为请求满足率包含了分散选择带来的好处：示例中28个组合各自平均只有46.6%，而整体是88.2%，差别就是灵活性带来的补充。所以整体88.2%和单个组合的46.6%不能直接比较：前者衡量请求有没有被满足，后者衡量某个组合自己交付了多少。示例里use1-az5的三个组合交付了26,880个vCPU，超过总量的一半，各自只达到68.6%到82.8%，所以那个可用区是最需要增加选项或预留容量的地方。

可支持性检查在规划阶段使用。你提供市场类型（按需或Spot）、容量数量、可用区和候选实例类型，也可以改用vCPU和内存范围让系统匹配实例类型，检查返回每个组合的High、Medium、Low以及一个整体分数。一次检查最多包含10个可用区（可来自多个区域）和100个组合。示例是为100个实例检查5种实例类型在3个可用区的情况：整体分数High，r5.16xlarge在三个区都是High，r7a.16xlarge只在use1-az6是High，r6a.16xlarge三个区都是Medium，新候选r7i.16xlarge在两个区是Medium，其余六个组合包括所有r6i.16xlarge都是Low。High表示足够满足请求且有余量，Medium表示刚好能满足，Low表示低于所请求的数量。博客把这三档的含义和“按分数该怎么做”交给EC2用户指南的对应章节，具体处理建议以用户指南为准。

博客强调了两个限制。第一，分数是指导，不是承诺；需要确保启动时一定有容量，就要使用容量预留或未来日期的容量预留。第二，检查适合在规划工作负载时做，不应在每次启动时调用，因为调用发生在启用了Capacity Manager的那个区域，逐次调用会增加跨区域依赖并耗尽每小时配额。示例还暴露了一个容易忽略的差别：r5.16xlarge在use1-az5的检查结果当下是High，但历史上实际只交付了82.8%。检查是此刻的判断，满足率是过去的事实，两者不矛盾，也不能互相替代。

把结论落到配置上，博客建议把检查通过的组合加入Auto Scaling组的混合实例策略、EC2 Fleet或Karpenter，一次配置，之后每次启动都受益，再用平均组合数指标确认变化；对必须有保障的基线容量，用按需容量预留，并按基线大小估算，因为容量预留无论是否使用都会计费。每周查看满足率、对低于目标的工作负载打开明细，并把可支持性检查加入变更管理，是它给出的日常做法。

读这则公告时要记住：它是AWS自己的产品公告和教程，示例数字不代表真实客户，没有给出检查分数与实际启动成功率之间的统计关系。是否能用，首先取决于账号是否被AWS Unified Operations覆盖。