Right sizing is the single largest cost lever on most OCI estates, and it lives or dies on understanding shapes. Here is how OCI compute shapes work and how to match them to real demand.
Ask why an OCI bill is higher than it should be and the honest answer, more often than not, is that the compute is too big. Not broken, not misconfigured, just larger than the workload needs. This is the most common form of cloud waste anywhere, and on OCI it is also the most addressable, because the platform offers a range of shapes and, crucially, flexible shapes that let you dial cores and memory to the workload rather than the catalogue. Getting this right is the largest single lever in the complete cost optimisation guide, and it starts with understanding what a shape actually is.
A shape defines the resources allocated to a compute instance, principally the number of OCPUs or cores, the amount of memory, and the network bandwidth that comes with them. OCI groups shapes into families, and the distinction that matters most for cost is between fixed shapes, where the resource counts are set by the catalogue, and flexible shapes, where you choose the number of cores and the memory within allowed ranges. Flexible shapes are the cost optimiser's friend, because they let you provision exactly what a workload needs instead of rounding up to the next fixed tier.
| Shape type | How resources are set | Cost implication |
|---|---|---|
| Flexible | You choose cores and memory in a range | Right size precisely, pay for what you use |
| Fixed | Catalogue defines cores and memory | Round up to the nearest tier |
| Dense or specialised | Tuned for storage or GPU workloads | Match only where the workload demands it |
The practical upshot is that wherever a workload can run on a flexible shape, it almost always should, because the flexibility is what lets you avoid paying for cores and memory the workload never touches.
Over provisioning is rarely a decision. It is a default that arrives through a few familiar routes. Migrations size the new instance to match the retired physical server, carrying years of on premises headroom straight into the cloud bill. Teams provision for the worst case peak that happens twice a year and then run that capacity every day. Caution adds a buffer, then a buffer on the buffer, because nobody wants to be the person whose instance ran out of memory. Each step is reasonable and the sum is an estate paying for capacity it does not use, which is exactly the waste that the forty percent reduction targets first.
Right sizing is not guesswork and it is not a one time event. It is a measured, iterative practice with a clear sequence.
The discipline is in the iteration. Teams that right size once and walk away leave savings on the table, while teams that treat it as a recurring review keep their estate close to its true demand over time.
The hardest part of right sizing is deciding how much margin to keep, and the answer depends on the workload. A predictable internal application with stable load can run close to its measured peak with modest headroom. A customer facing system with sharp, unpredictable spikes needs more, and may benefit from autoscaling rather than a single large instance. The mistake is applying the same generous buffer to everything out of habit, because that buffer is exactly the waste right sizing exists to remove. Set headroom deliberately, per workload, against its real volatility.
Compute is the obvious target, but database capacity is often the larger one. Oracle workloads provisioned for peak, with cores allocated for a quarter end that lasts two days, carry significant waste the rest of the year. Autonomous Database changes this picture because it can scale automatically, and configured well it keeps you close to demand without manual resizing, a behaviour explored in Autonomous Database Auto Scaling and Cost. For licensed database workloads the cores you allocate also drive the licensing cost, which makes right sizing the database a double saving, on infrastructure and on licence.
There is a sequencing rule that matters. Right size before you commit, never the other way round. Committing to a capacity number before you have right sized simply locks in the over provisioning at a discounted rate, which feels like a saving and is actually a smaller version of the same waste. Once the estate is right sized, the stable baseline is clear, and that baseline is exactly what you commit to for the best rate, as covered in Reserved Capacity vs On Demand on OCI. Right sizing first, commitment second, is the order that compounds.
A few errors recur often enough to name. Sizing from the peak of peaks, the single highest reading ever recorded, produces an instance that is idle ninety nine percent of the time. Ignoring memory while focusing on cores misses a common bottleneck, because some workloads are memory bound and resizing cores alone does nothing for them. Treating right sizing as a project with an end date rather than a standing practice means the estate drifts back to over provisioning within a year. And forgetting to remove the resources that right sizing reveals as entirely unneeded leaves the easiest saving uncaptured, which is why right sizing pairs naturally with finding idle resources.
Right sizing is detailed, ongoing work that competes for attention with delivery, which is why it is so often deferred. Our OCI Compute practice and our cost optimisation work treat it as a recurring discipline rather than a one time clean up, measuring real utilisation, applying changes in controlled windows, and revisiting on a schedule so the estate stays close to its true demand. Because we run optimisation on a fee paid only on verified savings, the right sizing we recommend is the right sizing that actually lowers your bill, and it begins with an assessment that measures where the capacity is going.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.