OCI Compute Pricing Deep Dive: Shapes, OCPUs, and Burstables

On most clouds, compute pricing is a menu problem: hundreds of fixed instance types, each bundling cores, memory, and a price, and your job is to find the least bad fit. OCI replaced the menu with dials. Flexible shapes let you specify an exact OCPU count and an exact memory amount, billed as two separate meters, across processor families with genuinely different price points. The result is that the cheapest configuration that fits your workload is almost always available, and finding it is a method rather than a search. This article is that method.

It builds on the unit fundamentals in OCI pricing explained and feeds the bigger model in our complete guide to OCI pricing and TCO. The one fact to carry in from those articles: an OCPU is a full core, two vCPUs worth, and every sizing decision starts there.

The shape families and what they cost

OCI compute concentrates into three processor families, each with a clear role. The figures below are list prices at the time of writing and worth confirming against the current price list, but the relationships between them are stable.

The headline inside that table is Ampere. At roughly a third of the AMD per OCPU rate, the A1 family is the cheapest mainstream compute on the platform, and for the large class of workloads that are architecture neutral, containerized services, web applications, Java backends, most open source databases, the discount is nearly free money. The constraint is software compatibility, and it is a real constraint: commercial software with x86 only builds, and any Oracle licensed software you intend to run under BYOL terms, needs checking before the migration, not after.

Flexible shapes: pay for the ratio you need

Because OCPUs and memory bill separately, the bundled ratios of fixed instance clouds stop dictating your spend. A memory hungry cache can take 2 OCPUs and 96 GB. A CPU bound encoder can take 32 OCPUs and 64 GB. In migrations from AWS or Azure we routinely find fleets sized to an instance type's ratio rather than the workload's, and unbundling that ratio on OCI is one of the most reliable savings in the first optimization pass. The discipline is to size both dials from measurement: CPU from observed utilization with honest headroom, memory from the working set, not from what the old instance happened to include.

Burstable instances: pay the baseline, keep the ceiling

Burstable shapes let you provision a full OCPU but pay for a baseline of either 12.5% or 50% of it, with the instance free to burst to the full core when load arrives, and the meter following actual utilization above the baseline. For the enormous population of services that idle most of the day, internal tools, low traffic APIs, agents, schedulers, the 12.5% baseline prices the instance at a fraction of a full core, and the bursting covers the moments that matter. The fit test is the utilization graph: a flat line under the baseline with occasional spikes is a burstable candidate, while sustained load above the baseline belongs on a standard shape, where the same capacity is cheaper.

Preemptible capacity: half price for interruptible work

Preemptible instances run at 50% off the standard rate, with the trade that OCI can reclaim them with a short notice. Batch processing, CI runners, rendering, stateless workers behind a queue, and fault tolerant analytics all absorb that trade comfortably. The pattern that works is a small core of standard instances for continuity plus a preemptible pool for throughput, scaled by the queue. Work that cannot checkpoint or tolerate interruption should simply not apply; the discount is payment for the interruption risk, and pretending the risk away converts the discount into incidents.

A seven step shape selection framework

Instance pools, autoscaling, and the meter

The pricing dials get more valuable when something turns them automatically. Instance pools with autoscaling adjust the fleet against schedules or metrics, and on OCI the per second billing means scale in events convert to savings within minutes rather than at the next hour boundary. The practical patterns are unglamorous and reliable: web fleets scaled on CPU with a floor sized to the overnight trough rather than the daily peak, worker fleets scaled on queue depth with preemptible instances taking the elastic share, and non production pools on hard schedules that stop entirely outside working hours. None of this requires architectural change, only configuration, which makes it first week work in any optimization engagement. The common failure is setting the floor from fear rather than from the utilization graph, which quietly converts an autoscaling fleet back into a static one with extra steps.

Bare metal economics

Bare metal shapes price as whole nodes at the same per OCPU economics as the equivalent VM family, so the premium you pay is granularity, not rate. A 128 core bare metal node costs about what 128 flexible OCPUs cost, the difference is that you buy all of them at once. That makes bare metal economically rational in three cases: workloads that genuinely consume the node, licensing strategies that benefit from full host isolation, and performance profiles that cannot tolerate a hypervisor. Estates that default to bare metal for comfort pay the granularity cost on every partially idle node, which is exactly the waste flexible shapes exist to remove. The honest test is utilization at the node level, and the honest answer for most general purpose workloads is the VM.

