A permitting office wants to be notified automatically the moment its monthly Bedrock inference spend crosses a set dollar threshold, well before the finance team's monthly report is due. Which approach meets this need?
Select an answer to reveal the explanation.
Short Explanation
Think of a budget alert like a thermostat, not a furnace: it doesn't fix spend, it just tells you the second the room gets too warm. Set the threshold once and the notification finds you, instead of you finding the bill at month-end. That's the whole point of alerting over reporting.
Full Explanation
Cost-management budgets let a team define a spend threshold against actual or forecasted usage and attach an alert action that fires automatically the moment that threshold is crossed, which is exactly the proactive notification the permitting office is asking for. Waiting on the monthly Cost and Usage Report only surfaces the overage after the fact, once the billing cycle has already closed — useful for reconciliation, not for catching a threshold breach in real time. An alarm on invocation count conflates request volume with dollar spend; those two track loosely at best, since token usage per call and pricing tiers vary, so an invocation-based alarm can miss real cost spikes or fire on harmless ones. Manual daily console checks depend on someone remembering to look and catching the crossing on the same day it happens, which does not scale and introduces exactly the lag the office wants to avoid. Scope note: a budget threshold protects against a category of spend crossing a line — it doesn't itself explain which specific model call or workflow drove the increase, so pair it with detailed billing tags if root-causing is also required. As an operational check, confirm the alert actually reaches a monitored channel by testing with a low threshold before relying on it at the real one.