The Bill That Doubled Without a Traffic Increase
A company's monthly cloud bill rose from $18,000 to $37,000 with flat user traffic. The bill shows: compute up 40%, data transfer out up 300%, and storage up 15%. The team recently enabled verbose application logging to a bucket, added a cross-region read replica for a database, and deployed a new image-resizing feature that pulls originals from a bucket in one region and serves resized images from a CDN. Nobody owns cost monitoring; there are no budgets or alerts. Finance wants the increase explained and reversed within one billing cycle, and engineering says "the cloud is just expensive."
1. Attribute the increase to specific causes using only the symptoms given, and rank them by likely dollar impact.
Read the worked answer
Three suspects map cleanly to the three line items. Data transfer out (+300%) is most likely the dominant driver: serving resized images without proper CDN caching means origin fetches and egress repeat for every request, and a cross-region read replica also generates inter-region transfer. Compute (+40%) is plausibly the resizing workers plus the replica instance, not user growth. Storage (+15%) is consistent with verbose logs accumulating. Ranking by impact: egress first (300% on a line that is usually large), then compute, then storage. The judgement point is to resist the "cloud is expensive" narrative and instead ask which configuration change created each line item - logging verbosity, replica placement, and cache behavior are all reversible settings, not inherent platform costs.
2. What immediate, low-risk actions would you take this cycle, and what would you defer?
Read the worked answer
Immediate: (1) set a budget with alerts at 80% and 100% of the new baseline so the next surprise is caught in days; (2) enable cost allocation tags and split the bill by workload so the next investigation is minutes, not weeks; (3) tune CDN cache headers and confirm cache hit ratio, which typically cuts egress sharply with no code change; (4) reduce log retention and move verbose logs to a cheaper storage tier or shorten retention to what compliance actually requires; (5) evaluate whether the cross-region replica is needed for read latency or only for disaster recovery - if the latter, a snapshot-based strategy may be cheaper. Defer anything requiring schema changes or re-architecture, such as rewriting the resizing pipeline, until the measured savings from the above are known.
3. Engineering proposes turning off the read replica entirely to save money. What is the risk, and how should the decision be made?
Read the worked answer
Turning off the replica is a availability and latency decision disguised as a cost decision. If the replica serves read traffic, removing it pushes load onto the primary and may breach latency SLOs or cause an outage during failover; if it exists for disaster recovery, removing it may violate a recovery objective. The decision should be made against a stated RPO/RTO: if the business can tolerate a restore-from-snapshot recovery measured in hours, the replica is optional; if it needs minutes, it is not. A middle path is to keep a replica but in the same region if cross-region transfer is the cost driver, accepting that a regional outage then affects both. Document the chosen RPO/RTO and the cost of meeting it, so the trade-off is explicit rather than an argument about the bill.