A worked fleet resize

A composite from recent engagements makes the method tangible. A 40 VM estate arrives from a lift and shift sized at source platform labels: mostly 8 vCPU instances translated as 8 OCPUs each, 320 OCPUs of E5 at roughly $7,000 a month. The measurement pass tells a different story. Conversion at two vCPUs per OCPU halves the baseline to 160 OCPUs. Utilization data cuts a further third from the steadily underloaded half of the fleet. Twelve services prove Arm clean and move to Ampere at a third the rate. Nine internal tools fit burstable baselines. The non production half of the fleet picks up stop schedules. The arithmetic lands the same estate near $2,300 a month, a 67% reduction, with no application change and no performance regression, verified over a quarter of monitoring. Not every estate carries this much slack, but the direction is typical, and it is why compute is usually the first verified saving in an optimization engagement. The sibling levers for the rest of the bill live in storage pricing and hidden costs.

GPU and HPC shapes: same logic, bigger numbers

The pricing logic of this article extends to the accelerated families with the decimal point moved. GPU shapes bill per GPU hour with the host CPU and memory bundled, H100 class capacity around ten dollars per GPU hour at list and older A100 capacity well below it, and the per second billing applies there too, which matters when a training run ends at 3 a.m. HPC shapes add RDMA cluster networking at rates that undercut the equivalent fabric elsewhere. Two differences deserve respect. Availability is the real constraint, GPU capacity is governed by quotas and reservations as much as price, so the planning disciplines in the GPU pricing comparison matter more than another dollar of rate. And idle accelerators burn money at a pace general purpose compute never approaches: an unused H100 node costs more per day than a mid size VM fleet, which makes the scheduling and queueing patterns from the preemptible section mandatory rather than optional at this end of the price list.

The five compute pricing mistakes we see most

After enough estate reviews the same handful of errors accounts for most compute overspend. Copying vCPU counts as OCPU counts, the factor of two classic. Leaving the memory dial at the migrated ratio, paying for gigabytes no working set touches. Ignoring Ampere because the team has always run x86, a habit that costs two thirds of the rate on every eligible service. Running non production around the clock, which a stop schedule fixes in an afternoon. And sizing for a peak that monitoring shows arriving twice a year, when autoscaling or a burstable baseline would buy the same insurance for a fraction of the spend. None of these requires deep expertise to fix, which is precisely the point: compute overspend is rarely an architecture problem, it is a measurement problem, and the measurements are sitting in the monitoring console waiting to be read.

Licensing intersections worth flagging

Two compute decisions carry licensing consequences that outrank their infrastructure savings. Oracle software under BYOL counts licenses against OCPUs, so shape sizing is also license sizing, and an oversized shape can double a license requirement silently. And bare metal versus VM affects isolation arguments some vendors care about. The infrastructure side is our work; for the license entitlement side, independent licensing advice before committing shapes is the cheap insurance.

A monthly compute review that takes one hour

The shape selection framework above is a project; keeping its results is a habit, and the habit fits in an hour a month. Pull the utilization report and flag every instance averaging under 30% CPU for a resize or a burstable conversion. Check the schedule compliance of non production fleets, because stop schedules decay as exceptions accumulate. Review any new instances against the family defaults, since new workloads arrive sized by habit rather than measurement. And scan the price list changes for the families you run, because hardware generations move the optimal answer over time. Estates that hold this cadence keep compute spend within a few percent of optimal indefinitely. Estates that treat optimization as an annual event drift 20% and call the correction a project, twelve times more expensive than the habit it replaces.

The bottom line

OCI compute pricing rewards teams that measure. The dials are all public: a third price Arm family, separate memory metering, burstable baselines, preemptible halves, and per second billing on it all. A fleet sized from measurement, placed on the right families, and scheduled honestly routinely lands 40% or more below a straight translation of its previous cloud footprint. That is the work our cost optimization practice does on a percentage of verified savings, and compute is usually where the first verified saving comes from. The egress and storage lines have their own levers, covered in the egress comparison and the rest of this cluster.