The two-source cost model

Outcome

By the end of this lesson, you will be able to describe the two-source cost model and pick the right source for any cost question.

1. Concept

Keep two cost numbers, not one.

One is calculated every day from what is running and the public price list. The other is the actual billed amount, after discounts, which arrives a day or more later. Label both clearly, and choose between them depending on the question being asked.

This is the pattern any serious cost practice ends up at, and it is what ZopNight implements.

Why two sources

A single-source cost model breaks under one of three pressures:

Freshness against accuracy. Billing data is at least a day behind. A calculated figure is written every day, before any billing data exists. With only one of them you can either spot a problem today or reconcile an invoice correctly, but not both.

Before discount against after discount. A price-list comparison or an estimate for a new workload needs the rack rate, because no discount applies yet. A budget needs the billed amount, because that is what was paid. One column cannot answer both without being wrong somewhere.

Gaps in coverage. Not every account has billing data wired up, and a new account will be running resources before it does. A calculated figure means there is a cost from day one rather than a blank.

The model

TWO COLUMNS, ONE TABLE
─────────────────────────────────────────────────────────────
cost_usd            = calculated rack rate
                      price list × hours running × units
                      written daily for every resource, NO discount

actual_cost_usd     = post-discount billing cost (provider source)
                      from Cost Explorer or CUR / Cost Mgmt / BigQuery
                      synced daily, last 3 days re-fetched,
                      NULL if not yet synced

cost_source         = label: 'calculated' or 'actual'
                      tells the reader which column is authoritative

How aggregations work

ZopNight uses a single SQL expression across every aggregate query:

-- Per resource-day: use the billed cost if that row has one,
-- otherwise fall back to cost_usd (rack rate)
SELECT
  COALESCE(actual_cost_usd, cost_usd) AS cost
FROM cost_records
WHERE...

The choice is made row by row, for each resource on each day. A billed row uses billing, an unbilled one falls back to rack rate, in the same organization and the same query. One account without billing does not switch the whole organization to rack rate. The same logic runs across summary, MTD, provider, budget, showback, and trends queries, so every number on every report comes from the same rule, with no per-report drift.

The cost-source label

Every report header carries one of five labels. The label is the contract with the reader:

• Unblended Cost (AWS), Amortized Cost (Azure), Net of Credits (GCP), or Mixed (by provider) when more than one applies = billed, post-discount, lagged. Use for: budgets, chargeback, monthly close.
• Rack Rate = calculated, pre-discount, no billing rows yet. Use for: estimates before billing lands, price-list comparisons.

A report that does not name its column is leaking trust. The two-source model is what makes the label honest.

When a single source is sufficient

There are organizations where a single source is fine:

• Very small, single-account. Calculated cost is close enough; the discount stack is minimal.
• Single-cloud, billing pipeline mature. If billing data is consistently fresh and the discount stack is well-understood, the actual column alone may serve.

But for any multi-account, multi-cloud, or governance-heavy environment, the two-source model is the defensible posture.

The mistake the two-source model prevents

Three common errors disappear when both columns are present and labelled:

1. The “we don’t know what we paid yet” stall. A team waits for monthly close to know last week’s cost. The calculated column unblocks them.
2. The “I thought we had a discount” surprise. Finance reports a rack-rate-flavored number. The bill arrives lower. Trust degrades. Two columns labelled explicitly prevent this.
3. The over-claimed savings. A scheduling rollout is reported at rack rate when the team actually pays a discounted rate, so the claim never shows up on the bill. The team loses sponsor confidence. Price the claim at the rate you actually pay where billing exists, and label the basis.

Two sources, labelled, picked per question.

Per-row vs per-rollup

cost_source is per-row in cost_records. Rollup tables (daily / monthly aggregates) derive their own cost_source:

• actual if any contributing row is actual
• calculated otherwise

A daily roll-up that is partially actual and partially calculated is labelled actual (with a tooltip explaining the partial state). Users reading the daily number get the most-recent best answer.

2. Demo

Same resource, same week, both columns visible:

