Outcome
By the end of this lesson, you will be able to read every field on a recommendation card, decide apply / dismiss / snooze with confidence, and execute a weekly triage flow.
| Prerequisites | M2.1.L1 - L4 |
| Time | 9 minutes |
1. Concept
A recommendation card exists to get a decision out of you, and there are only three available.
Apply it. Dismiss it, because it does not apply here. Or snooze it, because it does apply and not today.
Every field on the card is there to help you pick one of those three. Nothing on it is decoration.
THE THREE DECISIONS: APPLY Execute the recommended action DISMISS Mark not applicable (choose Forever) SNOOZE Dismiss with an end date; it reopens when that endsMost findings get one of these three actions. The card shows you what you need to decide.
Card anatomy: every field
┌─────────────────────────────────────────────────────────┐│ RC-001 · Idle EC2 Instance ││ ────────────────────────────────────────────────────── ││ Resource: i-0abc123def (m5.large) · us-east-1 ││ Account: prod-aws-us-east-1 ││ Status: OPEN ││ Severity: medium ││ Category: idle ││ ────────────────────────────────────────────────────── ││ CURRENT COST $11.65 / month ││ OPTIMIZED COST $0 / month ││ POTENTIAL SAVINGS $11.65 / month ($140/year) ││ ────────────────────────────────────────────────────── ││ EVIDENCE ││ Status: stopped ││ Stopped: 47 days ago ││ Last activity: 2026-04-03 (manual stop by ops-team) ││ Attached: 1 EBS volume (100 GB gp3, $8.00/mo) ││ 1 Elastic IP ($3.65/mo) ││ Snapshots: 3 (oldest 2024-11-02) ││ ────────────────────────────────────────────────────── ││ REMEDIATION (4 steps) ││ 1. Verify no workload depends on this instance ││ 2. Create an AMI backup if needed ││ 3. Terminate the instance via EC2 Console ││ 4. Delete associated EBS volumes if no longer needed ││ ────────────────────────────────────────────────────── ││ ACTION ││ [Apply Remediate] [Dismiss ▾] [View Resource →] │└─────────────────────────────────────────────────────────┘Every field is there because it informs the decision.
Reading the header: what is this?
RULE ID + NAME (RC-001 · Idle EC2) Click rule name to see rule documentation Same rule may match multiple resources
RESOURCE Provider + region + instance type Click to jump to resource detail
ACCOUNT Which account hosts this resource Matters for blast radius + IAM
STATUS OPEN (action available) APPLIED (already acted on) DISMISSED (not applicable, or snoozed until a date; a snooze reopens when it ends)
SEVERITY + CATEGORY Drives routing + prioritization (M2.1.L1, L2)The header tells you what the rule is + which resource it fires on.
Reading the savings line
CURRENT COST: what the resource is costing now Billed (actual) cost where billing data exists, otherwise calculated from the rate catalog For a stopped EC2: only what still bills (EBS, Elastic IP)
OPTIMIZED COST: what it would cost after action For idle/orphan: $0 (delete) For rightsizing: lower SKU rate For commitment: discounted tier rate
POTENTIAL SAVINGS: the delta Monthly: most actionable framing Annualized: for finance / leadership context
ANNUAL PROJECTION Often the deciding number for approvals "$140/year saved" is more compelling than "$11.65/mo"The savings line is the value proposition. Bigger numbers = more attention.
Reading the evidence panel
The evidence shows what triggered the rule:
FOR IDLE EC2 (state-based rule): Status: stopped Time-in-state: 47 days Last activity: when + by whom (from state history) Attached resources: what else is involved
FOR EC2 RIGHTSIZING (metrics-based rule): CPU utilization: p95 over 30 days Memory utilization: p95 over 30 days Lookback window: explicit Current instance type vs proposed
FOR DISCOUNT (TierRates rule): Current tier: on_demand Proposed tier: spot / reserved / etc. Rate comparison: $/hr per tier Eligibility: why workload qualifies
FOR COMPLIANCE (configuration rule): Current setting: e.g., multiAz=false Required setting: multiAz=true Policy reference: which standardThe evidence is reproducible: you can cross-check by inspecting the actual cloud resource. This is why ZopNight findings are trustworthy.
Reading the remediation steps
Step-by-step plan in plain language:
TYPICAL STRUCTURE (3-5 steps): 1. Verify (check assumptions) 2. Backup (snapshot, AMI, etc.) 3. Execute action (terminate, modify, etc.) 4. Clean up (associated resources) 5. Document (audit trail)
FOR ALLOWLISTED RULES: "Apply Remediate" button executes these steps in order With snapshot-first safety Full audit log
FOR ADVISORY RULES: Team executes manually Console link provided Steps printable for handoffThe remediation is the operator’s playbook. Print or follow live.
The action buttons: choosing wisely
APPLY REMEDIATE Trigger auto-remediation (if allowlisted, opted in, and the safety gate agrees for this resource) Otherwise: opens console link + shows manual steps Audit log records: who, when, what
DISMISS (split button: pick a period) 1 week, 1 month (default), 3 months, 6 months, or Forever Forever = "not applicable to my situation" Any other period = a snooze: it reopens when the period ends Record why in your ticket or channel (no comment field) Use a snooze when "this is real but not now"
VIEW RESOURCE Jump to resource detail page See full context: usage, dependencies, owner Useful for unclear findingsThe action buttons are how decisions become actions.
When to APPLY: three signals
SIGNAL 1: RESOURCE IS TRULY UNUSED Evidence matches reality Cross-check with team's knowledge Owner confirms (or doesn't object)
SIGNAL 2: SAVINGS IS MEANINGFUL Worth the audit overhead $5/mo idle EBS: maybe not worth the time $500/mo idle RDS: definitely worth it
SIGNAL 3: REVERSIBILITY PLAN EXISTS Snapshot ready Ticket / approval documented Team aware of actionThree signals = strong “apply” candidate. Two of three = “consider; verify the third.”
When to DISMISS: two reasons
REASON 1: RULE IS WRONG FOR THIS RESOURCE Stopped EC2 used as quick-restart DR target → not idle Single-replica K8s deployment intentionally single-replica RDS without Multi-AZ in non-prod (acceptable per tier policy)
REASON 2: ACTION IS UNSAFE Production database; can't terminate Resource owns by another team; coordinated change needed Compliance requires the current configuration
ALWAYS RECORD THE REASON (ticket or team channel): "DR target: must remain available" "Intentional single-replica per architecture" "Compliance-required Multi-AZ"
Future engineers see the reason; don't have to re-investigate.Dismiss lasts for the period you pick: 1 month by default, or Forever. The recorded reason preserves the decision rationale.
When to SNOOZE: timing concerns
USE SNOOZE WHEN: Code freeze prevents action this week Owner on PTO; can't get approval Scheduled change window is next sprint Dependent on upstream system change
SNOOZE PERIODS: 1 week, 1 month (default), 3 months, 6 months
RECORD WITH SNOOZE: Always reference the reason Link to ticket if planned Set realistic re-evaluation dateSnoozed findings reappear; the recorded reason tells you why they were deferred.
Triage cadence
Most teams: weekly triage during Operate meeting.
WEEKLY TRIAGE FLOW (45 min for typical team):
T+0 Open Recommendations T+5min Filter: severity ≥ high; status = open T+10min Sort by savings descending T+15min Triage top 10 findings: Apply (with cert rule): 2 minutes Dismiss (reason recorded): 1 minute Snooze (reason + ticket): 2 minutes Average: 2 minutes per finding T+45min Done. 30 findings triaged.
REALIZED SAVINGS per session: Typical: $5K-$30K/mo in apply actions Compounds weeklyThe cadence keeps the backlog flowing without becoming a daily distraction.
2. Demo
A team’s weekly triage flow:
WEEK 1 (mid-size team's first cycle):
T+0 Open Recommendations → filter severity ≥ highT+30 sec 47 high-severity findings Sort by savings descending
T+1 min FIRST CARD: $5,200/mo idle EKS cluster Read evidence: cluster stopped 89 days 0 active workloads Owner: data team (in PTO) Cross-check: confirm with platform team via Slack Owner-team confirms: cluster forgotten; no dependency Apply: triggers auto-remediation (allowlisted lever) Notification fires; action completes in 3 min Saved: $5,200/mo
T+5 min NEXT: $4,800/mo Multi-AZ RDS in non-prod Category: compliance Evidence: RDS is in dev environment; Multi-AZ enabled Decision: non-prod doesn't need Multi-AZ Dismiss with reason: "Non-prod; Multi-AZ not required by tier policy" Period: Forever (reason recorded in the ticket)
T+8 min NEXT: $3,400/mo over-provisioned RDS in prod Category: rightsizing Evidence: 30-day p95 CPU = 25%; memory 35% Decision: real, but needs maintenance window Snooze 7 days; add ticket reference DEV-4521 Ticket note: "Planned for next maintenance window" Will reappear next week
T+15 min NEXT: 7 more findings: 3× idle EBS volumes ($65/mo total): Apply (auto-rem) 2× orphan EIPs ($25/mo total): Apply (auto-rem) 1× missing tag on RDS: Dismiss (will be auto-tagged this week) 1× security finding (privileged container): Snooze; add to security-debt ticket
T+20 min 20 more findings, triaged the same way (not shown)
T+45 min Total: 30 findings triaged Realized savings (apply actions): $14,800/mo Deferred (snooze): $4,200/mo (planned for next week) Dismissed (with reasons): $7,300/mo opportunity cost
DOCUMENT in #finops-weekly: "Week 21 triage complete. 30 findings reviewed. Applied: 12 ($14.8K/mo recurring savings). Snoozed: 8 (planned work). Dismissed: 10 (with reasons; tier policy). Next triage: Friday next week."Forty-five minutes per week for the FinOps Engineer. Compounds across quarters.
3. Hands-on (5 min)
Triage your top 5 open recommendations:
□ STEP 1: Open Recommendations Filter: severity ≥ high; status = open Sort by savings descending
□ STEP 2: Top 5 cards For each: Card 1: __________ Decision: □ Apply □ Dismiss □ Snooze Reason: __________ Card 2: __________ (same) Card 3: __________ (same) Card 4: __________ (same) Card 5: __________ (same)
□ STEP 3: Document Realized savings this session: $_____/mo Deferred: $_____/mo Dismissed: $_____/mo (opportunity cost)
□ STEP 4: Schedule weekly cadence Day / time: __________ Owner: __________ Channel for results: __________A 30-minute exercise reveals your triage muscle. Compound weekly.
4. Knowledge check
Q1
A recommendation card shows $200/mo savings, evidence is solid, but the resource is intentionally always-on for a DR pattern. The right action:
A. Apply
B. Snooze it for 1 month, then check it again
C. Dismiss it: “DR target, must stay up”
D. Ignore
Show answer
Correct: C. Dismiss, choosing Forever, and record the reason where future engineers will see it. A snooze is meant to end, and ignoring the card leaves it open in every triage.
Q2
“Current cost” on a card uses which cost column?
A. Always the list (rack) rate
B. Billed cost where billing exists, else a calculated cost
C. Rack rate for idle and orphan, billed cost for the rest
D. Whichever column the customer chose in reporting settings
Show answer
Correct: B. Every rule reads the same per-resource monthly cost: billing-backed where billing data exists, otherwise calculated. The rack-rate catalog is a separate input, used only to derive catalog-based savings. See T0.M0.4.L1 for full coverage.
Q3
A team’s triage cycle frequency. Best practice:
A. Daily
B. Monthly (too slow; backlog grows)
C. Weekly: matches the Operate cadence
D. Quarterly (way too slow)
Show answer
Correct: C. Keeps backlog flowing without becoming daily distraction. 30-60 minutes per week is the typical investment for meaningful savings. Weekly Operate cadence is the sweet spot.
5. Apply
Recommendations is the canonical triage surface. Pair with weekly Operate meeting. Document apply / dismiss / snooze in #finops-weekly.
For your team: 45 minutes per week → typically $5K-$30K/mo in realized savings. The compounds across quarters.
Module quiz
Complete M2.1 → 10-question module quiz.
Related lessons
- L1: The 11 categories
- L2: Severity ladder
- L3: Rule interface
- L4: Pricing model
- M2.2: Reading evidence
- T0.M0.4.L1: Rack rate vs billing
Glossary terms touched
Recommendation card · Apply / dismiss / snooze