Cost as a Design Constraint

By the end of this lesson, you can…

• Explain the Inform → Optimize → Operate loop the way it actually runs from the engineering seat, not the practitioner seat.
• Name the Iron Triangle trade-off in a real deploy decision and state which two of cost, speed, and quality you're protecting when you concede the third.
• Describe what the Engineering persona owns versus what it hands upward to the FinOps Practitioner.
• Turn a monthly infra bill into at least two different unit-cost numbers (per request, per pod-hour, per build) and explain why they use different cost bases.
• Explain what a FOCUS-conformant export buys you as an engineer writing your own cost queries, instead of waiting on a monthly finance report.

The FinOps Framework, From the Engineering Seat

The FinOps Framework runs on one loop — Inform, Optimize, Operate — and most FinOps material teaches it from the practitioner's chair: build the dashboard, present the recommendation, run the governance meeting. You sit in a different chair. The same loop looks like this from where you work:

Every week after this one is one of these three phases made concrete: Week 2 is Inform and Operate for tags, Weeks 3–5 are Optimize for architecture, rightsizing, and Kubernetes, and Week 6 is Operate for the whole pipeline.

The Iron Triangle: Cost, Speed, Quality

Every infrastructure decision you make trades off three things — cost, speed (how fast you ship, and how fast the system responds), and quality (reliability, correctness, security). You can protect two. The third one moves.

Cost

What the decision spends — infrastructure dollars, but also the engineering time to build and maintain it.

Speed

Two different clocks: how fast you ship the feature, and how fast the running system responds to a request.

Quality

Reliability, correctness, and security — the properties that fail silently until they fail loudly.

A concrete example: Multi-AZ RDS versus single-AZ. Multi-AZ roughly doubles the database cost line, in exchange for automatic failover if a whole AZ goes down. That's a quality purchase, paid for in cost, with speed unaffected either way. A team that runs single-AZ in production isn't being careless by default — they may have decided their quality bar doesn't need automated failover, and they've bought speed-to-market or cost efficiency instead. The trade-off itself isn't right or wrong; what matters is that someone made it on purpose and can name what got protected and what got conceded.

Where Engineering Sits Relative to the Practitioner

The FinOps Foundation treats FinOps Certified Engineer and FinOps Certified Practitioner (FOCP) as parallel, persona-based certifications, not a ladder. They own different halves of the same loop:

Neither role works without the other: a Practitioner's dashboard is only as good as the tags Engineering enforced (Week 2), and Engineering's rightsizing script (Week 4) is only worth running against a budget the Practitioner has already forecast.

Reading a Bill Like an Engineer: Unit Cost

A finance-oriented cost review asks "did total spend go up." An engineering-oriented one asks "did the cost of doing one unit of work go up" — because total spend going up while traffic triples is a win, and total spend staying flat while traffic drops by half is a problem hiding behind a flat line. That's what unit cost is for: cost per request, per pod-hour, per pipeline run, per whatever unit your service actually produces.

Service: checkout-api                    Monthly cost
--------------------------------------------------------
Compute (8 pods avg, autoscaled)          $14,400
Managed Postgres (RDS, db.r5.xlarge)       $2,600
Data transfer / egress                       $600
--------------------------------------------------------
Serving cost (compute + db + transfer)    $17,600
CI/CD (500 builds this month)                $750
--------------------------------------------------------
Total infra + pipeline cost               $18,350

Notice the total is split into two groups: serving cost (compute, database, data transfer — the cost that scales with traffic) and CI/CD cost (the cost that scales with how often you ship). That split matters because each unit-cost number should divide by the cost base that actually drives it:

Requests served this month:        40,000,000
Pod-hours this month (8 pods x 720h): 5,760
CI builds this month:                    500

cost_per_request  = serving_cost / requests
                   = $17,600 / 40,000,000
                   = $0.00044   (0.044 cents / request)

cost_per_pod_hour = compute_cost / pod_hours
                   = $14,400 / 5,760
                   = $2.50 / pod-hour

cost_per_build    = ci_cost / builds
                   = $750 / 500
                   = $1.50 / build

Three different numbers, three different levers. Cost per request ($0.00044) moves if you cache more aggressively or reduce chattiness between services. Cost per pod-hour ($2.50) moves if you rightsize the pods themselves (Week 4) or renegotiate the compute pricing model (Week 3). Cost per build ($1.50) moves if you cache CI dependencies or trim a slow test suite. Blending all three into one "total cost per something" number — which is the instinct a lot of engineers reach for first — hides which lever actually moved the needle.

FOCUS for Engineers: Querying Your Own Cost Data

Waiting for a monthly billing export from finance is the practitioner-era workflow. If your organization's cost data is FOCUS-conformant (or exported through a provider's FOCUS-compatible export, like AWS Data Exports), you can query your own service's cost the same way you'd query your own logs — filtered by the resource tags you already enforce in Week 2, using FOCUS's provider-neutral ServiceCategory and ResourceId columns instead of hand-parsing a provider-specific export format.

SELECT
  ServiceCategory,
  ResourceId,
  SUM(EffectiveCost) AS effective_cost
FROM focus_cost_and_usage
WHERE Tags['team'] = 'checkout'
  AND ChargePeriodStart >= DATE_TRUNC('month', CURRENT_DATE)
GROUP BY ServiceCategory, ResourceId
ORDER BY effective_cost DESC;

The point isn't that you need to become a FOCUS expert (that's a separate course on this platform, if you want the deep dive) — it's that a normalized schema is what makes "check your own service's cost before standup" a query you can actually write, instead of a report you have to request.

Exercise: Build a Unit-Cost Model for a Service You Own

Reflection

Putting it together

The Inform → Optimize → Operate loop, the Iron Triangle, and the Engineering/Practitioner split are the same three ideas from three angles: what data you have, what trade-off you're making with it, and whose job it is to act on it. Unit cost is what turns "the bill went up" into a number you can actually reason about, and FOCUS is what makes that number queryable instead of requested. Every deliverable for the rest of this course — a tagging policy, an ADR, a rightsizing script, a Kubernetes cost model, a CI gate — is a more specific version of the same move: catching a cost decision at the point where you, the engineer, can still change it.