--- title: "Fully Used Savings Plans Can Leave AI Compute Usage Uncovered" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/ai-compute-savings-plan-utilization-coverage" last-updated: "2026-10-20" --- # Fully Used Savings Plans Can Leave AI Compute Usage Uncovered Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. An AWS Savings Plan can show 100% utilization while covering only part of the eligible compute usage. Utilization measures consumed monetary commitment; coverage measures eligible usage at its On-Demand-equivalent cost. Read both amounts, their rate bases and their reporting scope before using either percentage to support a commitment decision. Neither percentage measures GPU activity or the discount on the whole AI platform bill. ## Identify what the utilization percentage divides For an AI platform buyer, a report showing a fully used Savings Plan can look like evidence that the commitment fits the workload. It establishes a narrower fact: eligible usage consumed the purchased monetary commitment during the reported period. Additional eligible usage may still have been charged at On-Demand rates. The AWS Billing and Cost Management API defines UsedCommitment as commitment consumed by eligible usage, UnusedCommitment as the unconsumed amount, and TotalCommitment as the purchased amount. UtilizationPercentage uses UsedCommitment divided by TotalCommitment. Expressed as a percentage, utilization is 100 x used commitment / total commitment. The denominator is money committed over the selected period. It is not GPU count, device busy time or the workload's theoretical throughput. For the separate activity-counter question, use GPU Utilization and Data Center Occupancy. The distinction matters even when the same platform appears in both reports: a running resource can consume a billing benefit without establishing how much useful work its GPUs completed. References: [S1](https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_SavingsPlansUtilization.html) ## Keep coverage on its On-Demand-equivalent basis AWS's Savings Plans coverage calculation values the usage receiving the benefit at its On-Demand-equivalent cost. Coverage is 100 x that covered amount / (that covered amount + eligible usage billed at On-Demand rates). Both parts of the denominator therefore use the On-Demand basis. The amount of commitment consumed is not the covered numerator in that calculation. If covered usage has an On-Demand-equivalent value of 10 cost units but consumes 6 cost units of commitment, substituting 6 for 10 mixes rate bases. The usage population has not changed; the valuation has. These are the named AWS definitions checked October 20, 2026. Establish the actual plan, eligible products and account population before applying them to an AI budget. A product described as AI compute does not, by that description alone, establish eligibility, and this article identifies no currently eligible GPU SKU. The same formulas should not be assumed for another vendor's similarly named report. References: [S2](https://docs.aws.amazon.com/savingsplans/latest/userguide/ce-sp-cr-metrics.html) ## Follow the benefit until the hour's commitment runs out AWS applies Savings Plans to eligible usage until the available commitment or usage is exhausted. Remaining usage is charged at On-Demand rates. Its application rules also account for Reserved Instances, different plan types, account sharing and relative savings rates. A real account with several benefits cannot be reconstructed from one plan's headline percentage. Each hour's commitment belongs to that hour and cannot carry over. The purchased monetary commitment is distinct from the amount consumed; AWS's payment options charge the commitment upfront, monthly or through a combination. An unused portion is therefore not a reduction in the purchased amount. The comparison below isolates this mechanism with one hypothetical plan and one eligible usage family in one account. There are no Reserved Instances, other plans, sharing, credits, taxes, support charges or other fees. All illustrated usage is stipulated eligible. This keeps the utilization and coverage populations compatible without supplying a rule for allocating benefits across a real organization. References: [S3](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-applying.html), [S4](https://aws.amazon.com/savingsplans/faqs/) ## Compare three hours with the same 6 CU commitment Use fictional cost units, abbreviated CU, with no currency or current provider price. The commitment is 6 CU per hour. Each eligible unit-hour consumes 3 CU of commitment when covered; its On-Demand-equivalent cost is 5 CU. The plan can therefore cover 6 / 3 = 2 unit-hours in each hour. Stipulate two identical unnamed compute units running throughout hour A, four throughout B and one throughout C. These produce 2, 4 and 1 unit-hours respectively. They describe resource-time in this illustration, not GPU kernel activity, useful output or an actual instance configuration. Rates and the purchased commitment stay fixed while the amount of resource-time changes. In hour A, 2 unit-hours consume 2 x 3 = 6 CU. Used commitment is 6 CU and unused commitment is zero, giving 6 / 6 = 100% utilization. The covered usage is worth 2 x 5 = 10 CU on the On-Demand basis. No eligible usage remains uncovered, so coverage is 10 / (10 + 0) = 100%. In hour B, 4 unit-hours would require 12 CU to cover at the stipulated benefit rate. Only 6 CU is committed, so 2 unit-hours receive the benefit and 2 remain On-Demand. Used commitment is again 6 CU, producing the same 100% utilization as A. Covered usage is worth 10 CU on the On-Demand basis and uncovered usage costs another 10 CU. Coverage is 10 / (10 + 10) = 50%. Resource-time doubled; the commitment and the amount it could cover did not. In hour C, 1 unit-hour consumes 3 CU. The purchased commitment is still 6 CU: 3 CU consumed and 3 CU unused. Utilization falls to 3 / 6 = 50%. Yet all of the hour's eligible usage receives the benefit. Its On-Demand-equivalent value is 5 CU and coverage is 5 / (5 + 0) = 100%. A and B show why complete commitment consumption does not establish complete coverage. A and C show why complete coverage does not establish complete commitment consumption. The lower utilization in C follows from less eligible resource-time against the unchanged commitment; it does not show worse GPU efficiency. References: [S1](https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_SavingsPlansUtilization.html), [S2](https://docs.aws.amazon.com/savingsplans/latest/userguide/ce-sp-cr-metrics.html), [S3](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-applying.html) ## Aggregate the amounts before comparing percentages Across A, B and C, purchased commitment is 6 + 6 + 6 = 18 CU. Used commitment is 6 + 6 + 3 = 15 CU, leaving 3 CU unused. Period utilization is 15 / 18 = 83.33%, rounded to two decimal places. Covered usage has an On-Demand-equivalent value of 10 + 10 + 5 = 25 CU. Uncovered eligible usage is 0 + 10 + 0 = 10 CU. Coverage for the same three-hour population is therefore 25 / (25 + 10) = 71.43%. An unweighted mean of the hourly coverage percentages gives (100% + 50% + 100%) / 3 = 83.33%. That gives each hour equal weight. Period coverage instead weights the hours by their eligible On-Demand-equivalent amounts: 10 CU in A, 20 CU in B and 5 CU in C. B's lower coverage applies to the largest amount, so it contributes more to the combined result. The unweighted mean answers a different question. The mean hourly utilization happens to equal period utilization here because all three hours have the same 6 CU commitment denominator. That coincidence does not make averaging percentages a general reconciliation method. Preserve the underlying amounts and calculate the relevant ratio from their sums. AWS's coverage report uses selected filters and a lookback period, with hourly, daily or monthly views. Keep those selections attached to a comparison. In the fictional arithmetic, A and C together have 100% coverage. Quoting that narrower result would leave out B's uncovered peak even though no resource-time, rate or benefit changed. References: [S1](https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_SavingsPlansUtilization.html), [S2](https://docs.aws.amazon.com/savingsplans/latest/userguide/ce-sp-cr-metrics.html) ## Separate coverage from the modeled cost reduction The three-hour coverage result is 71.43%. It is not a 71.43% discount. Coverage describes which eligible usage received the benefit, using On-Demand-equivalent values. A cost comparison must also include the commitment that was purchased, including its unused part. In this model, all 7 unit-hours at the stipulated On-Demand rate would cost 7 x 5 = 35 CU. With the plan, the included compute-cost basis is the full 18 CU commitment plus 10 CU of uncovered usage, or 28 CU. The modeled reduction is (35 - 28) / 35 = 20%. The stipulated unit-rate reduction for usage receiving the benefit is (5 - 3) / 5 = 40%. Covered usage worth 25 CU consumes 15 CU of commitment, creating a 10 CU difference on that subset. The unused 3 CU commitment reduces that difference to 7 CU across the whole example. Thus 40% unit-rate reduction, 71.43% coverage and 20% overall modeled reduction are three different results from the same inputs. Using only the 15 CU of consumed commitment plus the 10 CU uncovered amount would produce 25 CU and omit 3 CU still purchased. Conversely, applying the 40% unit reduction to all 35 CU would incorrectly treat every unit-hour as covered. The 28 CU comparison includes both gaps. It remains an original simplified compute-cost illustration under the stated exclusions, rather than an invoice reconstruction or a forecast of actual AWS savings. ## Use the gap to frame the commitment decision High utilization alongside lower coverage points to eligible usage left at On-Demand rates in the selected population. The next question is whether that uncovered demand recurs in the hours relevant to the proposed commitment, with the same eligibility and rate basis. B supplies an observed gap within the fictional example; it supplies no evidence about future hours. High coverage alongside lower utilization points to purchased commitment left unconsumed. C's complete coverage does not make the unused 3 CU disappear. Before interpreting a real result, the billing and platform owners need to establish whether the pattern reflects less demand, a changed eligible mix or a different reporting population. The three-hour totals contain both unused commitment and uncovered usage. They cannot be netted into a reusable balance. If a C-like quiet hour occurred before a B-like peak, its unused 3 CU could not be moved forward to cover the later usage. An additional recurring hourly commitment might cover more of a B-like peak while leaving more unused in a C-like trough. Neither percentage determines the appropriate commitment amount. A useful explanation of a held or proposed plan ties its named scope and hourly amount to the eligible usage, applied benefits, unused amount and uncovered On-Demand amount over consistent intervals. Retain the actual rates, reporting filters and data period. A prospective case additionally needs supported demand assumptions; historical percentages alone do not establish a future optimum or justify an automatic increase or cancellation. Keep adjacent decisions with their existing owners. Capacity Reservation or Savings Commitment addresses what the pricing and capacity products supply. GPU Cloud Availability addresses quota, allocation and usable windows. Shared AI Platform Cost Allocation addresses how costs are attributed internally. None of those questions is settled by this report's utilization or coverage percentage. References: [S3](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-applying.html) ## Take the next question to its owner For this decision, ask the customer's billing and platform owners to reconcile commitment consumption with covered and uncovered eligible usage on the same reporting basis. Their answer should explain the gap that matters to the proposed commitment, rather than substituting a high percentage for the underlying amounts. If the wider program separately includes installing customer-owned equipment in colocation, Leviathan's Colocation Infrastructure Installation service addresses agreed customer-side equipment fit-out, IT cabling and installation records. Use the related project inquiry with a nonconfidential outline of the equipment, facility, access requirements and intended physical handoff. That inquiry concerns the physical project; cloud commitment analysis remains with the selected provider and the customer's responsible teams. References: [L1](https://www.leviathansystems.co/services/colocation-installation) ## Primary sources - [S1 — AWS Billing and Cost Management API Reference - SavingsPlansUtilization](https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_SavingsPlansUtilization.html). Checked 2026-10-20. Definitions of TotalCommitment, UsedCommitment, UnusedCommitment and UtilizationPercentage for the reported period. These measure monetary commitment consumption; they supply no hardware-activity measurement. - [S2 — AWS Savings Plans User Guide - Understanding coverage metrics and calculations](https://docs.aws.amazon.com/savingsplans/latest/userguide/ce-sp-cr-metrics.html). Checked 2026-10-20. Named AWS coverage formula, On-Demand-equivalent valuation, selected filters, lookback period and reporting granularity. The original arithmetic uses one fixed eligible population; the definition is not generalized to other vendors. - [S3 — AWS Savings Plans User Guide - Understanding how Savings Plans apply to your usage](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-applying.html). Checked 2026-10-20. Eligible-usage application, ordering and sharing context, remaining On-Demand usage and the restriction against carrying commitment between hours. AWS's illustrative prices are not used; the article stipulates its own fictional units and rates. - [S4 — AWS Savings Plans FAQs - Commitment and payment options](https://aws.amazon.com/savingsplans/faqs/). Checked 2026-10-20. Hourly monetary commitment, plan-dependent applicability and upfront/monthly payment options. No advertised savings percentage, product eligibility or current rate is adopted. - [L1 — Leviathan Systems - Colocation Infrastructure Installation](https://www.leviathansystems.co/services/colocation-installation). Checked 2026-10-20. Agreed customer-side physical equipment installation, IT cabling, installation records and the existing project-inquiry route. Hosting and facility services remain with the colocation provider. ## Related Leviathan resources - [Capacity reservation or Savings Plan: availability and pricing commitments](/articles/gpu-cloud-capacity-reservation-versus-savings-commitment) - [GPU cloud availability: quotas, allocations and usable windows](/articles/gpu-cloud-capacity-availability) - [GPU utilization and facility occupancy: activity and space measurements](/articles/gpu-utilization-vs-facility-occupancy) - [Shared AI platform cost allocation: team attribution and the resource bill](/articles/shared-ai-platform-cost-allocation-versus-resource-bill) - [Customer-side colocation equipment installation](/services/colocation-installation) - [Discuss a separate physical equipment installation project](/contact?service=colocation-installation&from=%2Farticles%2Fai-compute-savings-plan-utilization-coverage) ## Have a separate colocation installation project? Share the customer equipment, facility, access requirements and intended physical handoff to discuss installation scope, requirements and availability. [Discuss the scope](/contact?service=colocation-installation&from=/articles/ai-compute-savings-plan-utilization-coverage)