"Detect and act": what CDCR means

Outcome

By the end of this lesson, you will be able to define CDCR, distinguish it from the report-and-ticket pattern, and articulate why “act” is the differentiator.

1. Concept

Most cost work is a project: somebody runs an exercise, finds waste, and the estate drifts back over the following quarter. The alternative is to treat it as a loop that never stops. The system keeps looking for waste, sorts each finding by how safe it is to act on, and makes acting a matter of one click, so a fix lands within minutes or hours rather than weeks.

CDCR is the name we use at ZopNight for that loop: Continuous Detect, Continuous Remediation. Remediation is the word for actually fixing the thing, as opposed to writing it down. CDCR is our own term, not an industry standard. You will not find it in the FinOps Foundation framework from M0.2, and other tools describe the same idea in their own words.

That loop is what this University is built around. Everything else in the curriculum is the working knowledge you need to run it.

The legacy pattern: report and ticket

The pattern CDCR replaces is older than cloud. Call it report-and-ticket:

1. A tool detects waste (idle EC2, oversized RDS, orphaned EBS)
2. The tool surfaces it in a report or dashboard
3. A human reads the report (days later, typically)
4. The human files a Jira ticket
5. The ticket waits in a backlog (weeks)
6. An engineer eventually picks up the ticket
7. The engineer makes the change in production (manual, error-prone)
8. The savings finally land
9. Loop back to step 1: but now the waste has accumulated for weeks

Every step is friction. Only the first one is fast: detection happens daily at worst. Steps 2 through 8 routinely take 30 days or more, and even a strong FinOps team lands somewhere between four and eight weeks per finding.

The waste accumulates throughout. A $500/month idle EC2 instance found on day 1 and remediated on day 45 has burned $750 of avoidable spend in the interim. Multiply by hundreds of findings in a typical estate and the structural waste is substantial.

The CDCR pattern

CDCR replaces the workflow:

1. Continuous discovery: the system polls and detects every few hours
2. Continuous classification: each finding is tagged by how it can be fixed
                              (one click / one click plus review / advice only)
3. Remediation: a fix happens in one of two ways
                 a person clicks Remediate and the fix runs end to end:
                   precondition, admin approval if the person is not
                   an admin, the cloud action, then validation
                 or a person makes the change by following the
                   How to Fix steps (advisory findings have no Remediate button)
4. Continuous verification: the fix is checked, then confirmed in billing
5. Loop continues: no ticket and no backlog between finding and fix

The time-to-remediation drops from weeks to hours or minutes. The avoidable waste between detection and remediation shrinks to almost nothing for anything that can be fixed in one click.

What “continuous” means specifically

LOOKING FOR RESOURCES     every 6 hours, and on demand when you ask
RE-SCORING FINDINGS       on a regular schedule, ready before you ask
ACTING ON A FINDING       minutes, once somebody clicks Remediate
ACTING ON AN APPROVAL     as soon as an admin says yes (requests expire after 48 hours)
SPOTTING A COST SPIKE     once a day (20:55 UTC)

Every one of those is short enough that the loop closes inside the same working day. No multi-week backlog, and no “I’ll get to it next sprint”.

What “act” means specifically

Acting is not one big red button. What the system will do depends on what the finding is:

KIND OF FINDING                    HOW IT GETS FIXED
─────────────────────────────────────────────────────────────
Orphan disk, oversized server      One click runs the fix end to end
Riskier or destructive fixes       One click, plus a review you type to confirm
Started by a non-admin             Waits for an admin to approve
Database resizing, some others     No Remediate button: you follow the How to Fix steps

The system can act, and it does not act recklessly. No fix runs until a person clicks Remediate. L3 covers exactly how that is enforced.

Why acting is the part that is hard to copy

The market for cost reporting is crowded, and most tools in it show you where the money went. Some also take narrow automated actions, such as buying commitments or stopping instances under a policy. CDCR asks a broader question: does the loop from detection to a safe, approved fix close across your whole estate?

CDCR is the practice that closes the gap between the report and the action. Here is how the main tool categories compare:

TOOL CATEGORY                 DETECT              ACT
──────────────────────────────────────────────────────────────────────
Reporting and allocation      Yes                 Usually limited to policy
platforms                                         actions or commitment
                                                  purchases
Commitment automation         Yes, for rates      Yes, buys and exchanges
services                                          commitments
Kubernetes and compute        Yes, in cluster     Yes, inside their scope
autoscalers
CDCR (ZopNight)               Yes                 Yes, across resource types,
                                                  with approval gates

