To rightsize OCI compute shapes, you read each instance's real CPU and memory utilization over a representative window, compare it to the OCPU and memory you are paying for, and move oversized instances down to a correct size, preferring flexible shapes so you pay for the exact core count you need. The saving is immediate and the risk is low when you size to observed peaks plus a sensible buffer rather than to the original guess. The trap is rightsizing on a quiet week and clipping headroom you needed on a busy one.
This guide is part of our Oracle cloud cluster. For the full set of levers, read the complete guide to Oracle Cloud (OCI) cost optimization, the pillar this article links up to. Rightsizing is the first move in the Cut step of our See, Cut, Lock, Run method, because it shrinks the baseline before you ever buy a commitment on top of it.
Step 1: Pull real utilization, not nameplate size
Start from data, not from the shape someone chose at launch. Use OCI monitoring metrics for CPU and memory utilization across a window long enough to capture your real cycles: at least a full month, so weekly patterns and month-end peaks are visible. The number that matters is sustained utilization at the busy times, not the average. An instance averaging 12 percent CPU with a 35 percent peak is a clear rightsizing candidate; one averaging 60 percent with 90 percent peaks is not.
Step 2: Prefer flexible shapes so you pay per core
OCI flexible shapes let you set the exact number of OCPUs and the memory independently, rather than jumping between fixed sizes that often double the resources to get a small increase. Moving an oversized fixed shape onto a flexible shape sized to observed demand is frequently the single largest compute saving on an Oracle estate, because you stop paying for cores you never touch. For the detail on how that pricing works, see the sibling article on OCI flexible shapes.
Rightsizing failures come from sizing to averages and getting caught at peak. Size each instance to its observed busy-period utilization plus a buffer for growth and spikes, typically a margin above the highest sustained reading. This captures most of the saving while keeping the headroom that keeps the workload healthy.
Step 3: Consider Arm-based Ampere shapes for suitable workloads
For workloads that run well on Arm, OCI's Ampere A1 compute often delivers a strong price-performance improvement over equivalent x86 capacity. Stateless services, web tiers, and many modern runtimes port easily. Test correctness and performance on a non-production instance first, because not every workload benefits, but for those that do the saving stacks on top of rightsizing. Treat it as a per-workload experiment, not a blanket migration.
Want the rightsizing done across your estate?
We read utilization across every OCI compartment, resize to the right shapes, and protect the result with guardrails so it holds. On the performance model, you pay only from realized savings. No savings, no fee.
Book an OCI cost audit →Step 4: Apply changes safely and in order
Resize non-production first to validate the approach with no risk, then production in a maintenance window. Change one variable at a time so you can attribute any performance change to the resize. Most shape changes on OCI require a stop and restart, so schedule accordingly and confirm the workload tolerates a brief outage. Record the before-and-after shape and cost for each instance so the saving is measurable, not assumed.
Step 5: Lock it so it does not creep back
Rightsizing is not a one-time event. New instances get over-provisioned by default, and resized ones drift as teams add capacity defensively. Set a recurring review, define a policy for default shapes, and put budgets and alerts on the compartments you touched so growth is visible. This is the Lock step. For the broader assessment that surfaces every oversized instance in the first place, follow the sibling guide on how to read and use OCI Cost Analysis.
| Step | Action | Output |
|---|---|---|
| 1 | Pull CPU and memory utilization over a full cycle | Real demand per instance |
| 2 | Move to flexible shapes sized to demand | Pay per core, not per fixed tier |
| 3 | Test Ampere A1 for suitable workloads | Extra price-performance where it fits |
| 4 | Resize non-production then production | Booked saving, validated |
| 5 | Set policy, budgets, recurring review | Savings that hold |
OCI shape families, including Ampere A1 and the flexible E-series, and their pricing reflect the platform as of May 2026. Confirm current shape availability and per-OCPU pricing in Oracle's documentation before resizing, as shape families and rates change.
The OCI Cost Optimization Field Guide includes the utilization thresholds and buffer rules we use to size shapes safely. It is the downloadable companion to this method.
The short version
Read real utilization over a full cycle, move oversized instances to flexible shapes sized to observed peaks plus a buffer, test Ampere A1 where workloads suit it, apply changes non-production first, and lock the result with policy and budgets. Rightsizing is the lowest-risk, fastest OCI saving, and it must come before any commitment. When you want it run across the estate by an independent team, that is what our OCI cost optimization service delivers.