Cloud cost anomaly
A cloud cost anomaly is spend that departs from what the history and the plan said to expect for a service, an environment or an owner: a service that doubled overnight, a region that appeared, a commitment that expired into on-demand. It is defined against a baseline, so the same amount can be an anomaly for one service and noise for another.
An anomaly is not planned growth. A migration, a launch or a campaign raises spend on purpose, and a detector that alerts on it every day teaches its readers to ignore it. The changes budget owners record in the forecast are the same information a detector needs to stay quiet when an increase was expected.
Detection depends on a baseline at the level where spend is stable and owned: per service, per environment and per owner, aware of the weekly and monthly calendar. A single estate-wide threshold is either too loose to catch anything below the largest service or too tight to stay quiet on it. A relative threshold against the baseline is paired with an absolute floor so a large percentage on a tiny service does not page anyone.
Attribution turns a spike into a task. An alert that names the team, the resources and the daily run-rate of the change can be closed in a message; an alert that names an account and a percentage is a research project. The same mapping that produces monthly statements produces the attribution on the day.
The measure of a detector is the share of its alerts that led to an action and the anomalies it missed that month-end found, not how many anomalies it raised. The native detectors on each cloud are worth turning on, and they stop where attribution and cross-cloud baselines begin.
Go deeper
Related terms