The most detailed free FDE + DevOps library: 140+ lessons, 70+ labs and 80 long-form articles, in English and Turkish. Start learning →

DevOps Professional · Module 6: Governance, cost and change control

Cost and Capacity Math on Stated Assumptions

Cost decisions need arithmetic on stated assumptions, not vibes about stickers. Measure use, price the bottleneck's rate, compare options on the same assumptions, and label every price training-only with its date.

10 min reading

Objectives

  • Explain what cost math needs: measured use, bottleneck rate, stated prices
  • Compute per-request cost from fixture numbers and find the expensive hop
  • Choose watching the bottleneck, not chasing the cheapest sticker
  • Label every price a training assumption with its date

Why this matters

A team moves workloads to the cheapest-looking option and the bill rises: data transfer and idle reservations dwarf the compute saving, and the bottleneck hop costs more per request than before. The decision used sticker prices for one resource and ignored the rest. Cost math covers the whole request path (compute, transfer, storage, idle headroom, operations time) on stated assumptions, or it misleads with confidence. The L64 lab does this math on given assumptions and picks watching the bottleneck.

Concepts

The math starts from measurement. Requests per second, resource per request at the bottleneck, utilization of reservations, transfer per request across priced boundaries. Per-request cost falls out: the bottleneck hop's price divided by its sustainable rate, plus the path's transfer and storage shares. Options compare on identical assumptions: same traffic, same headroom policy, same growth window. Change one assumption and the ranking can flip; the sensitivity note (which assumption decides) matters more than the winner.

Bottleneck-first ordering applies to money too. Optimizing a cheap hop saves pennies while the expensive hop dominates; the math names the expensive hop first, and effort follows the ranking. Idle capacity gets priced honestly: reserved-but-unused is spend without work, and the fix is rightsizing or elasticity, not cheaper unit prices on waste.

Assumptions are labeled, dated and revisited. Every price in the exercise is a training assumption, never a current provider price; real decisions re-price at decision time from the provider's current list. The document states its date and its sources; undated cost math is how stale prices become confident decisions. Revisit triggers are the same as policy reviews: quarterly or when traffic shape changes.

Worked example

A fixture request path crosses three hops with given assumption prices. The learner computes per-request cost per hop, finds the transfer hop dominating, and compares two options: the sticker-cheap option loses once transfer is included. The sensitivity note names transfer volume as the deciding assumption, quoted with numbers.

Common wrong move

Optimizing unit prices while ignoring utilization. A forty-percent discount on half-idle reservations saves less than deleting the idle half at full price. Use first, price second, discount last.

Quick check

An optional 4-question self-check. Answers never leave your device, are not stored, and never count toward any assessment.

Lesson feedback

No published feedback yet.

Log in and complete the lesson to leave feedback.

Exercise

On a fixture path with given assumption prices, compute per-request cost per hop, compare two options, and name the deciding assumption with numbers.

Pass criteria

The record shows per-hop math, the option comparison on identical assumptions, the bottleneck-first pick, and dated training-assumption labels.

Sources

Log in to track progressFree account: stores only your lesson progress and quiz results.