This table uses ZopNight’s own definition of “act”: general-purpose, cross-cloud, closed-loop remediation. It is a point-in-time view, and the boundaries are ours, not an industry standard: several tools in these categories do have remediation surfaces, just narrower or differently scoped. Kubernetes-focused automation platforms (for example CAST AI) act inside the cluster and some adjacent services, not across the whole cloud estate. Treat the table as ZopNight’s framing of the category, not a neutral scorecard.

The underlying CDCR claim still holds: a tool that closes the loop saves more, faster, with less human friction, than one that surfaces the same data without acting.

Five things CDCR makes possible

1. Fixes land in hours, not weeks. This is the number that matters.
2. Savings compound. Each closed loop makes the next finding easier to see.
3. Better commitment decisions. A steady loop shows you how low your usage really goes, which is what a commitment has to be sized against (M0.3 L4).
4. Engineering time goes back to engineering. Nobody spends their week triaging cost tickets.
5. Ownership follows visibility. When a team watches the loop close in front of them, caring about the cost stops being something you have to ask for.

2. Demo

A real (anonymized) detect-and-act loop in a customer estate:

Day 0     Discovery sees vol-0xyz123 unattached (status "available") for 7+ days
Day 0     Recommendation fires: RC-002 (Orphaned EBS Volume), $34.10 a month
          Not Kubernetes-managed; classified as a one-click fix
Day 1     An admin opens the recommendation and clicks Remediate
  +0 min  Precondition: the volume is still unattached
  +0 min  Approval: skipped, because the person who clicked is an admin
  +1 min  Action: delete the volume
  +2 min  Validate: the volume is confirmed gone
Day 2     Billing sync shows the volume's charge has stopped

Two minutes from the click to the fix. No ticket, no waiting, no backlog.

When the person who clicks is not an admin, the same loop has an extra step:

T+0       Detection: RC-003, an oversized production server
T+0       An engineer (not an admin) clicks Remediate
T+0       Approval request sent to an admin by email
T+4 hr    Admin approves. Four hours is typical; people are slower than code
T+4:05    Action: resize the server (a short stop, then start at the smaller size)
T+4:10    Validate: the server is running at the new size
T+24 hr   Billing sync confirms the lower rate

Four hours from spotting it to fixing it. Slower than the admin path, and still roughly 170 to 250 times faster than report-and-ticket, which would have taken four to six weeks (672 to 1,008 hours).

3. Hands-on (5 min)

Walk your own current FinOps process against the CDCR loop:

1. Time from detection to surfacing in a report:
   __________ (target: hours)

2. Time from surfacing to engineering ticket:
   __________ (target: hours)

3. Time from ticket to remediation:
   __________ (target: hours; current state: weeks)

4. Time from remediation to verified savings:
   __________ (target: 24-48 hours via billing sync)

5. TOTAL CURRENT TIME-TO-REMEDIATION: ____________
   TARGET WITH CDCR: < 24 hours for one-click fixes, < 1 week with approval

The gap between current and target is the structural waste the CDCR model removes.

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. Discovery finished, so there is something to recommend on.
ASK     "Summarise our open recommendations: how many, what severity, what they would save."
CHECK   that detect is already solved for you. The rest of CDCR is what happens after this answer.

Tools behind it: get_recommendation_summary (read, Optimize), count_recommendations (read, Cost), get_recommendations (read, Optimize). Connection details are in the MCP integration docs.

4. Knowledge check

Q1

CDCR most accurately stands for:

A. Continuous Distribution and Continuous Replication, which is a data-platform term rather than a cost management one
B. Continuous Detect, Continuous Remediation: the operating model where waste is not just reported but acted on continuously
C. Cloud Detection / Cloud Response
D. Custom Detection, Custom Reporting

Q2

The fundamental difference between CDCR and report-and-ticket is:

A. CDCR uses newer tools
B. CDCR is cheaper to license
C. CDCR is fully automated whereas report-and-ticket is entirely manual, and nothing else separates the two of them
D. CDCR closes the loop within hours instead of weeks by replacing the ticket and backlog with a one-click fix

Q3

“CDCR auto-remediates everything by default” is most accurately:

A. True
B. True for prod, false for dev
C. False
D. True only for compute

5. Apply

ZopNight’s product surface implements CDCR throughout:

• Discovery → Recommendations → Remediate is the loop: one click runs the fix end to end, and findings without a Remediate button carry How to Fix steps you follow yourself
• Schedules are a separate feature: they start and stop resources at the times you set, and are not how recommendations get fixed
• Anomaly Detection → Alert → Root Cause is the same loop for spikes
• Approval gate: a fix started by a non-admin waits for an admin; riskier fixes add a review you type to confirm

The contract is the same everywhere: detect, classify, act within scope.

Related lessons

• L2: The cost of detect-only (next)
• L3: Read-only safety
• L4: What CDCR is NOT
• T2.M2.3: Auto-remediation

Glossary terms touched

CDCR · Safety Gate