What a GPU reservation actually buys

A low hourly rate is useful only if the machines are there when the job needs them. Amazon EC2 Capacity Blocks for ML turn that scheduling problem into a purchasable reservation. AWS’s May 7, 2026 guide describes the product as a way to secure capacity for testing, model validation, workshops and planned inference demand. S1

The buyer specifies an instance type, quantity, date range and duration. Current documentation permits booking up to eight weeks ahead, with durations of one to 14 days or weekly multiples up to 182 days. The offer identifies an Availability Zone and reservation price. Once purchased, that price is fixed. S2

The commitment has edges. The reservation fee is charged upfront, and cancellation is prohibited. Operating-system charges can apply separately. Ordinary instance blocks begin shutting down 30 minutes before the reservation’s stated end; UltraServer blocks have a 60-minute cutoff. Extensions depend on available capacity, so an overrun needs a contingency plan. S2S3S4S5

For a buyer, the question is whether a dependable work window outweighs the risk of paying for idle machines. A simple illustration: if only half the purchased GPU-hours are used, the reservation cost per used GPU-hour doubles. That arithmetic excludes other costs and says nothing about model throughput. Prepare data, software and checkpoints before the paid window opens.

For an agent, the purchasing record should preserve the exact instance type, accelerator count, region, Availability Zone, start time, usable end time, currency, total fee and cancellation terms. A generic “GPU-hour” field loses the conditions that make two offers comparable.

PCT reading: Capacity Blocks show how time and delivery conditions become part of the compute product. The published rate is one supplier’s offer, not a market-wide clearing price. This review did not query live account-specific inventory or purchase a block; it establishes product mechanics, not available volume.