Right-Sizing a Lift-and-Shift Fleet (OCPU vs vCPU and a Bursty Batch Host)
Northline Logistics is lift-and-shifting 12 application VMs from a colocation cage into the Frankfurt region. On-premises monitoring shows every application server peaking at 15% CPU on 16 vCPUs, while one nightly batch host sits at 90% for roughly two hours and idles the rest of the day. The migration team's first design uses VM.Standard.E4.Flex with 16 OCPUs and 128 GB of memory for every host, "to match what we bought in 2019". The first full month of billing came in at about 3.5 times the finance forecast, and spend is now frozen pending a design review. The application tier sits behind a load balancer and can be distributed; the batch host cannot be parallelised and must not lose work.
1. The team argues that each host needs 16 OCPUs because the on-premises servers have 16 vCPUs. Evaluate that argument and describe how you would determine the correct shape.
Read the worked answer
The vCPU-to-OCPU mapping is wrong by a factor of two, and the observed utilisation makes the shape oversized even after correcting it.
- On OCI x86 flexible shapes (E4/E5), 1 OCPU = 1 physical core = 2 vCPUs (hyperthreads). A 16-vCPU server therefore maps to roughly 8 OCPUs, not 16.
- Observed peak is 15% of 16 vCPUs, about 2.4 vCPUs, i.e. roughly 1.2 OCPUs. Even with 3x headroom for migration variance, around 4 OCPUs is defensible.
- Size memory from measured consumption, not from the old chassis. Flexible shapes let you pick OCPU count and memory per OCPU independently within published limits, so an unusual pairing (few OCPUs, lots of RAM) is legitimate for a memory-bound workload.
- Measure inside OCI: run a pilot shape for 2-4 weeks and use OCI Monitoring and the Management Agent. Hypervisor counters from the old estate often exclude steal time and overstate real headroom.
- Changing a shape requires a reboot, so treat it as a maintenance-window change, not a live adjustment.
- Check architecture before optimising price: Ampere A1 (Arm) is materially cheaper per OCPU, but only once the application stack is verified as aarch64-compatible.
Resize one canary host first, compare p95 CPU and memory against the forecast, then roll the rest of the fleet.
2. How would you handle capacity for the nightly batch host, given that the application tier can be distributed but this job cannot?
Read the worked answer
Two different problems are being conflated: the app tier scales horizontally, the batch host does not.
App tier (scale out):
- Put the uniform app servers in an instance pool behind the load balancer, then use autoscaling with a metric rule (e.g. scale out when average CPU exceeds 60% for five minutes) or a schedule rule for known peaks.
- Autoscaling changes the number of instances; it never resizes an existing one. The pool's shape is fixed, so the shape must be right and the pool must be sized for steady state.
- Set thresholds below the point where latency degrades, and add a cooldown so the pool does not flap.
Batch host (single, non-parallelisable job):
- Extra instances do not help one job. The lever is the instance's shape. Before resizing up, confirm the job is actually CPU-bound: two hours at 90% can equally be I/O wait on a block volume with insufficient VPUs - check volume performance and queue depth first.
- A burstable flexible instance with a low baseline OCPU is the natural fit for a short daily spike: credits accumulate while idle and are consumed during the burst. Do the arithmetic before committing - baseline % × 24 hours must cover the daily burst demand, or the instance throttles to baseline mid-job. Baseline performance across the other 22 hours must also be acceptable.
- Never rely on bursting to cover long or unpredictable peaks; the mechanism is credit-limited, not unlimited.
Measure a real run with the agent before choosing between resizing up, burstable baseline, or splitting the job.