Interruptible GPU instances cost 18% of on-demand price, practitioner account shows

A practitioner writing on dev.to reports running GPU workloads on interruptible capacity for between $0.55 and $0.70 per hour on a single-card instance that costs $3.0421 per hour on demand — roughly 18–20% of the on-demand price, or about an 80% discount.

According to the author, Rémi Etien, GPU discounts sit near the top of the range AWS advertises (up to 90% off), contrary to the common assumption that real savings land far below the marketing figure. Most published guidance concerns CPU fleets, where discounts of 55–75% are typical; GPUs are the exception.

The pricing data

The post includes a price survey taken across three regions on a single afternoon:

Instance	On demand (per hour)	Interruptible (per hour)	Share of on demand
Single card, best zone	$3.0421	$0.5503	18%
Single card, author's zone	$3.0421	$0.5996	20%
Two cards, best zone	$7.1283	$1.2721	18%
Single card, third region	$3.0421	$1.4175	47%

Two patterns stand out. On-demand pricing is identical across regions, while interruptible pricing is not: the spread between availability zones within a region was 27% in one case and 1.2% in another. Zone choice therefore matters more than region choice, and the useful question is which zone is cheap this week.

What the discount costs

The account lists three constraints in rising order of severity. First, instances can be reclaimed with two minutes' notice — familiar, and the most engineerable of the three. Second, the cheapest zone was also the one AWS itself rated lowest for available capacity; the author writes that this zone dropped the workload once, converting a few cents per hour of savings into an outage. Third, and least discussed, interruptible GPU capacity is gated by a vCPU quota. The author's limit is 64 vCPUs, and it is 64 in every region checked, so relocating does not help. A request to raise it to 128 was partially approved the same day, and increases beyond that threshold have been removed from self-service and now require a review reachable only through an account team.

The quota reshapes architecture: a two-card instance uses 48 vCPUs, and two of them would need 96, leaving no intermediate rung. The author describes scaling as choosing a fixed shape and fitting inside it rather than adding capacity incrementally. On-demand GPU quotas are set separately and varied widely across regions in this account — 64, 16 and 8 vCPUs — so the fallback path can be much narrower than the primary one, and in a different place.

Who should take the deal

Workloads that can stop and resume — checkpointed training runs, offline rendering, evaluation sweeps, data preparation — fit interruptible capacity with little more than a retry, the author argues. Live sessions with a waiting user can still benefit, but the savings must then fund the engineering that hides interruptions.

That engineering, as described, has four parts: a controller that targets a number of healthy slots rather than a specific machine or zone; a fallback ladder from a two-card instance to single-card instances to a temporary, deliberately expensive on-demand bridge; a price watcher that flags drift between zones; and a backoff schedule of 30, 60 and 120 minutes that the author warns against making more aggressive, since eager retries during a capacity shortage extend it. Because on-demand prices are identical everywhere, the bridge should run wherever on-demand quota exists, not in the primary region. During one real mid-day interruption, the setup replaced the machine, restored the slots and reattached the address in about half an hour with no human involvement.

Silent failure modes

The most instructive section concerns three bugs in which the system reported success while failing. A price watcher compared regions but not zones within a region, so a zone running about $91 per month more than its neighbour went unflagged for months while the alert stayed green. An alert topic had no subscribers, so events were delivered to nobody — a state indistinguishable from satisfied subscribers. And a cleanup job meant to shut down old instances after deliberate replacements only covered the primary region; the bug hid in production because during real interruptions AWS reclaims the old machine anyway, so it appeared only when things went well.

The author's takeaway is that once automation sits between you and the hardware, your visibility is bounded by that automation's self-reporting, which fails quietly by construction.

Why it matters

For anyone budgeting GPU training or rendering, this is concrete evidence of a roughly fivefold cost difference, together with the fine print behind it: zone-level price variance, capacity ratings that correlate inversely with price, and vCPU quotas that constrain fleet shape harder than the interruption risk itself. The data comes from one user's account and a single afternoon of pricing, so treat the figures as indicative rather than universal. The operating lessons generalise further than the numbers: measure at the grain where cost actually varies, and treat your automation's green lights as meaning only what its checks can see.