What CDCR is NOT: the boundaries

Outcome

By the end of this lesson, you will be able to list the four things CDCR explicitly does NOT try to do and explain why those boundaries matter.

1. Concept

An idea this broad tends to grow. “Continuous Detect, Continuous Remediation” sounds like it might mean “automate everything”, and it does not.

Four boundaries mark out what CDCR is deliberately not trying to do. Knowing them is what lets you describe it to a sceptical audience without being caught out.

Boundary 1: CDCR is NOT autopilot for everything

The temptation: since CDCR can auto-remediate idle EC2, surely it can auto-remediate everything. Just turn on every rule.

Why this is wrong: L3’s layers exist for a reason. Some actions are cheap and undoable, such as terminating an idle machine after taking a copy of its disk. Some can be undone but will interrupt people, such as resizing a production load balancer. Some cannot be undone at all: database changes, anything holding state, anything near customer data.

The defaults are cautious because the two kinds of mistake are not the same size. Getting a saving wrong costs you $300 you did not save. Getting a database change wrong costs six figures of downtime and a good deal of trust.

The accurate version: the system can act, and you decide where. Anything risky defaults to showing you rather than doing it, and you switch automatic fixing on one rule and one scope at a time.

Boundary 2: CDCR is NOT a way to bypass change management

The temptation: since CDCR closes the loop in minutes instead of weeks, surely it removes the need for change management.

Why this is wrong: change management exists for reasons that have nothing to do with how fast FinOps moves. It produces the audit trail compliance asks for. It keeps other teams informed, so nobody has to say “I had no idea that was happening while support was on fire”. It holds the instructions for undoing things, and it decides who gets woken up when something goes badly. CDCR replaces none of that; it plugs into it.

Where a company already runs change management well:

• The CDCR approval gate routes through the change-management system
• Audit logs feed the compliance evidence trail
• Notifications go to the same channels as other operational changes
• The Operate cadence (see M0.2 L4) includes a change-window awareness

The accurate version: CDCR makes change management faster where cost is concerned, it does not remove it. Automatic action on tagged non-production is a scope your own change process has approved in advance, once, instead of case by case. Everything outside that scope goes through the usual route.

Boundary 3: CDCR is NOT a substitute for cost ownership

The temptation: the FinOps practice can outsource cost ownership to CDCR. The system finds and fixes problems. Teams don’t have to think about cost.

Why this is wrong: the third FinOps principle, everyone takes ownership for their own usage, falls apart if teams stop paying attention on the grounds that a tool has it covered. That is worse than having no tool, because the waste then piles up in exactly the places the tool cannot reach: how the system was designed in the first place, which is lever 4 from M0.2 L3.

CDCR covers levers 1 and 2, removing waste and resizing what is too big. It cannot touch lever 4. The decisions that move cost the most, where a workload runs, how it is built, whether you build it or buy it, stay with the engineers who own it.

The accurate version: CDCR keeps the day-to-day floor clean. The ceiling is set by design decisions, and those stay with engineering. A healthy organisation has both: the loop running underneath, and teams making the design calls that set what the estate costs at all.

Boundary 4: CDCR is NOT a single-vendor lock

The temptation: since CDCR works well as an integrated suite, the customer should consolidate every cost surface to one vendor.

Why this is wrong: the FinOps Foundation’s framework covers 22 capabilities across four domains, which is more ground than any one vendor genuinely covers. ZopNight works on automating usage optimisation, on splitting cost across teams, and on making infrastructure cost visible. Several neighbouring jobs belong elsewhere: managing commitments (ProsperOps, Spot Eco), tracking what you spend on software subscriptions (Vantage connects to more of these), and reporting cost per unit for things outside infrastructure, which usually means your own reporting tools.

A mature practice normally runs two or three tools, each doing a different job. CDCR is one strong piece of that, not the whole of it.

The accurate version: CDCR is one solid tool among several. This University teaches the framework so you can assemble the right set for your own situation, rather than defaulting to putting everything with one vendor.

The five things CDCR IS, restated

To balance the four “is nots,” here are the five “is” claims:

1. CDCR is a way of working, the loop, not a product
2. CDCR is measured on how long a fix takes, hours instead of weeks on the safe class
3. CDCR is cautious by design, with layered permissions, conservative defaults and databases off the table
4. CDCR is yours to control, since every automatic path is switched on by you
5. CDCR holds up in a security review, because it reads by default and every change it makes is recorded

Why the boundaries matter for the conversation

When somebody takes this to a leadership meeting, the boundaries are what keep the conversation honest.

