Outcome
By the end of this lesson, you will be able to configure the three priced-plan guardrails, read the dollar figure they surface in a pull request, and choose thresholds that hold rather than being disabled within a month.
| Tier | Engineer |
| JTBD | ”Stop a $9,000-a-month change reaching production because nobody priced it at review time.” |
| Personas | Platform Engineer · FinOps Lead · SRE |
| Prerequisites | M5.8.L2 · M5.6.L3 (pre-merge cost estimation) |
| Time | 9 minutes |
| Bloom verb | Configure (Apply), Read (Apply), Choose (Evaluate) |
1. Concept
Cost governance runs in the same engine as the posture rules. It is not a separate tool bolted on, which matters: one decision point, one required check, one place to look.
THE THREE GUARDRAILS
max_monthly_cost a ceiling on the priced monthly cost of what this plan creates
budget_cap_total a ceiling on the total, so a plan cannot push a scope past a cap
max_cost_delta_* a ceiling on the CHANGE this plan makesAll three surface the $/mo figure in the pull request, which is the actual point. A developer sees what their change costs at the moment they can most cheaply change their mind.
Why delta is usually the right one
max_monthly_cost governs the ABSOLUTE cost of a plan's resources. Good for: catching a single oversized thing. Bad at: a large legitimate stack trips it every time, and people stop reading it.
max_cost_delta_* governs the CHANGE. Good for: the actual failure mode, which is a change that adds far more than the author realised. Better because a big existing stack does not constantly re-alarm.The pattern to avoid is the one every alerting system teaches: a guardrail that fires on things everyone knows about, every time, stops being read. Delta guardrails fire on the new thing, which is the thing worth reading.
Choosing thresholds that survive
THE WRONG WAY Pick a round number that feels responsible. $500. Watch it fire on 40% of pull requests. Watch someone add an exception. Watch the exception become the norm.
THE RIGHT WAY 1. Run WARN-ONLY for two weeks. 2. Plot the distribution of your actual deltas. 3. Set the threshold ABOVE the routine band, so it fires on the tail rather than the body. 4. Re-check quarterly, because the band moves.A guardrail should fire rarely enough that firing is informative. If it fires on more than a small minority of pull requests, it is measuring your normal workload rather than catching outliers.
What “priced” means, and its limits
The figure comes from a priced plan: the engine prices the resources the plan declares. That inherits both the strengths and the limits you met in M5.6.L3.
IT PRICES WELL resources with a clear shape and a published rate (instances, volumes, managed databases)
IT PRICES POORLY OR NOT AT ALL usage-driven costs: data transfer, request volume, serverless invocation counts
Nothing in a plan says how many requests a Lambda will receive.So a guardrail catches provisioned cost reliably and consumption cost not at all. A plan that adds one NAT gateway and a Lambda will price the NAT gateway correctly and tell you nothing about the egress that the Lambda’s traffic will drive.
Being explicit about that with your team prevents the failure of trust that happens when someone discovers a guardrail passed a change that turned out expensive.
Where it fits with the other cost gates
M5.6.L3 Infracost or equivalent, pre-merge Estimates cost from the plan, in the PR.
M5.8.L3 ZopNight guardrails, same engine as posture Prices the plan and applies POLICY to it, with a decision your required check consumes.
M2 / cost reports What actually happened, after the fact.The distinction between the first two is a decision. A pre-merge estimator tells you the number. A guardrail applies a rule to the number and emits a verdict, in the same place your posture verdicts already appear. If you already run an estimator and it is working, the guardrail’s value is the policy and the consolidation, not the pricing.
2. Demo
Setting a delta guardrail that survived:
STARTING POINT A team had a $500 max_monthly_cost guardrail, added after an incident. Six weeks later it was disabled.
WHY IT FAILED It fired on absolute cost, so every pull request touching their main stack tripped it, because the stack costs more than $500 in total. It fired on 40% of PRs and told nobody anything.
First an exception was added. Then a second. Then it was disabled "temporarily".
THE REBUILD
STEP 1: two weeks, warn-only, delta guardrail with no threshold set, just recording.
DISTRIBUTION OF DELTAS, 78 pull requests $0 41 (no cost change) $1 - $50 22 $51 - $200 9 $201 - $500 4 $501 - $2,000 1 above $2,000 1 ($3,400: a new multi-AZ RDS)
STEP 2: threshold set at $500. Fires on 2 of 78, about 2.5%. Both were genuinely worth a conversation.
STEP 3: the $3,400 case, in the PR The author had not priced it. Multi-AZ was copied from a neighbouring module. The review changed it to single-AZ for a staging database, saving $1,700/mo on a change that would otherwise have merged unremarked.
ONE YEAR LATER: still enabled. Threshold reviewed twice, moved to $650 as the estate grew.
WHAT THE GUARDRAIL DID NOT CATCH Three months in, a change adding an NAT gateway and a high-traffic Lambda priced at $34/mo delta and passed.
Actual outcome: $34 of NAT gateway plus about $900/mo of data processing driven by the Lambda's traffic.
NOT A BUG. Nothing in a plan says how many requests a Lambda will receive. The guardrail prices PROVISIONED cost, and consumption cost is invisible to it.
The team's response was the right one: they added a note to their PR template asking authors to flag traffic-driven changes, and they kept the guardrail for what it does catch.3. Hands-on (6 min)
1. Enable a delta guardrail in warn-only mode. Record deltas across two weeks of pull requests. PRs observed: ______ $0 deltas: ______ Largest delta: $______
2. Where does your routine band end? $______ Set your threshold above it, not at a round number that felt responsible.
3. Predict the fire rate at your threshold: ______% Above ~10%? It is measuring your normal workload.
4. Find one PR from your history that added significant consumption-driven cost (traffic, requests, invocations). Would a guardrail have caught it? Y / N Write what you will do instead: ______________________________________________
5. If you already run a pre-merge estimator, state what the guardrail adds beyond it: ______________________________________________4. Knowledge check
Q1
A team sets max_monthly_cost at $500 and it fires on 40% of pull requests. The problem:
A. The threshold is too low and should be raised
B. Warn-only mode was not used first
C. The plan is not being priced correctly
D. The guardrail type is wrong
Show answer
Correct: D. max_monthly_cost governs absolute cost, so every PR touching a stack that already costs more than the threshold trips it. max_cost_delta_* governs the change, which is the actual failure mode and does not re-alarm on a large existing stack. Raising the threshold on the wrong guardrail type postpones the problem. A guardrail firing on things everyone already knows about stops being read, then gets an exception, then gets disabled.
Q2
A change adds a NAT gateway and a high-traffic Lambda. The guardrail prices it at $34/month and passes; actual cost is around $930/month. This is:
A. Expected
B. A pricing bug to report
C. A sign that the plan was not fully expanded
D. Caused by the delta guardrail rather than the absolute one
Show answer
Correct: A. The guardrail prices provisioned cost from what the plan declares, and consumption cost is invisible to it: nothing in a plan says how many requests a Lambda will receive. Being explicit about that limit with your team prevents a loss of trust when someone discovers it. The productive response is a PR-template prompt asking authors to flag traffic-driven changes, while keeping the guardrail for the provisioned cost it does catch reliably.
Q3
You already run a pre-merge cost estimator. What does a ZopNight cost guardrail add?
A. More accurate pricing
B. Policy and consolidation
C. Coverage of consumption-driven costs
D. Retroactive analysis of merged changes
Show answer
Correct: B. An estimator tells you the number; a guardrail applies a rule to the number and emits a verdict, in the same engine and the same required check as your posture decisions, so there is one decision point rather than two tools to read. C is specifically not true: consumption costs are invisible to both. If your estimator is working, adopt the guardrail for the policy and the single decision point, not because you expect better numbers.
5. Apply
Run warn-only for two weeks and plot your actual delta distribution before choosing a threshold. Setting it above the routine band is the single decision that determines whether the guardrail is still enabled a year from now.
Tell your team explicitly what it does not price. A guardrail that is trusted for provisioned cost and known to be blind to consumption cost is more useful than one people quietly assume covers everything.
Related lessons
- L2: Builtin rules and custom Rego
- L4: CI wiring, scans and overrides (next)
- T5.M5.6.L3: Pre-merge cost estimation
- T5.M5.4.L3: Network architecture and egress cost
Glossary terms touched
Priced plan · max_cost_delta · Provisioned vs consumption cost · Warn-only mode