Ninety-Day Cloud Cost Reduction
A SaaS provider spends $420,000 per month across 200 AWS accounts. Cost allocation tags cover only 65% of spend. Forty development accounts run 24/7, and 30% of their EC2 instances are below 10% CPU. Savings Plans cover 18% of compute. Seventy percent of 900 TB of S3 data is in S3 Standard, and 12 TB of CloudWatch logs are retained indefinitely. Finance wants a 25% reduction in 90 days without affecting production SLAs. Engineering is resistant to commitments because product usage is unpredictable. A 3-year reserved capacity offer is on the table, but there is no reliable baseline. A new chargeback model is planned for next quarter. Last month a forgotten GPU cluster cost $28,000, and 14 accounts have no budget alerts.
1. Prioritize actions for the 90-day reduction. Which savings are safe, and which need validation?
Read the worked answer
Recommendation: start with non-production schedules, idle resource cleanup, storage lifecycle, and log retention. Treat rightsizing and production changes as a second wave after measurement.
Reasoning: The 40 development accounts running 24/7 are the safest target: schedule shutdown outside working hours, which can remove roughly 65% of their runtime without touching production. Identify unattached EBS volumes, idle load balancers, and old snapshots. For S3, move the 70% of 900 TB that is in Standard and not frequently accessed to Intelligent-Tiering or a lifecycle rule to Standard-IA and Glacier tiers, but validate retrieval patterns first. Set CloudWatch log retention to 30–90 days unless compliance requires longer. The 30% of instances below 10% CPU are rightsizing candidates, but low CPU alone does not prove they are overprovisioned; check memory, network, and burst behavior. The forgotten GPU cluster shows the need for anomaly detection and auto-stop, not just a one-time cleanup. The 25% target is plausible, but not from commitments alone.
2. How should the company approach Savings Plans and the 3-year reserved capacity offer?
Read the worked answer
Recommendation: do not buy the 3-year all-up commitment now. Establish a 30–45 day post-cleanup baseline, then buy a 1-year, no-upfront Compute Savings Plan for the steady-state floor, leaving room for growth.
Reasoning: Commitments are only savings if usage exists. The current 18% coverage and unpredictable product usage mean a 3-year commitment could lock in spend for workloads that are about to be rightsized or shut down. First remove waste and tag usage, then measure the minimum hourly compute that persists across the prior 30–60 days. Buy to that floor, not to the peak. A no-upfront plan preserves cash and reduces the penalty if usage falls. The tradeoff is a lower discount than a 3-year all-upfront plan, but it is safer given the missing baseline. Revisit coverage quarterly and increase gradually. Keep production and non-production commitments visible separately so engineering can see the cost of variability.
3. What governance changes should accompany the cost program so savings persist?
Read the worked answer
Recommendation: combine showback, mandatory tagging, budget alerts, and anomaly detection. Make account owners accountable before launching full chargeback.
Reasoning: The 35% untagged spend prevents accurate allocation and encourages waste. Enforce a small required tag set through AWS Tag Policies and an SCP that denies creating expensive resources without tags, but allow a grace period and a remediation path. Give each account a budget with alerts to the owner and finance, and enable Cost Anomaly Detection for services such as GPU instances. Start with showback dashboards so teams see their spend before money changes hands; chargeback next quarter will be more credible if the data is already trusted. The tradeoff is engineering overhead, so keep the tag set minimal and automate it through IaC. Review savings monthly against the 25% target and stop actions that risk SLAs.