Why flexible shapes help
On a flexible shape you choose OCPUs and memory separately (within per-shape ratios). A server that needs 2 OCPUs and 32 GB doesn't have to buy 4 OCPUs to get the memory. Most savings come from adjusting these two numbers to what the workload actually uses.
1. Measure
From OCI Monitoring (Oracle Cloud Agent compute metrics), 30 days, per instance:
CpuUtilization[1h]{resourceId = "<instance-ocid>"}.percentile(0.95)
MemoryUtilization[1h]{resourceId = "<instance-ocid>"}.max()
Run them in Metrics Explorer, or across a compartment with oci monitoring metric-data summarize-metrics-data:
oci monitoring metric-data summarize-metrics-data --compartment-id $C --namespace oci_computeagent \
--query-text 'CpuUtilization[1h].groupBy(resourceDisplayName).percentile(0.95)' \
--start-time "$(date -u -d '-30 days' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)"
| Pattern | Action |
|---|---|
| p95 CPU < 20%, memory < 50% | Fewer OCPUs and less memory |
| CPU low, memory high | Keep memory, reduce OCPUs |
| CPU mostly idle with short spikes | Burstable baseline |
| Constantly busy | Leave it, or test a newer shape generation |
2. Resize OCPU and memory independently
oci compute instance update --instance-id $INSTANCE \
--shape-config '{"ocpus": 2, "memoryInGBs": 24}'
A flexible shape change reboots the instance. Schedule it, and check application licences tied to core counts (see the "Resizing an OCI compute instance" post for the safe procedure).
3. Burstable instances for mostly idle servers
Burstable VMs bill a baseline fraction of the OCPUs (1/8 or 1/2) and can burst to the full OCPU count for short periods:
oci compute instance update --instance-id $INSTANCE \
--shape-config '{"ocpus": 2, "memoryInGBs": 16, "baselineOcpuUtilization": "BASELINE_1_2"}'
Good fits: jump servers, small internal web apps, build agents idle most of the day, dev/test VMs. Poor fits: anything with sustained CPU, which gets throttled back to baseline. Check which shapes support burstable baselines.
4. Ampere (Arm) for Linux workloads
Ampere A-series shapes usually cost less per OCPU, and an Ampere OCPU is one physical core. Good candidates are Java, Go, Python, Node.js, containers with multi-arch images and open-source databases. Test with the real workload first (see the Ampere transformation post).
5. Newer generations
Within the same family, newer shapes (e.g. a newer E-series generation) often give more performance for similar price. When a workload is CPU-bound, try the newer shape before adding OCPUs.
6. Remember memory-to-OCPU limits
Each flexible shape has a minimum and maximum memory per OCPU. If you need lots of memory with few OCPUs, check the ratio. Sometimes a different shape fits better than adding OCPUs just to unlock memory.
7. Track results
| Metric | Before | After |
|---|---|---|
| Total OCPUs (compartment) | ||
| Total memory GB | ||
| Monthly compute cost (Cost Analysis by service/compartment) | ||
| p95 CPU and application latency |
Warning
Oracle software licensing (Database, WebLogic) counts OCPUs. Reducing OCPUs can save licence cost, but increasing them can create licence exposure. Check with whoever owns licensing before resizing licensed servers.
Checklist
- 30-day CPU and memory p95/max per instance
- OCPU and memory trimmed independently
- Burstable baselines for mostly idle servers
- Ampere tested for suitable Linux workloads
- Newer shape generations tried for CPU-bound servers
- Licence impact checked; savings tracked