Capacity Blocks amortization: what it means for GPU cost

On November 6, 2026, AWS announced amortization for EC2 Capacity Blocks for ML. The upfront fee for a Capacity Block used to show up as one large charge on the day you bought it. Now AWS Data Exports for Cost and Usage Report (CUR) 2.0 and AWS Cost Explorer can spread that fee across the length of the reservation. If you rent GPUs by the block and split the cost between teams or products, your reports can now line up with when the GPUs were available. This post covers what changed, who should care, and what we would check first.

What did AWS announce?

According to the announcement, CUR 2.0 and Cost Explorer now show the Capacity Block upfront fee spread over the reservation's duration, instead of as a single charge on the purchase date. You can see the amortized cost of each instance launched into a block, and the amortized cost of capacity that went unused.

AWS says this helps you allocate GPU costs to teams, projects and applications, find unused capacity, and plan future purchases. It is available at no additional charge in all AWS Regions except the AWS GovCloud (US) Regions and the China Regions (as of November 2026).

How were Capacity Blocks billed before?

A quick refresher from the pricing and billing page of the EC2 User Guide:

• The price depends on supply and demand when you buy, and it does not change after you reserve.
• The whole price is charged up front. Payment is billed within 5 minutes to 12 hours after purchase.
• When the block starts, you are billed only for the operating system while instances run (AWS says you see a usage charge only if you use a premium operating system). There is no additional charge for unused time.
• Savings Plans and Reserved Instance discounts do not apply to Capacity Blocks.
• The upfront payment appears in the month you purchased the block. If the block starts in a later month, the fee and the usage land in different billing months.

That last point is the pain. A team that trains a model in January can show a cost spike in December, when the block was bought. Chargeback by month, by team or by product then points at the wrong period.

1. 1Buy block
2. 2Upfront fee billed
3. 3Block starts
4. 4Usage and unused time

Based on the EC2 User Guide, November 2026. With amortization, the upfront fee is also spread across the block.

What actually changed in the data?

The announcement names three CUR 2.0 columns:

• reservation_amortized_upfront_fee_for_billing_period
• reservation_effective_cost
• reservation_net_effective_cost, described as the amortized cost after discounts

In Cost Explorer, you pick the amortized cost view. The Cost Explorer guide explains that amortized costs spread the cost of commitments, such as Reserved Instances or Savings Plans, across the usage of the selected period. AWS says the same amortized view now shows Capacity Block costs.

1. SourceCapacity Block upfront fee
2. SpreadAcross the reservation's duration
3. CUR 2.0Amortized and effective cost columns
4. Cost ExplorerAmortized cost view

As described in the AWS announcement of November 6, 2026.

Here is an illustrative example. Numbers are made up and are not a benchmark. Say a block costs 14,000 dollars, paid on December 20, and runs for 7 days starting January 5. Before, December showed 14,000 dollars. With amortization, the fee is spread across the 7 days of the reservation, so each day would carry roughly 2,000 dollars if it is spread evenly, and the cost lands in the month when the GPUs were available. Unused hours still cost you, but now the report puts a cost on that unused time.

Who should care, and who can ignore it?

Pay attention if you:

• Train or fine-tune models on P5, P6 or Trainium instances using blocks, and bill the cost back to teams or customers.
• Run showback for AI work and need monthly numbers that match when the work happened.
• Want to know how much of a block you actually used before you buy the next one.
• Report GPU spend to finance or investors and need a stable monthly trend.

You can ignore it if you only run GPU instances On-Demand, or if all your AI inference goes through a managed model API. It also does not apply to Capacity Blocks in GovCloud or China Regions.

How would a team try it safely this week?

This is a reporting change. You do not need to touch a running workload. A reasonable plan:

1. Find your blocks. List your Capacity Blocks and their start and end dates. The EC2 User Guide notes blocks can start up to 8 weeks in the future, so some purchases sit in a different month from their use.
2. Check your export. In Data Exports, confirm you have a CUR 2.0 export. If your finance tools still read the legacy CUR, find out how they will get the new columns.
3. Open Cost Explorer. Switch to the amortized cost view, group by usage type or tag, and compare it with the unblended view.
4. Compare one block. The announcement does not say whether blocks bought before the launch are shown amortized, so check your data. Use a block you already have if it is, or the next one you buy if not, and check that the amortized total matches the upfront fee you paid. If it does not, ask AWS Support before you change any report.
5. Update the chargeback query. Point it at the amortized columns, and keep the old numbers side by side for one month-end.

What would we check first before adopting it?

We would start with the questions that make or break a chargeback model:

• Tagging. Can you tie a block, or the instances inside it, to a team? Cost allocation tags only help once they are activated, and AWS says they can take up to 24 hours to appear. Check the AWS Billing guide for details.
• Who pays for unused time. Amortization shows the cost of unused capacity. It does not say who owns it. Decide in advance whether the team that bought the block, or a shared platform budget, absorbs it.
• Account structure. The EC2 guide has a page on sharing Capacity Blocks. AWS says the owner account pays the upfront fee, while consumer accounts pay only the operating system charges for instances they run. So the owner carries the block cost unless you allocate it back, for example by tag or by usage per account.
• Cash versus accrual. Finance still pays the full fee up front. Amortized views are for allocation, so keep the cash view for payment forecasts.
• Utilization. Use the unused-capacity cost as a metric. If a team keeps leaving a large share of its block idle, the fix may be a shorter block or better job scheduling, not a bigger budget.

If you want a second pair of eyes on how GPU spend is allocated, our cloud and AI services cover this kind of review.

This post is general information, not financial, accounting or legal advice. Check pricing and report behavior in your own AWS account.