These rules identify running SageMaker notebook instances, idle real-time endpoints that may no longer be needed, and SageMaker usage running on demand that a Savings Plan should be covering.
| Rule ID | Scan Type | Severity | Name |
|---|---|---|---|
| CLDBRN-AWS-SAGEMAKER-1 | Discovery | High | SageMaker Notebook Instance Running |
| CLDBRN-AWS-SAGEMAKER-2 | Discovery | High | SageMaker Endpoint Idle |
| CLDBRN-AWS-SAGEMAKER-3 | Discovery | Medium | SageMaker Savings Plans Coverage Low |
CLDBRN-AWS-SAGEMAKER-1
SageMaker Notebook Instance Running
Scan type: Discovery
Severity: High
What it checks
Flags SageMaker notebook instances whose status remains InService. Running notebook instances incur compute charges continuously until stopped.
Why it matters
SageMaker notebook instances are billed per second while in the InService state. A ml.t3.medium notebook instance costs roughly $50/month running 24/7. Data scientists frequently leave notebook instances running after their analysis is complete, leading to persistent compute charges for idle resources.
What triggers a finding
notebookInstanceStatus is InService.
How to remediate
Stop the notebook instance when it is not actively in use. Consider implementing lifecycle configuration scripts that automatically stop idle instances after a period of inactivity. SageMaker Studio provides a more managed alternative with automatic shutdown capabilities.
aws sagemaker stop-notebook-instance --notebook-instance-name my-notebook
CLDBRN-AWS-SAGEMAKER-2
SageMaker Endpoint Idle
Scan type: Discovery
Severity: High
What it checks
Flags SageMaker real-time inference endpoints that are InService, old enough to have a full observation window, and have received zero invocations over the past 14 days.
Why it matters
A real-time SageMaker endpoint keeps its underlying instances running around the clock regardless of traffic. An idle ml.m5.xlarge endpoint costs well over $150/month for zero inference requests. Endpoints are easy to leave behind after a model evaluation or demo project wraps up, since nothing about the endpoint signals it's unused the way a stopped instance would.
What triggers a finding
All of the following must be true:
endpointStatusisInServicetotalInvocationsLast14Daysis exactly0(anullvalue means CloudWatch didn't return complete coverage for the window, and the endpoint is skipped rather than flagged)creationTimeis 14 or more days in the past
Coverage
An InService endpoint is reported as unknown when the evidence cannot settle the result either way: its 14-day invocation total is missing and its creation time is 14 or more days in the past, or its creation time is missing or unparseable and it recorded no invocations. See Live Evaluation Coverage.
How to remediate
Confirm no application or scheduled job depends on the endpoint, then delete it:
aws sagemaker delete-endpoint --endpoint-name my-endpoint
For endpoints with genuinely intermittent traffic, consider SageMaker Serverless Inference, which scales to zero between invocations automatically. Asynchronous Inference can also reach zero instances, but only when you configure Application Auto Scaling with a minimum capacity of 0 and a scale-out policy — without that, an async endpoint keeps billing for its provisioned instances just like the real-time endpoint it replaced.
CLDBRN-AWS-SAGEMAKER-3
SageMaker Savings Plans Coverage Low
Scan type: Discovery
Severity: Medium
What it checks
Flags accounts whose SageMaker Savings Plans eligible usage is less than 80% covered over a complete 30-day window, when the uncovered On-Demand spend is large enough to be worth committing. The finding is account-scoped: its resource ID is the account ID, and it carries no region.
Why it matters
SageMaker Savings Plans discount eligible SageMaker usage in exchange for a committed hourly spend over a one or three year term. Training jobs, processing jobs, and real-time endpoints that run continuously are exactly the steady-state usage that commitment is designed for, and running them at On-Demand rates is a straightforward overpayment. Coverage tends to drift downward without anyone noticing: usage grows, an existing plan stays the same size, and the uncovered fraction quietly widens.
What triggers a finding
All of the following must be true, evaluated per account:
coveragePercentagefor the 30-day window is below 80onDemandCostfor the window is 72 cost units or more, in the currency the coverage data reports- AWS Cost Optimization Hub has no SageMaker Savings Plans purchase recommendation for the same account
The Hub check is what keeps this rule from duplicating AWS's own advice. If CLDBRN-AWS-COSTOPTIMIZATIONHUB-1 is active and AWS already recommends a SageMaker Savings Plan for the account, that recommendation carries a concrete commitment amount, term, and payment option, so this rule stays quiet and lets the Hub finding stand. The Hub dataset is an optional dependency: this rule never causes it to be loaded, so in a scan where the Cost Optimization Hub rules are not enabled, the coverage gap is reported on its own.
How to remediate
- Confirm the uncovered usage is steady rather than a one-off training burst. A commitment only pays off against usage you will keep running for the whole term.
- Review AWS Cost Explorer's Savings Plans recommendations for SageMaker to size the hourly commitment.
- Start with a one-year, no-upfront plan sized to your baseline rather than your peak. Under-committing leaves some usage on demand; over-committing bills for the commitment whether you use it or not.
aws ce get-savings-plans-purchase-recommendation \
--savings-plans-type SAGEMAKER_SP \
--term-in-years ONE_YEAR \
--payment-option NO_UPFRONT \
--lookback-period-in-days SIXTY_DAYS
See Also
- CLI discover command - scan live AWS resources
- Understanding Rules — Finding Precedence - how CloudBurn avoids duplicating AWS recommendations
- SDK Reference - run discovery programmatically