• Promise too much (“we will automate all of FinOps”) and the first exception costs you your credibility
• Promise too little (“it is another dashboard”) and you have described the thing it is not
• Skip the boundaries (“we do not need change management any more”) and you will fall out with another team inside a month

What works is being precise about scope. CDCR closes the gap between finding and fixing for a defined set of actions, with a safety design that has been through security review. Everything outside that set follows the normal process.

2. Demo

A real internal conversation pattern, condensed:

SPONSOR: "CDCR can automate everything in our FinOps practice, right?"

FINOPS:  "It can automate the safe-class operations: schedule start/stop on
         tagged non-prod, terminate orphan storage, apply specific autoscaler
         policies. About 60-70% of recurring findings."

SPONSOR: "What about the other 30%?"

FINOPS:  "Approval-gated for rightsizing and similar. Show-only for any
         database change or stateful work. Architectural decisions stay with
         engineering."

SPONSOR: "So we still need a FinOps team?"

FINOPS:  "Yes. A smaller one, spending its time on the judgement calls and the
         design work instead of clearing tickets. Each person gets further."

SPONSOR: "And we can disable change management?"

FINOPS:  "No. CDCR integrates with change management on the gated rules and
         provides better audit trails than today. The change process doesn't go
         away. It gets faster on the cost surface."

SPONSOR: "OK: let me re-pitch this to the exec team correctly."

The conversation lands when the boundaries are explicit. Without them, the executive pitch oversells, the Security team pushes back, and the rollout stalls.

3. Hands-on (5 min)

Draft your own one-page CDCR scope statement:

WHAT CDCR DOES IN THIS ORGANIZATION:
  - __________________________________________
  - __________________________________________
  - __________________________________________

WHAT CDCR DOES NOT DO IN THIS ORGANIZATION:
  - __________________________________________
  - __________________________________________
  - __________________________________________

WHO OWNS WHAT CDCR DOES NOT DO:
  - Architectural cost decisions:  ____________
  - Database optimization:          ____________
  - Cost forecasting:               ____________
  - Commitment design:              ____________
  - Cross-team cost arbitration:   ____________

WHAT TRIGGERS A REVIEW OF THESE BOUNDARIES:
  - __________________________________________

Hand this document to leadership before the CDCR pitch. It prevents the “expected everything, got something specific” reaction.

4. Knowledge check

Q1

A leadership member says: “Now that we have CDCR, we can disband the FinOps team.” Most accurate response:

A. Yes, since the tool handles all of that for you
B. No: CDCR handles operational findings (levers 1 and 2)
C. Yes, except for finance
D. Yes, after one year

Q2

A team enables auto-remediation on every rule, including database changes. The system blocks the database rules. The team escalates: “ZopNight is broken.” Most accurate response:

A. Escalate to support
B. Disable the denylist
C. The database denylist is intentional and hardcoded
D. Switch over to a different tool entirely instead

Q3

The four boundaries of CDCR are:

A. Not autopilot for everything · Not bypass for change management · Not a substitute for cost ownership · Not a single-vendor lock
B. Cost, performance, reliability, security
C. AWS, GCP, Azure, other
D. Discovery, then recommendation, then remediation, and finally the audit trail that records all of it afterwards too

5. Apply

The boundaries are reflected in ZopNight’s product:

• Auto-remediation toggle per rule lets customers choose where to delegate
• Database denylist is enforced in code, not in policy: cannot be turned off
• Approval gate configurable per rule integrates with change management
• Recommendations remain show-able even when auto is off: ownership stays with the team
• MCP read-only enforcement: even AI-agent integrations cannot mutate

The boundaries are also reflected in the Competition Parity positioning: ZopNight does not claim to be a single-vendor solution; it claims to be a strong execution layer that integrates with broader FinOps practice.

Module quiz

You have now completed all four lessons of M0.6 and all 28 lessons of Track 0. The module quiz (10 questions, 80% pass) is on the Operator certification page. Passing completes the Operator-tier foundation.

Track complete: what’s next

You have completed Track 0: Cloud Cost Foundations.

Operator certification. Take the Operator certification exam (free, 22 questions, 35 min, open-book). Pass to earn the ZopDev Operator digital badge, shareable to LinkedIn.

Or go deeper. Continue to Track 1: ZopNight Operator to learn the product, or jump to a role-based path curated for your role.

Related lessons

• L1: What CDCR means
• L2: The cost of detect-only
• L3: Read-only safety
• T6.M6.5: What’s NOT writable via MCP

Glossary terms touched

CDCR boundaries · Change management integration · Single-vendor lock · Operational floor · Architectural ceiling