Summary

  • Oracle's capacity-reservation page binds a reservation to a single availability domain inside a tenancy and to a shape, with a fault domain as an option; an instance only counts against a reservation sitting in its own availability domain, and the same page states the capacity types are mutually exclusive.
  • Preemptible capacity is documented as reclaimable at any time, with no guaranteed minimum holding period, and a preemption event fired two minutes before termination begins.
  • Availability domains and fault domains are described as isolation and co-location units, not as capacity pools — and none of the five pages read on 19 October 2026 states a reservation term, a price, or any exclusion of accelerated shapes.

What a reservation actually names

The Capacity Reservations page is unusually concrete about the object it creates. "When you create your capacity reservation, you specify the availability domain in the tenancy where you want to reserve capacity," it states, and the amount and the machine type are settled in a second step: "You can then add a capacity configuration, which defines the amount of space that you want to reserve and the shape to use when creating instances against that capacity configuration."

Two further sentences sharpen the boundary. The fault domain is optional — "Optionally, you can specify the fault domain to reserve capacity in" — and the reservation is a container rather than a single allotment: "Each capacity reservation can have multiple capacity configurations."

The Launching an Instance page closes the loop from the other side, because a reservation only bites where placement matches: "To create an instance and have it count against a capacity reservation, you must have a capacity reservation in the same availability domain as the instance." The same page adds the sentence that most capacity planning never reads: "The capacity types are mutually exclusive."

Put together, the instrument has coordinates. Not a region, not an account, not a shape family. One availability domain, one tenancy, and per configuration a named shape with an amount attached. Oracle's own page summaries go further and describe reservations as unable to span regions or move between availability domains or tenancies — but that is a summary statement rather than a quoted line, and it matters enough to keep the distinction visible.

The two-minute signal is not a promise

The Preemptible Instances page is equally plain about what the cheap tier is. Preemptible instances "behave the same as regular compute instances, but the capacity is reclaimed when it's needed elsewhere, and the instances are terminated." The page does not soften that into a retention window: "The capacity is not guaranteed for a minimum amount of time, so instances can be reclaimed at any time."

The operational mechanic follows in one sentence: "An instancepreemptionaction event is emitted two minutes before the instance termination begins." Two minutes is a signal in a termination sequence. It is not a minimum runtime, not a reinstatement promise, and not a substitute for a restart path that a team has actually built and timed. A workload that treats the event as continuity insurance has misread the document.

There is a second scoping fact here that bears directly on planning. Preemptible capacity and reserved capacity are not interchangeable quantities, because the page's own limitation list places capacity reservations among the features preemptible instances cannot use — and the launching page states flatly that the capacity types are mutually exclusive. A plan that assumes it can fall back from one to the other is assuming a migration the pages do not describe.

Isolation is not capacity

The Regions and Availability Domains page is where reading discipline matters most, because its language is strong and its subject is failure, not supply. "Availability domains are isolated from each other, fault tolerant, and very unlikely to fail simultaneously," it states. It then defines the inner unit: "A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain contains three fault domains. Fault domains provide anti-affinity: they let you distribute your instances so that the instances are not on the same physical hardware within a single availability domain."

That is a co-failure statement with a placement rule attached, and it is genuinely useful: three fault domains per availability domain gives a designer somewhere to spread replicas. But it says nothing about whether capacity exists for those replicas, in which shape, or on what terms. Isolation and capacity are orthogonal layers, and the fact that a design survives the loss of one fault domain is not evidence that it can rebuild inside another at the moment it needs to.

What the pages do not say

Three boundaries are worth stating as precisely as the findings.

First, no term. None of the pages read states how long a capacity reservation lasts, how it renews, or what happens at its end. The scoping statements are eligibility rules; they are not commitment language, and calling a reservation a contracted guarantee would go beyond anything here.

Second, no price and no supply position. The preemptible page never says preemptible capacity is cheaper than on-demand, and the reservation page states no price at all. Separately, the summaries describe capacity as allocated when the reservation is created, with a shortfall request created at the maximum amount possible. That is a provisioning behaviour, not an inventory measurement, and it should not be dressed up as a scarcity claim about any shape or region.

Third, no shape-family exclusion. The five pages read include the Compute Overview page, which is described as listing on-demand, preemptible, reserved and dedicated capacity — but that page returned no verbatim passage, so its list cannot be quoted here, and nothing in the material read states that accelerated or GPU shapes are excluded from preemption or from reservation. Silence is not inclusion. The honest position is that the question remains open on this evidence.

Why the distinction bites at scale-out

The control surface is not technical trivia; it is who reads which page. Architects, procurement teams and investors routinely encounter a region count and a shape catalogue, and both are easy to consume as statements about obtainable capacity. The sentences that decide whether capacity is in fact obtained — reservation scope, the same-availability-domain rule, mutual exclusivity, the absence of a hold on preemptible instances — sit in separate reference pages that a catalogue reader has no reason to open.

The failure mode follows mechanically. A training or serving plan is sized in aggregate, as though a region were a pool. The instrument is scoped to one availability domain and one shape. When the workload scales out, the jobs that land outside the reservation's availability domain do not count against it, and the preemptible capacity that was going to absorb the overflow carries no minimum lifetime at all. Nothing in the catalogue changed. The shortfall arrives at the expansion step, which is the one step that cannot be paused cheaply.

That is the practical weight of these pages: they do not report Oracle's capacity position, and they are not meant to. They define the shape of the instrument a customer holds, and in doing so they tell a planner exactly which denominator its plan is not entitled to use. Background on the operator sits in the Oracle Cloud directory entry.