Amazon SageMaker Endpoint
Does ZopNight manage Amazon SageMaker Endpoint?
SageMaker real-time endpoints bill per instance-hour for every instance behind them, from deployment until deletion, with no native stop verb. An idle endpoint costs exactly what a busy one does. ZopNight reads 90 days of endpoint metrics, attributes per-endpoint cost from Cost Explorer or CUR 2.0, and flags idle endpoints for rightsizing or removal.
Rules that fire on Amazon SageMaker Endpoint
At a glance
| Field | Value |
|---|---|
| Scheduling notes | deliberately excluded from scheduling: the only way to stop a real-time endpoint is to delete and recreate it, and ZopNight does not automate that on a schedule. |
A SageMaker real-time endpoint hosts a deployed model on dedicated ML instances, billed per instance-hour for as long as the endpoint exists. Endpoints are among the most expensive always-on resources in ML accounts, and idle endpoints bill exactly like busy ones.
Deployed means billing
An endpoint’s meter is the ML instance-hour, multiplied by however many instances its production variants run, from the moment deployment succeeds until the endpoint is deleted. Invocations are irrelevant to the charge. What makes this meter unusually dangerous is the missing verb: real-time endpoints cannot be stopped. There is no pause state, no scale-to-zero on the standard configuration. Silencing the meter takes deleting the endpoint and recreating it later from its configuration. GPU-backed inference instances push the hourly rates high enough that one forgotten endpoint can dominate an ML account’s bill.
Ninety days of truth per endpoint
ZopNight discovers endpoints via the SageMaker API on the 6-hour cycle, pulls hourly CloudWatch metrics from the SageMaker namespace with a 90-day lookback, and attributes per-endpoint cost from Cost Explorer or CUR 2.0. The lookback separates genuinely idle endpoints, whose invocation counts stay flat for months, from bursty ones that look quiet in any single week. Findings split into idle-endpoint recommendations (candidates for deletion) and instance rightsizing (endpoints whose utilization justifies a smaller or cheaper instance type). A delete-and-recreate executor exists internally but is deliberately not exposed as a schedulable action: automating deletion of a serving path on a timer is a decision ZopNight leaves to humans.
The experiments that never undeployed
Endpoint waste is biographical: a data scientist deploys a model to demo it, the demo succeeds or fails, and the endpoint persists because deleting feels irreversible in a way that stopping would not. Shadow deployments from A/B tests keep their losing variant serving. Notebooks-to-production tutorials end with a deployed endpoint and no cleanup cell.
Endpoint accounting in SageMaker
The SageMaker console’s Inference section lists endpoints with status, instance types, and variant counts; pairing each against its invocation metrics answers the only expensive question: who is actually calling this model?