AWS adds cost allocation for reserved GPU Capacity Blocks
AWS has added amortized cost reporting for EC2 Capacity Blocks for ML. Its November 6 announcement says Cost Explorer and Cost and Usage Report 2.0 now allocate reservation fees across used and unused capacity. AI infrastructure teams can use that breakdown to understand what their reserved GPUs actually cost to use.
The payment still happens upfront
The EC2 billing guide says a Capacity Block’s price is fixed when reserved and charged upfront. Operating system charges are separate. Savings Plans and Reserved Instance discounts do not apply to Capacity Blocks.
That matters when a reservation is purchased in one month and used in another. The invoice records the payment, while an amortized view helps attribute the expense to the period of use. A smoother cost chart does not change the amount paid or make unused capacity free.
AWS already records used and unused reservation time separately. Its billing guide says unused time carries no additional charge. That means no extra charge on top of the reservation fee, rather than a refund of the prepaid amount. The purchase documentation also says Capacity Blocks cannot be canceled after reservation.
Where to find the new cost information
AWS names three CUR 2.0 fields: reservation_amortized_upfront_fee_for_billing_period, reservation_effective_cost and reservation_net_effective_cost. The last reflects applicable discounts. Cost Explorer exposes the allocation through its amortized cost view. The feature is available at no additional charge in all AWS regions except GovCloud and China.
The capacity reservation data dictionary documents separate fields for the reservation identifier, its status and its type. Status values distinguish used and unused capacity, while the type identifies EC2 Capacity Blocks for ML separately from On-Demand Capacity Reservations. These identification fields help keep different reservation products apart when reviewing exports.
The CUR 2.0 table guide says INCLUDE_CAPACITY_RESERVATION_DATA adds those reservation fields and finer detail when an instance uses multiple reservations within an hour. INCLUDE_RESOURCES separately adds resource-level granularity and the resource identifier. Both can make an export larger. Inspect the current export schema before assuming a dashboard contains the fields needed to join costs to workloads.
How to interpret unused GPU capacity
Consider a hypothetical research team that reserves a cluster for a training run. Data preparation slips, leaving part of the booking idle. A useful internal report would show the reservation expense associated with the run and a separate unused-capacity amount. Assigning the whole booking to completed experiments can conceal the cost of that delay.
These billing records distinguish reservation consumption from unused capacity. An instance can occupy reserved capacity while its GPUs do little useful work, so application or GPU telemetry is still needed to measure computational utilization.
Keep the reservation identifier, usage window and workload owner together in that review. Decide who owns idle time before comparing projects: the model team, a central infrastructure budget or another agreed cost center. That is an internal allocation decision, not something a billing column can settle.
Cost Explorer also has a reporting delay. Its documentation says costs generally reflect usage through the previous day, and some current-period data can arrive later than 24 hours. Treat the report as cost analysis rather than a live GPU utilization monitor. A missing current-day entry is insufficient evidence that a reservation was unused.
Shared capacity needs an explicit accounting policy
According to the Capacity Block sharing guide, the owning account pays the reservation fee. Consumer accounts pay operating system charges for their running instances, but are not billed for the shared reservation itself. Sharing is limited to accounts within the same AWS Organization and does not support UltraServer Capacity Blocks.
Teams using shared capacity should check who is billed before interpreting a consumer account’s low spend as cheap compute. Internal allocation should reconcile back to the owner’s reservation payment and include idle capacity, rather than counting the same upfront fee twice.
What to check before the next reservation
Start with one completed reservation and reconcile its payment, usage and unused-capacity records. Then compare useful workload output with the full cost. For teams evaluating infrastructure suppliers, our Google Cloud A5X availability guide covers another reservation-based GPU offering and the limits to check alongside hardware specifications.
This article is based on AWS’s announcement and documentation. ByteForward has not tested the new reporting fields in a customer account or measured savings from them.
Featured image: AI-generated conceptual editorial illustration by ByteForward using the official AWS mark from Amazon Press Center. AWS is a trademark of Amazon.com, Inc. or its affiliates. Independent coverage, not an AWS endorsement.
