Outcome
By the end of this lesson, you will be able to name what each Bedrock rule actually detects, predict which ones can produce a dollar figure and which are structurally advisory, and route each finding to the right owner.
| Tier | Engineer |
| JTBD | ”Know what each Bedrock rule catches so I can route attention to the highest-impact findings.” |
| Personas | ML Engineer · Platform Engineer · FinOps Lead |
| Prerequisites | M2.11.L1 |
| Time | 9 minutes |
| Bloom verb | Name (Remember), Predict (Apply), Route (Apply) |
1. Concept
The single most useful thing to internalise about this family is what it is not. The Bedrock rules do not inspect your prompts, your token counts, or your model choice at the application layer. They read the control plane: what Bedrock objects exist, whether they are being invoked, and what rate they bill at.
That is why the family clusters into two shapes: provisioned throughput economics, and orphaned Bedrock artifacts.
THE 16 BEDROCK RULES
PROVISIONED THROUGHPUT (resource type: bedrock-pt)RC-1601 PT Idle idle highRC-1602 PT Underutilized rightsizing mediumRC-1603 PT Below Break-Even discount mediumRC-1609 Invocation Logging Disabled governance lowRC-1610 PT on Older Model Generation rightsizing low
ORPHANED ARTIFACTSRC-1604 Custom Model Orphan orphan mediumRC-1605 Imported Model Idle idle mediumRC-1606 Knowledge Base Idle orphan mediumRC-1607 Agent Idle advisory mediumRC-1608 Guardrail Unused advisory lowRC-1632 Marketplace Endpoint Idle idle highRC-1633 Inference Profile Unused advisory lowRC-1634 Custom Model Deployment Unused advisory low
POSTURERC-1615 Guardrail Missing PII Protection security highRC-1630 Agent Without Guardrail security highRC-1631 Custom Model Without CMEK compliance mediumNote the gap in the numbering. RC-1611 through RC-1628 are SageMaker, not Bedrock; the Bedrock family resumes at RC-1630. RC-1629 does not exist.
The three rules that carry real money
RC-1601 PT IDLE biggest lever Signal: Invocations = 0 over a 30-day lookback Savings: the FULL current monthly cost, not a fraction. A no-commitment PT is freely deletable, so the whole MU/hr x 730 bill is recoverable. Guard: ABSTAINS on any committed term (OneMonth/SixMonths). A committed PT bills to term-end whatever you do.
RC-1632 MARKETPLACE ENDPOINT IDLE high severity Same shape as RC-1601 on a marketplace-model endpoint.
RC-1610 PT ON OLDER MODEL GENERATION live, real delta Signal: the PT's model is in the deprecated set (claude-v1/v2/instant, titan-text-express/lite, j2-mid/ultra, command-text, llama2-13b/70b) Savings: cost x (1 - newRate/oldRate), both rates looked up for real. Never a fabricated fraction. Guard: ABSTAINS if either rate is missing, if the successor is not actually cheaper, or on a committed term.The absent-series trap, and why RC-1601 is careful
Invocations in the AWS/Bedrock namespace is a Sum-statistic count. A series exists only when invocations are greater than zero. So a completely idle provisioned throughput produces a missing metric key, not a zero.
RC-1601 treats an absent series as the authoritative idle signal, but only when the metrics map for the org is non-empty. If the whole map is empty, the rule hard-abstains, because an org-wide metrics fetch outage is indistinguishable from “every PT is idle” and would otherwise mass-fire delete recommendations.
This is worth understanding as a pattern, not just a Bedrock detail: absence of evidence is only treated as evidence when the surrounding fetch demonstrably succeeded.
Two rules that are currently structural no-ops
Being able to explain why a rule does not fire is as useful as knowing what it detects.
RC-1603 PT BELOW BREAK-EVEN Detection works: activity present, but daily invocations below the 1,000/day floor. It ABSTAINS anyway. The break-even needs the projected on-demand cost, which needs per-token on-demand rates. The PT-side rate is ingested; the token-side is not. It emits nothing rather than a $0 recommendation.
RC-1607 AGENT IDLE A producer-contract gap. The metric query asks for namespace AWS/Bedrock, metric Invocations, dimension AgentId. Bedrock Agent metrics actually live in AWS/Bedrock/Agents as InvocationCount, dimensioned by the alias ARN. There is no AgentId dimension, so the query can never return a datapoint for any agent, active or idle. The rule therefore refuses to treat an absent series as idle, and fires only on a present series showing zero. In practice that means it does not fire.RC-1607 is the cautionary tale. An earlier version did treat the absent series as the idle signal, and recommended deleting every discovered Bedrock agent regardless of real traffic.
Why so many are advisory
advisory is a real category value, and four Bedrock rules carry it: RC-1607, RC-1608, RC-1633, RC-1634. The reason is consistent: the artifact itself is free. An agent, a guardrail, an inference profile and a custom-model deployment cost nothing to keep. The money lives in the foundation-model invocations underneath, which are already tracked against the PT or the on-demand spend.
So the recommendation is a cleanup signal with no recoverable dollar attached. Filing it under idle would have been wrong twice over: it would imply money that is not there, and a cost-driven category with $0 savings gets dropped by the low-savings suppressor and would never reach you at all.
Action paths: who fixes what
Every Bedrock rule is customer-executed. None of them can be applied in one click. Two, RC-1604 custom-model delete and RC-1608 guardrail delete, appear on the orphan-cleanup list as guided steps. Guided means you type a confirmation and a person reads the change first. It does not mean automation.
RULE OWNER ACTION────────────────────────────────────────────────────────────────RC-1601/1632 Platform / ML Confirm no traffic, migrate to on-demand, delete the PTRC-1602 Platform / ML Reduce model unitsRC-1610 ML Recreate PT on the successor model, benchmark, migrate, deleteRC-1604/1605 ML Delete the orphaned model (guided)RC-1606 ML Delete the unreferenced KBRC-1608/1633/ ML Cleanup; no cost attachedRC-1634RC-1609 Platform Enable invocation loggingRC-1615/1630 Security / ML Attach a guardrail; add PII protectionRC-1631 Security Recreate the custom model with a customer-managed keyThe boundary is the same one drawn in M2.3.L5 for databases: ZopNight surfaces and quantifies; the customer’s team executes.
2. Demo
A real Bedrock audit, read the way the rules actually report it:
ORG: 41 discovered Bedrock resources across 2 accounts
FINDINGS BY RULE
RC-1601 PT Idle 2 findings bedrock-pt/us-east-1/claude-3-sonnet-pt-01 Invocations series: ABSENT (org metrics map populated) commitmentDuration: (none) Current cost: $2,190/mo (3 MU x $1.00/MU-hr x 730) Savings: $2,190/mo (full recovered cost) bedrock-pt/us-west-2/titan-express-pt-02 commitmentDuration: SixMonths -> ABSTAINED. Committed term; bills to term-end regardless.
RC-1610 PT on Older Model Generation 1 finding bedrock-pt/us-east-1/claude-v2-pt-03 modelArn matches deprecated set: anthropic.claude-v2 successor: claude-3-5-sonnet oldRate $1.00/MU-hr -> newRate $0.72/MU-hr Current cost: $730/mo Savings: $730 x (1 - 0.72) = $204/mo
RC-1604 Custom Model Orphan 3 findings Category orphan, guided delete. No PT or deployment references these three fine-tuned models.
RC-1607 Agent Idle 0 findings 9 agents discovered. Invocation series absent for all 9. Rule abstained on all 9 (producer-contract gap).
RC-1630 Agent Without Guardrail 6 findings Category security, $0. Routed to the security backlog.
RC-1603 PT Below Break-Even 0 findings 1 PT matched the detection signal; abstained for lack of on-demand token rates.
────────────────────────────────────────────────────────────RECOVERABLE THIS MONTH: $2,394/moPOSTURE / CLEANUP: 9 findings at $0SILENTLY ABSTAINED: 10 (1 committed PT, 9 agents)The load-bearing line is the last one. Ten resources produced no recommendation, and in every case that was the correct outcome rather than a miss.
3. Hands-on (6 min)
Open Recommendations and filter to the RC-16xx range. For your own estate:
1. How many bedrock-pt resources do you have? _____
2. Of those, how many carry a commitmentDuration? _____ (These can never produce an RC-1601 finding.)
3. RC-1601 findings, and their total savings: _____
4. Count the $0 findings (RC-1607/1608/1633/1634 and the security rules 1615/1630). _____ Who owns those in your org? ______________________
5. Pick one RC-1601 finding. Before acting, confirm in CloudWatch that Invocations really is absent for the full 30-day window, not merely low. ____Step 5 is the discipline the rule itself cannot do for you: it proves the absent series is genuine idle rather than a fetch gap on that one resource. That residual gap is documented and unfixed.
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. AI or ML workloads in the estate: SageMaker endpoints or notebooks, Vertex AI endpoints, or Azure Cognitive Services.ASK "What are we spending on AI and ML, by model and by month?"CHECK the split between on-demand and provisioned throughput. That ratio is the whole optimisation in this module.Tools behind it: get_ai_cost_summary (read, Cost), get_ai_usage (read, Cost), list_ai_models (read, Cost). The full catalogue is at zop.dev/learn/mcp-tools.
4. Knowledge check
Q1
RC-1601 (PT Idle) fires on a provisioned throughput whose Invocations series is absent. Why is absence the idle signal rather than a data error?
A. Because CloudWatch always returns a series, so absence means the resource has been deleted entirely from the account already by then entirely
B. Because the discoverer deletes the series for idle resources
C. Because Invocations is a Sum-statistic count metric: a series exists only when invocations are greater than zero, so a fully idle PT produces no key at all
D. Because absence is never treated as a signal
Show answer
Correct: C. The rule still hard-abstains when the org’s whole metrics map is empty, which is what a fetch outage looks like. Sum-stat count metrics do not emit zeros. The guard that matters is the empty-map check: without it, an org-wide metrics fetch failure would read as “every PT is idle” and mass-fire delete recommendations.
Q2
An org has 9 Bedrock agents and RC-1607 (Agent Idle) reports 0 findings. The most likely explanation:
A. A producer-contract gap
B. All 9 agents are actively invoked
C. The rule was retired
D. Agents are not discovered
Show answer
Correct: A. The metric query asks for AgentId in the AWS/Bedrock namespace, but Bedrock Agent metrics live in AWS/Bedrock/Agents as InvocationCount dimensioned by alias ARN. No datapoint can return, so the rule abstains rather than declaring every agent idle. An earlier version did treat the absent series as idle and recommended deleting every agent regardless of traffic. Abstaining is the corrected behaviour, and it will stay a no-op until the discoverer stamps alias ARNs and the aggregator spec is fixed.
Q3
RC-1607, RC-1608, RC-1633 and RC-1634 all carry the advisory category and $0 savings. The reason:
A. The rules are not finished
B. They are low severity
C. AWS does not publish pricing for them
D. The artifacts themselves are free
Show answer
Correct: D. An agent, guardrail, inference profile or custom-model deployment costs nothing to keep; the spend lives in the foundation-model invocations underneath, which are already counted against the PT or on-demand usage. Filing a $0 finding under a cost-driven category would get it dropped by the low-savings suppressor and it would never reach the customer. This is the general rule from M2.1: a cost-driven category must carry a real dollar figure or abstain, so a genuine $0 cleanup signal is deliberately filed under a non-cost-driven category to survive the suppressor.
5. Apply
Filter Recommendations to the RC-16xx range and split the list in two: the PT rules (RC-1601/1602/1610) which carry recoverable money, and everything else, which is cleanup and posture routed to the ML and security backlogs.
Re-check the PT findings after any commitment purchase. A PT that acquires a committed term stops producing RC-1601 and RC-1610 findings by design.
Related lessons
Glossary terms touched
Provisioned throughput · Model unit · Absent-series signal · Advisory category