Exercises: Cloud Cost Optimization

Solutions and grading notes are in the instructor companion. Exercises marked 🧪 use code/cost_model.py. Every price in this chapter is the book's frozen rate card and yours is different — several exercises ask you to substitute your own, which is the point.

Warm-Up

Exercise 33.1 — Which meter are you on?

Difficulty: ★☆☆ · Time: 15 minutes

§33.2: per byte scanned, per warehouse-second, per node-hour.

  1. For each system you use, name the meter. If you cannot, that is the exercise — go and read the pricing page.
  2. For each, say what a 50% reduction in CPU time would save. Be honest; for one of the three the answer is nothing.
  3. For each, say what a 50% reduction in bytes read would save.
  4. Which of your systems dominates your bill, and does that match where your team's optimization effort goes?

Exercise 33.2 — The Chapter 1 arithmetic

Difficulty: ★☆☆ · Time: 15 minutes

160 × 10.0 × $2.400 = $3,840.00 became 24 × 1.3 × $2.400 = $74.88.

  1. Compute the ratio, the annual saving, and the saving per character deleted (four characters).
  2. --estimate prices the same fix at 126.5×, 128.6×, and 51.3×. Explain why the node-hour meter shows the smallest ratio and the largest dollar saving.
  3. §33.3 says the postmortem led with 51.3× and buried $1,374,269. Rewrite the one-line summary the way §33.3 recommends.

Exercise 33.3 — Read the bill

Difficulty: ★☆☆ · Time: 20 minutes · 🧪

python code/cost_model.py --bill
  1. Storage is 2.1% and compute is 61.9%. Before looking, predict which category you would have optimized first, and say why.
  2. Four line items are unattributed. What do they have in common?
  3. Compute what deleting every byte Kestrel stores would save, and compare it to suspending one warehouse.
  4. Which single line item would you investigate first, and is it the largest one?

Core

Exercise 33.4 — Estimate before you run

Difficulty: ★★☆ · Time: 40 minutes

§33.6's calibration exercise.

  1. For the next three queries you write against a real system: predict the cost, get the dry-run or EXPLAIN estimate, then read the actual. Record all three.
  2. Report your error on each. Most people are wrong by more than 10× on the first.
  3. Now do it for a query you have already shipped and run regularly. Annualize it.
  4. What would have to be true for that number to appear in front of you automatically?

Exercise 33.5 — Attribute your own bill

Difficulty: ★★☆ · Time: 60 minutes

  1. Take a real bill. Split it by team. If you cannot, record how far you get and where you stop.
  2. Compute the unattributed share. Case Study 1's was 36.4%.
  3. For each unattributed item: is it waste, or is it shared infrastructure that genuinely has no single owner? The two need different answers.
  4. §33.5 says the fix that moved the number was charging the unattributed bucket to a team. Who would it be at your organization, and would they accept it?
  5. Case Study 1's unattributed spend resolved 87% by deletion, 13% by tagging. Predict your own split before you find out.

Exercise 33.6 — Size the seven wastes

Difficulty: ★★☆ · Time: 60 minutes · 🧪

python code/cost_model.py --waste

For each of the seven patterns, check whether you have it, and size it with arithmetic rather than instinct:

  1. A compute resource that does not suspend or stop when idle.
  2. A dev/test environment running outside working hours.
  3. Storage nobody has read in a year.
  4. Small-file request amplification.
  5. Cross-region or cross-AZ data transfer.
  6. A scheduled refresh far more frequent than anyone consumes.
  7. Raw data retained past its need.

For each: the monthly cost, the annual cost, and an honest estimate of weeks to fix.

Then: §33.7 found 83.3% of Kestrel's waste was idle, not inefficient. What is your share?

Exercise 33.7 — Rank by payoff

Difficulty: ★★☆ · Time: 30 minutes · 🧪

python code/cost_model.py --rank
  1. Take your Exercise 33.6 list and rank it twice — by annual saving, and by annual saving per week of work.
  2. Do the two orderings differ? If not, either you are lucky or your effort estimates are uniform; check the second.
  3. Identify everything you could do in under one day. Total the annual saving. Kestrel's was $132,192.
  4. Identify your worst payoff-per-week item. Does it have a non-cost justification? If so, rewrite its proposal without the cost argument (§33.8).

Exercise 33.8 — Unit economics

Difficulty: ★★☆ · Time: 45 minutes

§33.11: $0.1526 per order, 0.201% of GMV.

  1. Pick the business unit your organization counts — orders, users, transactions, requests, patients. Compute cost per unit for your data platform.
  2. Compute cost as a share of the number your business reports.
  3. Decompose your bill into fixed and variable. Kestrel's came out ~64% variable.
  4. Using that decomposition, answer: if volume doubles, what happens to the bill and to unit cost?
  5. Find your step functions — the lines that are flat until they jump. When is the next step?

Exercise 33.9 — What the monitors cannot see

Difficulty: ★★☆ · Time: 40 minutes

Case Study 2: seven monitoring systems green for thirty nights.

  1. List every monitor on a pipeline you own. For each, say whether it watches time, correctness, volume, or money.
  2. Construct a change that would be invisible to all of them. Case Study 2's produced byte-for-byte identical output.
  3. Your duration alarm: is its threshold absolute or relative to the job's own history? Kestrel's 8-hour alarm missed a 3.75× regression.
  4. Do you have any volume assertion on inputs, or only on outputs?

