AWS Adds Real-Time Supportability Checks and Fulfillment Metrics to EC2 Capacity Manager, Included With AWS Unified Operations: Scores Are Guidance, Not Capacity Commitments, and Blog Figures Come From a Fictional Company

On November 4, 2026, AWS posted a What's New announcement saying that Amazon EC2 Capacity Manager gains two capabilities: real-time supportability checks and capacity fulfillment metrics. A supportability check scores each combination of instance type and Availability Zone for how well it can support a request, without launching or reserving instances, with a High, Medium or Low score for each option plus an overall score. Fulfillment metrics show how much capacity was actually delivered, by AWS organization, account, Region and tagged workload, with a breakdown by instance type and Availability Zone. AWS says both are included with AWS Unified Operations, the AWS Support plan for global enterprises running mission-critical workloads, and are available in all commercial Regions. So this is not a default feature for every EC2 user.

The AWS Compute Blog published the same day gives the operating detail, but it follows a fictional company called AnyCompany, so every specific number in it is an example, not a measurement of a real customer. To use the features, you turn on Capacity Manager at organization level, from the management account or a delegated administrator, or for a single account, and the account must be covered by AWS Unified Operations. To see metrics by workload you can activate a tag as a monitored tag key. Capacity is measured in vCPUs.

Fulfillment has four request-level metrics: requested vCPUs, fulfilled vCPUs, request fulfillment rate (fulfilled divided by requested, weighted by vCPU) and the average number of instance type by Availability Zone combinations each request is configured to use, where a value above 1 means the request is flexible. The blog notes that retries within five minutes for the same configuration count once, and that the metrics measure actual launches, not the accuracy of a check. In the example, the search-index workload requested 51,712 vCPUs and received 45,632, an 88.2 percent request fulfillment rate, with an average of 21 combinations to use. The batch-etl workload could use only one combination and fulfilled 72.8 percent. Per-combination rates are usually lower than the request rate, because the request rate includes the benefit of diversification. In the example, 28 combinations average 46.6 percent on their own while the request reaches 88.2 percent, and the gap is what flexibility adds. The three use1-az5 combinations delivered 26,880 vCPUs, more than half of the total, at only 68.6 to 82.8 percent each, so that zone is where to add options or reserve capacity.

Supportability checks belong to planning. You give the market type (On-Demand or Spot), the capacity amount, the Availability Zones and the instance types to consider, or you give vCPU and memory ranges and let the service match types. The check returns High, Medium or Low for each combination plus an aggregate score, and one check can include up to 10 Availability Zones, possibly from more than one Region, and up to 100 combinations. The example checks 100 instances of five types across three zones. The aggregate score is High. r5.16xlarge scores High in all three zones, r7a.16xlarge scores High only in use1-az6, r6a.16xlarge scores Medium in all three, the new candidate r7i.16xlarge scores Medium in two zones, and the other six combinations, including every r6i.16xlarge, score Low. High means a combination holds more than enough for the request, Medium means it can cover it with little to spare, and Low means it holds less than asked.

The blog states two limits. First, scores are guidance, not commitments; if you need assurance that capacity will be there at launch, use Capacity Reservations or future-dated Capacity Reservations. Second, run the check when you plan a workload, not on every launch, because the call goes to the Region where Capacity Manager is turned on, and per-launch calls would add a cross-Region dependency and use up the hourly quota. The example also exposes a difference that is easy to miss. r5.16xlarge scores High in use1-az5 right now, yet historically it delivered only 82.8 percent there. The check is a judgment about the present, the fulfillment rate is a fact about the past, and neither replaces the other.

For configuration, the blog suggests adding the combinations that pass the check to an Auto Scaling group mixed instances policy, an EC2 Fleet or Karpenter, so that flexibility is set once and every later launch benefits, then confirming the change with the average combination count. For baseline capacity that needs certainty, it suggests an On-Demand Capacity Reservation sized to the baseline, because reservations are billed whether or not they are used. Its routine advice is to review fulfillment rates weekly, open the breakdown for any workload below target, and add a supportability check to change management.

Keep in mind that this is AWS's own product announcement and tutorial. The example numbers do not represent real customers, the sources give no statistical link between check scores and actual launch success, and whether you can use the features depends first on whether your account is covered by AWS Unified Operations.