Exam-style
A Bedrock summarisation feature has a seasonal, steadily growing spend curve: quiet in January, triple that by June, up again year on year. A monthly cost budget set high enough to avoid false alarms never fires, and one set low enough to be useful fires every month. The team wants to be told, within about a day, when the daily spend on this feature departs from its own moving baseline, without anyone hand-tuning a number every quarter. Which arrangement fits?
Reveal the answer
B. An AWS Cost Anomaly Detection monitor scoped to Bedrock, or to the feature's cost allocation tag, with a dollar-impact threshold on the alert subscription
Cost anomaly detection is built for exactly this shape of workload: the monitor learns the feature’s own spend pattern, including the seasonality and the growth, and alerts when the daily curve departs from that learned baseline. Scope it to the Bedrock service or to the cost allocation tag that isolates the feature, then set a dollar-impact threshold on the alert subscription so small wobbles stay quiet. Nobody re-tunes a number, because the baseline moves with the workload. A fixed monthly budget catches a month-scale overrun and cannot see a change in shape against a moving baseline, and the threshold is the thing this team is trying not to guess. A static CloudWatch alarm on Invocations fires in minutes, which is a useful and complementary signal. A static threshold on a growing workload eventually alarms on the growth. A scheduled AWS Cost Explorer report is visibility with no detection attached; somebody still has to notice. The Athena query over the Cost and Usage Report would work, and it reimplements the managed detector and then has to be maintained. The three horizons: CloudWatch token and invocation alarms in minutes, cost anomaly detection in about a day, budgets and forecasts across the month.
Q. The feature’s spend is seasonal and growing, so a fixed budget threshold either never fires or fires every month. What catches a departure from its own normal?
A. An AWS Cost Anomaly Detection monitor scoped to Bedrock, or to the feature’s cost allocation tag, with a dollar-impact threshold on the alert subscription. The monitor learns the seasonality and the growth and alerts on the daily departure from that baseline, so there is no threshold to re-tune each quarter. The tagging work is what makes the per-feature scope possible in the first place.
Why? Three horizons, three tools. A CloudWatch alarm on Invocations or OutputTokenCount fires in minutes and is the right home for anomaly detection for token burst patterns, catching the retry loop while it is still running. Cost anomaly detection works on billing data. It lands about a day later, and answers a different question: has the daily spend on this feature left its own learned curve. AWS Budgets and forecasts work across the month and catch the slow creep. AWS Budgets is the tempting answer here, because the guardrail layering already puts one in front of this workload. A budget compares spend to a number a human chose. That number is what keeps breaking on a curve that triples between January and June. AWS Cost Explorer and a scheduled report give the same billing view without anything watching it, and a nightly Athena query over the Cost and Usage Report rebuilds the managed detector by hand. Run the CloudWatch alarm and the anomaly monitor together; they cover different failure speeds.