Cost Spike from Orphaned and Oversized Resources
Monthly bill jumped 38% quarter-over-quarter with no traffic growth. Investigation shows: 22 ECS instances tagged env=dev running 24/7, 14 unattached cloud disks from deleted instances, 6 EIPs not bound to any instance, an OSS bucket with 40 TB of logs never lifecycle-expired, and 30% of prod instances are 8 vCPU where CloudMonitor shows peak CPU of 8%. Prod must stay available; dev is used 9am-7pm weekdays.
1. Rank the cost-saving actions by savings potential and risk, and identify which are safe to do immediately.
Read the worked answer
Rough ranking by savings and risk:
- Release unattached disks and unbound EIPs - pure waste, zero risk once you confirm nothing references them (snapshot disks first). Safe immediately.
- OSS lifecycle rule on the 40 TB log bucket - move to infrequent-access/archive tier or expire old objects. Safe, reversible, large recurring saving.
- Dev instance scheduling - stop 22 dev instances outside 9-7 weekdays. ~60% of their runtime eliminated. Low risk if devs agree; use scheduled start/stop.
- Right-size prod - 8 vCPU at 8% peak is oversized, but this carries availability risk. Do it last, with monitoring and a rollback plan.
Do 1-3 this week; pilot 4 on one instance first.
2. How would you right-size the prod instances safely, given peak CPU is only 8%?
Read the worked answer
Peak CPU of 8% is a hint, not proof - memory, disk I/O, and network could be the real constraint, and a batch job may spike outside the sampled window.
Safe approach:
- Pull memory and network metrics too, not just CPU. Check peak over the full month, not averages.
- Pilot on one instance: downsize (e.g., 8→4 vCPU), monitor for a week against the original baseline (latency, error rate, CPU/memory headroom).
- Roll out in waves with a rollback trigger (e.g., CPU >70% sustained or latency regression).
- Keep auto scaling so a downsized fleet can absorb unexpected load.
This converts an irreversible fleet-wide change into a reversible, measured one. Set a target headroom (e.g., peak ≤60%) rather than chasing the lowest possible spec.