RESOURCE: i-0abc123def (m5.large, us-east-1, RI-covered)

DATE        cost_usd (rack)   actual_cost_usd (billed)   cost_source
─────────────────────────────────────────────────────────────────────
2026-05-13     $2.30              $1.49                    actual
2026-05-14     $2.30              $1.49                    actual
2026-05-15     $2.30              $1.49                    actual
2026-05-16     $2.30              $1.49                    actual
2026-05-17     $2.30              $1.49                    actual
2026-05-18     $2.30              NULL                     calculated
2026-05-19     $2.30              NULL                     calculated  ← billing sync lag
─────────────────────────────────────────────────────────────────────
WEEK rack rate              $16.10
WEEK billing (actual)         $7.45    (5 days × $1.49)
WEEK using COALESCE          $12.05    ($7.45 + $4.60 fallback)

The COALESCE pattern gives the best-available-answer per day: actual where available, calculated where not. The week label is actual (because some days were actual) but the rendered tooltip notes the partial fallback.

3. Hands-on (6 min)

For your own organization, evaluate:

1. Do you currently maintain both columns (calculated + billed) in your
   cost data?
   Y / N

2. If N: which one is your default? What gap does the missing column
   create?
   Default: __________
   Missing column gap: __________

3. Which report uses which column?
   Budget reports:          __________ (should be billed)
   Savings claims:          __________ (should be real rate where billed)
   Anomaly detection:       __________ (should be best available)
   Monthly close:           __________ (should be billed)

4. Are the columns labelled visibly on the report?
   Y / N

If any “should be” doesn’t match what is, the report is structurally lying. The fix is either to swap the column source or to switch the report’s stated purpose.

Ask for it instead. The same task you just did in the console, asked in one sentence.

BEFORE  A ZopNight account with one cloud connected. Billing sync run at least once.
ASK     "Show the cost trend for last quarter, and tell me when billing data last synced."
CHECK   the sync timestamp before you trust the last few days. Recent days are usually incomplete, not cheap.

Tools behind it: get_cost_trends (read, Cost), get_billing_sync_status (read, Cost), get_currency_exchange_rate (read, Cost). Connection details are in the MCP integration docs.

4. Knowledge check

Q1

A new cloud account is connected to ZopNight today. Before its billing data has synced, what cost data does ZopNight show for it?

A. Nothing at all until the month’s invoice has closed
B. Only the billed cost, as soon as the account connects
C. Calculated rack-rate cost from the daily run, replaced by billed cost once synced
D. Only the resource list, with no cost figures until the billing sync has run

Q2

A team’s monthly variance report uses calculated (rack-rate) cost. Most likely consequence:

A. The report systematically overstates spend by the discount stack (typically 20-40%)
B. The report is accurate
C. The report is entirely irrelevant and ought simply to be ignored completely
D. The budget is wrong

Q3

The “cost_source” label on a daily rollup shows “actual” but a tooltip says “partial: last 2 days fallback to calculated.” How should this be interpreted?

A. The data is unreliable and should simply be ignored until the billing feed has fully caught up with it again
B. The data is best-available; actual where it has landed, calculated as a placeholder where billing sync has not yet caught up
C. Wait for the billing sync
D. The label is wrong

5. Apply

The two-source model is the spine of ZopNight’s cost surface. Visible places:

• Reports header: Cost Source label: “Unblended Cost”, “Amortized Cost”, “Net of Credits”, “Mixed (by provider)” or “Rack Rate”
• Costs → Reports → Summary cost chart: splits each data point into actualCostUsd and calculatedCostUsd
• get_billing_sync_status (MCP tool, via an AI assistant): per-account billing-sync health
• Recommendations cards: schedule savings use your real effective rate (last 30 days of billed cost divided by running hours) where billing is connected, and rack rate where it is not

Related lessons

• L5: Currency, FX, and the date-specific exchange rate (next)
• T0.M0.1.L3: Granularity vs. timeliness
• T3.M3.5: Showback design

Glossary terms touched

Unblended cost