Exercise 33.10 — The autoscaling trade

Difficulty: ★★☆ · Time: 30 minutes

Case Study 2's 🔎 callout: autoscaling decoupled cost from latency, and latency was the only accidental cost signal.

  1. Verify the arithmetic: 24 nodes × 1.30 h and 64 nodes × 4.88 h. Why are the node-hours exactly 10× apart?
  2. Compute what the job would have cost with no autoscaling and the same window change. Compare.
  3. For each autoscaled workload you run, name the signal that replaces latency. If there is none, that is your finding.
  4. §"Questions for Discussion" asks whether other reliability features hide signals. Take retries: what does an automatic retry hide, and how would you surface it?

Advanced

Exercise 33.11 — Extend the model

Difficulty: ★★★ · Time: 90 minutes · 🧪

Add three to cost_model.py, with self-checks:

  1. Your own rate card, loaded from a file rather than constants. Then re-run every report and report which conclusions change.
  2. A reserved-capacity model — commit level, discount, and the blended rate against a demand curve (§33.10).
  3. A spot model with an interruption rate and a re-run cost, answering "is spot worth it for this job?"
  4. Cost per pipeline over time, with the day-over-day anomaly check from Case Study 2.
  5. A storage-class model — Standard, Infrequent Access, Glacier — including retrieval cost, which is the term everyone omits.
  6. A break-even calculator for an optimization: engineering cost versus annual saving, in months.

Then: run #6 against Exercise 33.7's list at your own loaded engineering cost. How many of your optimizations never break even?

Exercise 33.12 — Build the pull-request bot

Difficulty: ★★★ · Time: 90 minutes

Case Study 2's fix.

  1. For your engine, find the API that estimates a query's cost without running it (dry run, EXPLAIN, plan bytes).
  2. Write the estimator. Given a changed file, produce before and after cost.
  3. Decide the threshold and the gate. Case Study 2 chose a soft gate with a label — argue for or against.
  4. Run it against the last twenty merged changes in your repository. How many would have tripped it, and were any of them mistakes?
  5. §"What Happened": 5 of 11 flagged changes were modified or abandoned. What conversion rate would make you delete the bot?

Exercise 33.13 — The commitment decision

Difficulty: ★★★ · Time: 60 minutes

§33.10's trap: a 42% discount against a workload a migration was about to cut by 61%.

  1. Model it. Three-year commitment at 42% off, current spend $X, and a 61% reduction arriving in month
  2. What is the three-year cost with and without the commitment?
  3. Now model committing to the floor — 60% of current — and paying on demand for the rest. Compare.
  4. §33.10 claims a commitment converts a future efficiency into a sunk cost, so teams stop pursuing savings they cannot benefit from. Is that a real effect or a rationalization? Argue both.
  5. Write the two paragraphs you would send to a finance partner who wants to commit now. Give them something to say yes to.

Exercise 33.14 — Deliver a cost finding

Difficulty: ★★★ · Time: 45 minutes

§33.12: Kestrel's first attempt produced three weeks of defensiveness.

  1. Find a real cost finding about another team's work.
  2. Write the message twice — once as the version that goes badly, once following §33.12's four rules. Compare them.
  3. Convert the number into the other team's units. What is $2,000 a month to a marketing team? To a product team? To a hospital's operations lead?
  4. §33.12's finding was wrong for one tile of eighteen because the engineer did not know what it was for. What is the equivalent thing you do not know about your finding?
  5. Send it. Report what happened.

Project Milestone

Exercise 33.15 — Cost discipline for your platform

Difficulty: ★★★ · Time: 3–4 hours · 🧪

Build §33.13's structure for your own work.

  1. One versioned rate card — rates.yml, a single source of truth. §33.13's 🧱 callout: Kestrel had two circulating answers to "what does a node-hour cost," which made every estimate arguable.
  2. Attribute your bill, and publish the unattributed share.
  3. Run the seven wastes and size them.
  4. Rank by payoff per week, and do everything under a day.
  5. Compute your unit cost and its fixed/variable split.
  6. Add a cost estimate to code review for one repository.
  7. Add a daily per-pipeline cost anomaly check.
  8. Publish two numbers monthly: total, and unattributed share.

Deliverable: the rate card, the attributed bill, the ranked waste list with what you actually did, the unit cost, and the two monitors.

Report the unattributed share honestly, including if it is embarrassing. Case Study 1's whole finding is that the embarrassing number is the valuable one.

Exercise 33.16 — The Part VI retrospective

Difficulty: ★★☆ · Time: 45 minutes

Part VI covered streaming, governance, privacy, ML, and cost. The book claims one finding recurs across all five: a control that exists and does not operate is not a control.

  1. Name the instance in each of the five chapters. One of them is in this chapter.
  2. For each, say what measurement would distinguish "exists" from "operates."
  3. Is there a single audit that would find all five at once? Chapter 30 Case Study 2 asks this and does not answer it. Answer it, or explain why it cannot be answered.
  4. Which of the five controls in your platform would fail this test today?