Outcome
By the end of this lesson, you will be able to name the six FinOps Foundation principles and explain how each one shapes a real cost decision.
| Tier | Operator |
| JTBD | ”Have a defensible answer when the CFO asks ‘what framework are you using?’” |
| Personas | All five |
| Prerequisites | M0.1 module complete |
| Time | 8 minutes |
| Bloom verb | Name (Remember) and Explain (Understand) |
1. Concept
FinOps is the practice of managing cloud spending as a shared responsibility between engineering, finance and the business, rather than as a bill that arrives and gets paid.
The FinOps Foundation, the industry body for this work, publishes the framework everyone else borrows from. It has six principles, three phases called Inform, Optimize and Operate, and 22 named capabilities grouped into four areas.
The principles describe how a healthy practice behaves rather than what it does on a Tuesday. Learn the six and most arguments about whether to do something answer themselves.
Principle 1: Teams need to collaborate
Engineering, finance, product, leadership, procurement and security all make decisions that move the bill. None of them can fix it alone.
This principle exists to prevent the usual failure: finance writing reports that engineering ignores, and engineering buying capacity that finance cannot forecast.
Practice form: A weekly FinOps standup that includes a finance representative and an engineering lead. Decisions made in the room, not in email threads.
Principle 2: Business value drives technology decisions
A smaller bill is not the goal. Cost measured against what the business got for it is the goal.
A bill 10 percent higher than last quarter is only a problem if the business did not also grow. A bill 10 percent lower is a problem if the team cut something the business needed.
In practice: every cost report carries a cost-per-something column: per monthly active user, per order, per thousand API requests. The direction that column is moving matters more than the total at the bottom.
Principle 3: Everyone takes ownership for their technology usage
Whoever uses the resource owns its cost. Not a central FinOps group, not finance, not the platform team.
The alternative is an arrangement where a central cost team owns the bill. It reliably produces waste, because the people who can turn something off are not the people being asked about it.
Practice form: Each team has a monthly cost dashboard scoped to its tagged resources. Each team has a budget. Variance reports go to the team, not to central FinOps.
Principle 4: FinOps data should be accessible, timely, and accurate
Cost data that is old, wrong, or only available on request is worse than useless, because it creates the appearance of a practice without the substance.
A team told about a cost problem three weeks later cannot fix it. A group that keeps the bill inside monthly PDFs cannot then ask teams to take ownership of it.
In practice: cost data sits in a tool people can open themselves, refreshed daily, accurate to within a margin everyone knows. No tickets to request a report.
Principle 5: A centralized team drives FinOps practices
This one is widely misread as “the central team owns the bill”. It says the opposite.
The central group supplies the tools, the training, the standards and the benchmarks. The teams make the decisions inside them.
In practice: a small central function that publishes the standards, the four required tags, the budget thresholds, what to do when spending spikes, and runs the tooling. Not a team that has to approve every infrastructure change.
Principle 6: Take advantage of the variable cost model of the cloud
In a data centre you buy the machine once and it costs the same whether it is busy or idle. In the cloud you pay for what you use, which means you can stop paying.
That is the whole advantage, and it is the one most often wasted. Scale down at night. Turn off what is idle. Use cheap interruptible capacity for work that can be interrupted. Commit in advance only to the floor you are certain of.
Treating the cloud like a data centre, provision once and leave it running, is the single most expensive habit in this course.
In practice: scheduling, autoscaling and commitment decisions are treated as real disciplines with owners, not as settings somebody adds to a template later.
The principles in one picture
┌─────────────────────────────────────────────────────┐ │ FINOPS FOUNDATION: six principles │ ├─────────────────────────────────────────────────────┤ │ 1. Teams collaborate │ │ 2. Business value drives tech decisions │ │ 3. Everyone takes ownership │ │ 4. Data is accessible, timely, accurate │ │ 5. Centrally enabled, locally owned │ │ 6. Exploit the variable cost model │ └─────────────────────────────────────────────────────┘These six are not opinion. They are the public framework. Any organization can adopt the language; the language gives FinOps work the shared vocabulary it needs to be defensible inside an engineering culture that respects defensibility.
2. Demo
The six principles tested against a real decision: “Should we apply a 1-year Reserved Instance to dev compute?”
- Principle 6 (variable cost): Dev compute should not be running 24/7 in the first place. A reservation locks in 24/7. The first move is scheduling, not commitment.
- Principle 3 (ownership): Who owns the dev environment? They should be on the call.
- Principle 4 (data): What is the current utilization of dev compute? Pull the number before deciding.
- Principle 2 (business value): What does the dev environment deliver to the business? If it accelerates 30 engineers’ work, that frames the budget.
- Principle 1 (collaborate): Finance, engineering, product in the room. Not just engineering.
- Principle 5 (centrally enabled): Central FinOps publishes the “schedule first, commit on the floor” playbook. The team applies it.
Decision: Do not apply a 1-year RI to dev. Schedule the dev compute. After 60 days of scheduled operation, evaluate a commitment on the floor only (the always-on overlap of the schedule).
3. Hands-on (5 min)
Pick a current cost decision your team faces. Apply the six-principle test to it:
DECISION: __________________________________
Principle 1 (collaborate) : Who needs to be in the room? ____________Principle 2 (business value): What does this enable? ________________Principle 3 (ownership) : Who owns the consequence? ______________Principle 4 (data) : What number do we need? ________________Principle 5 (centrally enabled): What policy applies? _______________Principle 6 (variable cost): Is there a fixed-cost trap to avoid? ___If three or more cells are blank, the decision is not ready to make. Get the data, gather the people, then revisit.
4. Knowledge check
Q1
“FinOps is central. Cost ownership is central.” This statement most directly violates which principle?
A. Principle 3 (ownership)
B. Principle 1 (collaborate)
C. Principle 5 (centrally enabled)
D. Principle 6 (variable cost)
Show answer
Correct: A. Principle 3 is explicit: ownership lives with the team that uses the resource. Central enables but does not own. (Principle 5 is the closest decoy but its statement is “centrally enabled,” not “centrally owned”: exactly the distinction the principle is making.)
Q2
A team’s cost report is published monthly as a PDF. Which principle is undermined?
A. Principle 2 (business value)
B. Principle 6 (variable cost)
C. Principle 4 (accessible, timely, accurate)
D. Principle 5, which is centrally enabled
Show answer
Correct: C. Monthly PDFs are neither timely nor accessible. The team cannot act on data they cannot query, refreshed at a cadence that lets them respond.
Q3
The CFO asks: “Why is our bill up 12 percent quarter-over-quarter?” The best framing for the answer leans on which principle?
A. Principle 2 (business value)
B. Principle 1 (collaborate)
C. Principle 4 (accessible, timely, accurate)
D. Principle 6 (variable cost)
Show answer
Correct: A. The answer must connect bill change to business value change. “Our bill is 12% higher; our MAU is 18% higher; our cost-per-MAU is down 5%” is a different conversation than “our bill is 12% higher, full stop.”
5. Apply
ZopNight’s product surface aligns with the principles by design. Specific examples:
- Principle 3 (ownership): Reports → Teams attributes cost by tag, including shared-resource split. The Unattributed bucket is its own row: visible, embarrassing, fixable.
- Principle 4 (data): The two-source cost model (Rack Rate + Billing) and the 24-hour sync cadence make daily cost queryable, with the freshness band labelled.
- Principle 6 (variable cost): Scheduling is a first-class feature, not a Lambda script. The variable-cost principle is what makes that decision defensible.
Open ZopNight Reports → Teams (deep link)
Related lessons
- L2: Inform: what visibility actually means (next)
- L5: Crawl, Walk, Run
- T4.M4.1: The FinOps maturity ladder
Glossary terms touched
FinOps Foundation · FinOps lifecycle · Cost ownership · Variable cost