Nightly Batch Contention on Shared-CPU Instances
A 30-person SaaS company runs a customer-facing analytics dashboard and a nightly media-transcoding batch in the same region. Both workloads share four 8 GB shared-CPU Compute Instances ($48/month each) behind a NodeBalancer. Dashboard p95 API latency is 180 ms during business hours but climbs past 2,400 ms between 01:00 and 04:00, exactly when twelve concurrent ffmpeg workers saturate every host. CPU sits at 100% for three hours and disk I/O spikes with it. The batch still finishes in 3.5 hours against a 4-hour SLA, so nobody has treated it as broken. The proposed fix is to add two more identical shared instances and double batch concurrency. Finance has approved at most a 25% increase in monthly compute spend.
1. Assess the proposal. What does it fail to address, and what alternative would you recommend within the 25% ceiling? Show the arithmetic.
Read the worked answer
The proposal is over budget and aimed at the wrong problem.
Current spend is 4 x $48 = $192/month, so the ceiling is $240. Two more shared instances cost $96 (+50%) and are rejected on cost alone.
Cost is not the only flaw. Shared plans are oversubscribed and scheduled fairly rather than exclusively, so batch workers and dashboard threads already compete; doubling concurrency on saturated hosts adds context switching and page-cache pressure, not throughput. The symptom (latency collapse at 01:00 with 100% CPU) is contention, not insufficient raw capacity.
Recommendation: split the pools and change the purchase type.
- Batch: 2 x Dedicated 8 GB ($72 each) = $144, giving predictable cores for ffmpeg.
- Dashboard: downsize the 4 shared hosts to 4 GB plans ($24 each) = $96, since the dashboard is latency-sensitive but not memory-bound.
- Total $240, exactly at the ceiling.
Before downsizing, confirm peak resident memory with a load test; if it does not fit, run 2 shared 8 GB + 2 dedicated and accept less dashboard headroom.
2. The team wants to keep both workloads on one host pool "because it's simpler." What risks does co-location create, and how should monitoring change if the pools are separated?
Read the worked answer
Co-location couples the two workloads' failure modes and hides their causes:
- Scheduler competition. A burst of ffmpeg threads delays dashboard requests on the same host, which is exactly the observed 01:00 collapse.
- Blast radius. A host reboot, kernel upgrade, or disk exhaustion taken for the batch also removes dashboard capacity; with four hosts the loss is 25% of the pool.
- SLA coupling. Batch overruns consume the headroom the dashboard needs during early-morning traffic from other time zones.
- Unreadable signals. Aggregate host CPU cannot tell you which workload caused a spike, so alerting drifts toward noise.
After separation, alert per pool: dashboard p95 latency and request error rate; batch queue depth, time-to-completion against the 4-hour SLA, and per-host runnability. Add a saturation alert on each dedicated host's core utilization so the batch is scaled before it misses SLA, not after.
3. Once the batch runs on dedicated plans, state two things Akamai operates and two the team still owns.
Read the worked answer
Buying a dedicated plan changes the CPU scheduling guarantee, not the division of responsibility.
Akamai operates: the physical hosts and hypervisor; the network fabric and DDoS mitigation in front of the region; the storage backend behind instance disks and Block Storage; and the control plane (Cloud Manager, API, billing metering).
The team owns: guest OS patching and configuration; the batch application itself - ffmpeg settings, concurrency, retry behavior, output validation; the Cloud Firewall rules and the account's API tokens; and data protection, including backup policy and tested restores.
A common exam trap is assuming dedicated plans or managed databases shift patching or backup responsibility. They do not: the plan changes performance isolation and price, not the boundary.