← Agent Frameworks 🕐 15 min read

Agent Frameworks

AWS Cost Anomaly Detection for Bedrock AI Spend (2026)

Overview · March 2026

AWS Cost Anomaly Detection (CAD) is the ML-based spending surveillance layer in AWS Cost Management.

AWS Cost Anomaly Detection (CAD) is the ML-based spending surveillance layer in AWS Cost Management. For teams running Bedrock workloads — inference, agents, knowledge bases, provisioned throughput — CAD is the difference between catching a runaway loop on Tuesday morning and discovering it Friday when the CFO pulls the monthly bill. This note covers setup, detection mechanics, Bedrock-specific patterns, and the complementary architecture with AWS Budgets.

CAD is free. The cost is complexity of setup and the 10-14 day baseline wait before the model is useful.

1. How Cost Anomaly Detection Works

ML Detection Engine

CAD uses a multi-layered machine learning model that builds a behavioral baseline from historical spend data. The baseline accounts for:

Day-of-week patterns — weekend drops, Monday morning spikes in batch jobs
Growth trends — steady month-over-month increases in inference volume
Seasonal variation — month-end batch processing, quarterly reporting cycles
Service-specific seasonality — each monitored dimension trains its own sub-model

The model does not use a single global threshold. Each service, account, tag, or cost category dimension is evaluated independently against its own learned baseline. This means a new Bedrock workload and a mature EC2 fleet are held to different standards of “normal.”

Detection Algorithm (as of Nov 2025)

In November 2025, AWS upgraded the detection algorithm to use rolling 24-hour windows rather than evaluating full-day totals once nightly. The system now compares current costs against equivalent time periods from previous days each time AWS receives updated Cost and Usage Report (CUR) data — which happens up to three times per day.

Detection runs: approximately 3× per day, triggered by CUR data refresh cycles.

Detection stages:

ML model evaluates whether deviation from baseline exceeds statistical threshold
System computes Total Impact: (actual spend) - (expected spend) over the anomaly window
Alert fires only if Total Impact exceeds the subscription’s configured minimum threshold
Root cause analysis runs to rank contributing dimensions

Root Cause Analysis

When an anomaly is confirmed, CAD performs attribution analysis and surfaces up to 10 ranked root causes. Each root cause identifies the combination of dimensions (linked account + region + usage type + service API operation) with the highest cost impact.

Important limitation: root cause shows the single largest contributing factor, not the full explanation of the anomaly. If a Bedrock agent loop is spread across multiple usage types (InvokeModel + InvokeAgent + Retrieve), each may appear as separate root causes with partial impact figures that do not sum to the total anomaly.

Root cause quality depends on tag and cost allocation hygiene. If your Bedrock workloads are tagged with team, environment, and agent-id tags, CAD can surface “team: payments, agent: invoice-processor” as the root cause. Untagged workloads collapse to account + region, which is less actionable.

Detection Lag

CUR delay: Cost and Usage Report data has an inherent 8-24 hour delay from when usage occurs to when it is visible in Cost Explorer. CAD operates on Cost Explorer data.

Practical alert lag from incident start:

Best case (anomaly starts at CUR refresh, large magnitude): 8-12 hours
Typical case: 12-24 hours
Worst case (anomaly starts shortly after a CUR refresh, borderline magnitude): 24-36 hours

Friday-evening failure mode: A runaway agent loop that starts at 6pm Friday will likely not trigger an alert until Saturday morning at the earliest. Average cloud cost anomaly burns $3,000-$15,000 before detection. CAD is not a real-time guardrail — it is a billing-layer safety net. Pair it with application-level rate limiting and Lambda concurrency limits for Bedrock workloads that need faster containment.

2. Setting Up Monitors for Bedrock

CAD supports four monitor types. For Bedrock workloads, the relevant patterns are:

2a. AWS Service Monitor (Recommended Starting Point)

Monitor a single AWS service. Set MonitorDimension to SERVICE and the monitor evaluates each service independently. Amazon Bedrock appears as its own dimension.

What it catches: Any anomaly in total Bedrock spend across your account. Highest signal-to-noise ratio for getting started. Does not distinguish between teams or environments — a load test in dev triggers the same alert as a production incident.

Console path: Cost Management → Cost Anomaly Detection → Create monitor → AWS services → Amazon Bedrock

2b. Linked Account Monitor

One monitor evaluates each linked account independently. Useful in AWS Organizations where each team or BU has its own account.

What it catches: A specific team’s account running anomalous Bedrock spend. Root cause analysis is cleaner because it’s already scoped to an account.

Limitation: Requires a multi-account organization structure. Single-account AWS setups cannot use this pattern meaningfully.

2c. Cost Category Monitor

Monitor a cost category dimension (e.g., a “GenAI” cost category that rolls up Bedrock + SageMaker + Marketplace AI model charges). As of November 2025, AWS expanded managed monitors to support cost categories natively — a single monitor covers all cost categories without manual per-category configuration.

What it catches: Combined AI spend anomalies that span services. Useful when you want to detect “the GenAI budget has a problem” without caring whether it’s Bedrock specifically or a SageMaker endpoint.

Prerequisite: Cost Categories must be defined in Cost Explorer before creating this monitor.

2d. Cost Allocation Tag Monitor

Monitor by tag key — for example team or project. A single managed monitor now covers all values of a tag key automatically. Previously, 500 teams required 500 monitors; as of Nov 2025, one monitor covers all of them.

What it catches: A specific team’s Bedrock spend anomaly, identified by their cost allocation tag. Most actionable for multi-team platforms — root cause names the team directly.

Prerequisite: Tags must be activated as cost allocation tags in the Billing console. Bedrock resources (inference profiles, knowledge bases) must be tagged consistently.

3. Subscription Configuration

A monitor detects anomalies. A subscription defines who gets notified and under what conditions. Multiple subscriptions can attach to a single monitor.

Threshold Type: ABSOLUTE vs PERCENTAGE

ABSOLUTE (ANOMALY_TOTAL_IMPACT_ABSOLUTE): Alert when the anomaly’s total dollar impact exceeds a fixed threshold.

Example: alert if the anomaly costs more than $100
Recommended for production Bedrock workloads where dollar risk is the primary concern
Immune to alert fatigue from low-cost services that regularly fluctuate by large percentages

PERCENTAGE (ANOMALY_TOTAL_IMPACT_PERCENTAGE): Alert when the anomaly represents more than X% above expected.

Example: alert if spend is more than 50% above baseline
Useful for early-stage workloads where absolute spend is low but percentage deviation is informative
Caution: new services with minimal baseline spend trigger percentage alerts on trivial absolute amounts. A service with $2/day baseline flags at 50% when it spends $3.

Recommended for Bedrock: Use ABSOLUTE with a minimum impact of $50-$200 depending on your workload size. Percentage thresholds work as a secondary subscription for development accounts where you want to catch early signals before absolute dollar impact is large.

Minimum Impact Amount

This is the floor below which CAD suppresses alerts even if an anomaly is statistically detected. Set too low: alert fatigue from noise. Set too high: miss genuine early-stage escalations.

Suggested starting values:

Development / sandbox accounts: $25
Shared platform accounts: $100
Production with high daily Bedrock spend (>$500/day): $250-$500

Alert Frequency

Three options per subscription:

Individual alerts: fire as soon as an anomaly exceeds the threshold. Highest signal latency, no aggregation.
Daily digest: all anomalies from the past 24 hours in one message. Reduces noise but adds up to 24 hours of additional delay.
Weekly digest: useful for low-priority monitors only. Not appropriate for production Bedrock spend.

Recommendation: Individual alerts for production monitors, daily digest for development/staging.

SNS → Slack / PagerDuty Routing

CAD delivers alerts to SNS topics. From SNS, use either:

Path 1 — AWS Chatbot (managed, no Lambda):

Create SNS topic
Create an AWS Chatbot configuration pointing SNS → Slack channel
Reference the SNS topic ARN in the subscription

Cost: no Lambda, no custom code. Chatbot formats the CAD alert as a Slack message automatically.

Path 2 — SNS → Lambda → Webhook:

# Lambda handler for SNS → custom Slack/PagerDuty formatting
import json, urllib3

def handler(event, context):
    http = urllib3.PoolManager()
    for record in event['Records']:
        message = json.loads(record['Sns']['Message'])
        anomaly = message.get('anomalyDetails', {})
        
        total_impact = anomaly.get('impact', {}).get('totalImpact', 0)
        service = anomaly.get('rootCauses', [{}])[0].get('service', 'unknown')
        account = anomaly.get('rootCauses', [{}])[0].get('linkedAccount', 'unknown')
        
        payload = {
            "text": f":rotating_light: CAD Alert: ${total_impact:.2f} anomaly in {service} (account: {account})"
        }
        http.request('POST', SLACK_WEBHOOK_URL,
                     body=json.dumps(payload).encode('utf-8'),
                     headers={'Content-Type': 'application/json'})

Path 3 — EventBridge (for PagerDuty / complex routing): EventBridge can consume SNS events and route based on dollar magnitude or service, triggering different runbooks for different severity tiers.

4. CAD API: Programmatic Monitor Management

All CAD operations are available through the boto3 ce (Cost Explorer) client.

Create a Bedrock Service Monitor

import boto3

ce = boto3.client('ce', region_name='us-east-1')

# Service-level monitor: tracks each AWS service independently
# Amazon Bedrock will be one of the auto-discovered service dimensions
response = ce.create_anomaly_monitor(
    AnomalyMonitor={
        'MonitorName': 'bedrock-service-monitor',
        'MonitorType': 'DIMENSIONAL',
        'MonitorDimension': 'SERVICE'
    },
    ResourceTags=[
        {'Key': 'Purpose', 'Value': 'bedrock-finops'},
        {'Key': 'ManagedBy', 'Value': 'platform-team'}
    ]
)
monitor_arn = response['MonitorArn']
print(f"Monitor ARN: {monitor_arn}")

Create a Cost Category Monitor (GenAI Rollup)

# Custom expression monitor for a cost category
response = ce.create_anomaly_monitor(
    AnomalyMonitor={
        'MonitorName': 'genai-cost-category-monitor',
        'MonitorType': 'CUSTOM',
        'MonitorSpecification': json.dumps({
            'CostCategories': {
                'Key': 'WorkloadType',
                'Values': ['GenAI'],
                'MatchOptions': ['EQUALS']
            }
        })
    }
)

Create a Tag-Based Monitor (Per-Team)

# Tag monitor: one monitor covers all values of the 'team' tag
# Requires 'team' to be an activated cost allocation tag
response = ce.create_anomaly_monitor(
    AnomalyMonitor={
        'MonitorName': 'team-tag-monitor',
        'MonitorType': 'DIMENSIONAL',
        'MonitorDimension': 'COST_CATEGORY'  # or TAG when tag-based managed monitors are used
    }
)

sns_arn = 'arn:aws:sns:us-east-1:123456789012:bedrock-cost-alerts'

response = ce.create_anomaly_subscription(
    AnomalySubscription={
        'SubscriptionName': 'bedrock-production-alerts',
        'MonitorArnList': [monitor_arn],
        'Subscribers': [
            {
                'Address': sns_arn,
                'Type': 'SNS',
                'Status': 'CONFIRMED'  # SNS topic must confirm subscription
            },
            {
                'Address': 'oncall-finops@example.com',
                'Type': 'EMAIL'
            }
        ],
        'Threshold': 100.0,           # alert if anomaly > $100
        'ThresholdExpression': {
            'Dimensions': {
                'Key': 'ANOMALY_TOTAL_IMPACT_ABSOLUTE',
                'Values': ['100'],
                'MatchOptions': ['GREATER_THAN_OR_EQUAL']
            }
        },
        'Frequency': 'IMMEDIATE'     # IMMEDIATE | DAILY | WEEKLY
    }
)
subscription_arn = response['SubscriptionArn']

List and Query Detected Anomalies

from datetime import datetime, timedelta

# Retrieve anomalies from the past 30 days
response = ce.get_anomalies(
    MonitorArn=monitor_arn,
    DateInterval={
        'StartDate': (datetime.now() - timedelta(days=30)).strftime('%Y-%m-%d'),
        'EndDate': datetime.now().strftime('%Y-%m-%d')
    },
    Feedback='ALL',          # ALL | PLANNED_ACTIVITY | YES | NO | NOTSET
    TotalImpact={
        'NumericOperator': 'GREATER_THAN',
        'StartValue': 50.0
    },
    MaxResults=100
)

for anomaly in response.get('Anomalies', []):
    print(f"""
    Anomaly ID:    {anomaly['AnomalyId']}
    Start:         {anomaly['AnomalyStartDate']}
    End:           {anomaly.get('AnomalyEndDate', 'ongoing')}
    Total Impact:  ${anomaly['Impact']['TotalImpact']:.2f}
    Feedback:      {anomaly.get('Feedback', 'not set')}
    Top Root Cause: {anomaly['RootCauses'][0] if anomaly.get('RootCauses') else 'N/A'}
    """)

Provide Feedback to Improve Detection

# Mark an anomaly as expected (planned load test, migration event, etc.)
ce.provide_anomaly_feedback(
    AnomalyId='anomaly-id-string',
    Feedback='PLANNED_ACTIVITY'   # PLANNED_ACTIVITY | YES (true anomaly) | NO (false positive)
)

# Mark as a true anomaly worth future detection
ce.provide_anomaly_feedback(
    AnomalyId='another-anomaly-id',
    Feedback='YES'
)

5. Baseline Data Requirement

CAD requires a minimum of 10 days of historical spend data for a dimension before anomaly detection is meaningful. The ML model takes up to 90 days to fully mature.

Practical implications:

Timeline	State	What to expect
Days 0-9	No detection	CAD will not fire alerts. No baseline exists.
Days 10-30	Early detection	Alerts possible but higher false positive rate. Large deviations catch.
Days 30-90	Improving model	Day-of-week patterns become reliable. Gradual escalations detectable.
Days 90+	Mature model	Seasonal patterns captured. False positive rate at steady state.

Implication for new Bedrock workloads: When you deploy a new Bedrock agent or inference endpoint for the first time, you are flying blind for the first 10 days. Compensate with:

Lambda concurrency limits or token-rate limits at the application layer
A manual Budgets alert (absolute dollar ceiling) as a bridge until CAD baseline matures
CloudWatch metric alarms on bedrock:InvokeModel invocation counts as a real-time signal

Multi-account rollout: Each linked account gets its own sub-model per service. Migrating a workload from one account to another resets the baseline for both accounts’ Bedrock dimension. Plan migrations with a 10-day overlap or temporary budget alert coverage.

6. Bedrock-Specific Anomaly Patterns

Pattern 1: Runaway Agent Loop

What happens: A Bedrock Agents orchestration loop gets stuck — the agent continuously invokes its LLM to decide next steps, never reaching a final answer or hitting a configured stop condition. Each iteration costs model tokens. At Claude 3 Sonnet rates (~$0.003/1K input tokens), a loop invoking a 10K token context 600 times/hour runs ~$18/hour — invisible until CAD fires.

CAD signature: Sustained, gradually increasing Bedrock spend starting from a specific time and continuing linearly. Root cause points to InvokeAgent usage type, specific account, specific region.

Detection lag concern: Loop must run 8-24 hours before CUR data surfaces it to CAD. Mitigation: set maxIterations in your agent’s action group configuration (max is 100 by default). Set explicit Lambda timeout on action group Lambda functions. CloudWatch alarm on bedrock:InvokeAgent invocation rate is a faster signal.

CAD alert threshold recommendation: $50 absolute for development, $200 for production. A runaway agent loop will blow through these within 3-12 hours.

Pattern 2: Prompt Injection Cost Escalation

What happens: A public-facing Bedrock application (customer support bot, document Q&A) receives crafted inputs that inflate token usage — adversarially long prompts, requests to “repeat everything you know,” or jailbreak patterns that trigger verbose reasoning. At scale, this drives spend above baseline.

CAD signature: Correlated spike in both InvokeModel input token count and total Bedrock spend. Spike may appear during specific hours (attack window) or gradually increase as the application is discovered.

Root cause quality: CAD will identify the Bedrock service + account but will not distinguish adversarial traffic from organic growth. You need application-layer logging (CloudTrail + Bedrock invocation logs to S3) to attribute the spike to specific request patterns.

Mitigation before CAD fires: Implement input token limits in the application layer. Use Bedrock Guardrails to reject oversized inputs or known injection patterns.

Pattern 3: Forgotten Provisioned Throughput Endpoint

What happens: Provisioned Throughput (PT) in Bedrock works like a reserved instance — you purchase model units (MUs) that bill hourly whether you invoke the model or not. A PT endpoint created for a load test, demo, or short-term project and not deleted continues accruing cost indefinitely.

CAD signature: Steady, flat anomaly. Bedrock spend is $X/hour above baseline continuously, without the typical usage-correlated spikes. This is actually a subtle pattern for CAD because it’s not a spike — it’s a sustained elevation that starts at a specific moment.

Baseline problem: If the PT endpoint was provisioned before CAD’s baseline window, CAD will normalize the cost as “expected.” The only detection opportunity is at provisioning time (a sudden step-up in spend).

Mitigation: Tag every PT endpoint with ExpiryDate. Set a weekly Lambda that lists all PT endpoints and pages oncall if any are older than 14 days without recent invocations. Cost Explorer resource reports can identify idle PT endpoints.

Hourly PT cost reference (Claude models, approximate 2026 pricing):

Claude 3 Haiku, 1 MU: ~$0.80-1.20/hour
Claude 3 Sonnet, 1 MU: ~$3.50-5.00/hour
Claude 3 Opus, 1 MU: ~$12.00-18.00/hour

A forgotten Opus PT endpoint runs $105,000-$157,000/year.

Pattern 4: Knowledge Base Retrieval Spike

What happens: Bedrock Knowledge Bases charge per retrieval query. A misconfigured Retrieve-and-Generate loop, a polling application checking the KB repeatedly, or a high-traffic period can spike retrieval costs.

CAD signature: Retrieve or RetrieveAndGenerate usage type spike in root cause analysis. Often correlated with the model invocations but shows up as a separate CAD anomaly if the retrieval cost itself is disproportionate.

Pattern 5: Batch Inference Job Forgotten Running

What happens: Bedrock Batch Inference jobs process large document sets asynchronously. A job submitted with a misconfigured input manifest (e.g., pointing to a very large S3 prefix) continues processing and billing far beyond expectation.

CAD signature: Sustained Bedrock spend elevation starting from a specific timestamp, dropping to zero when the job completes or is cancelled. Check InvokeModelWithResponseStream or batch-specific usage types in root cause.

7. CAD + Budgets: Complementary Architecture

CAD and AWS Budgets are not alternatives — they cover fundamentally different detection modes. A production Bedrock FinOps architecture needs both.

Decision Matrix

Property	AWS Budgets	Cost Anomaly Detection
Detection type	Threshold-based (you define the ceiling)	Pattern-based (ML defines normal)
Trigger condition	“Spend reached X% of budget”	“Spend deviated from historical baseline”
Latency	Near real-time (hourly for Cost Explorer Budgets)	8-24 hours (CUR delay)
New workloads	Works immediately with any threshold	Requires 10-day baseline
Known cost events	Catches slow drift toward ceiling	May alert on planned growth
Unknown cost events	Only catches if they hit the defined ceiling	Catches any pattern deviation
Configuration burden	You must set amounts manually	Self-calibrating, no threshold to maintain

Recommended Architecture: Two-Layer Defense

Layer 1 — AWS Budgets (Immediate Ceiling Protection)
  ├── Budget per account, monthly period
  ├── Alert at 80% and 100% of budget
  ├── Bedrock-specific budget using cost filter: Service = Amazon Bedrock
  └── Threshold: set to maximum acceptable monthly Bedrock spend

Layer 2 — Cost Anomaly Detection (Pattern Deviation)
  ├── AWS Service monitor (SERVICE dimension, covers Bedrock)
  ├── Tag monitor (per-team if cost allocation tags in use)
  └── Individual alert subscription, $100 absolute minimum impact

Why both are necessary:

CAD alone misses the “slow leak” — a workload growing 10% week-over-week will not trigger CAD because it’s following the established growth trend. A Budget catches it when total spend approaches the agreed ceiling.
Budgets alone miss the “sudden spike” — a $500 Budget with $100 spent so far will not alert on a $200 overnight anomaly because you are still within budget. CAD catches the pattern deviation.
Budgets have no 10-day warmup period. They protect new workloads from day one.

Budget Setup for Bedrock (Complementary)

budgets = boto3.client('budgets', region_name='us-east-1')

budgets.create_budget(
    AccountId='123456789012',
    Budget={
        'BudgetName': 'bedrock-monthly-ceiling',
        'BudgetLimit': {'Amount': '5000', 'Unit': 'USD'},
        'CostFilters': {
            'Service': ['Amazon Bedrock']
        },
        'TimeUnit': 'MONTHLY',
        'BudgetType': 'COST'
    },
    NotificationsWithSubscribers=[
        {
            'Notification': {
                'NotificationType': 'ACTUAL',
                'ComparisonOperator': 'GREATER_THAN',
                'Threshold': 80.0,
                'ThresholdType': 'PERCENTAGE'
            },
            'Subscribers': [{'SubscriptionType': 'SNS', 'Address': sns_arn}]
        },
        {
            'Notification': {
                'NotificationType': 'ACTUAL',
                'ComparisonOperator': 'GREATER_THAN',
                'Threshold': 100.0,
                'ThresholdType': 'PERCENTAGE'
            },
            'Subscribers': [{'SubscriptionType': 'SNS', 'Address': sns_arn}]
        }
    ]
)

8. Multi-Service Monitoring: Marketplace + SageMaker + Bedrock

AI spend in a mature AWS environment spans multiple services. A single “GenAI” CAD monitor built on a Cost Category rollup covers the full picture.

Services to Include in a GenAI Cost Category

Service	Typical spend driver
Amazon Bedrock	Inference (on-demand + PT), agents, knowledge bases
Amazon SageMaker	Custom model hosting, fine-tuning jobs, Studio instances
AWS Marketplace (AI models)	Third-party model subscriptions billed through Marketplace
Amazon OpenSearch Serverless	Vector search for Bedrock Knowledge Bases
Amazon S3	Embedding storage, batch inference input/output
AWS Lambda	Bedrock action group executors

Cost Category definition (console or API):

{
  "Rules": [
    {
      "Value": "GenAI",
      "Rule": {
        "Or": [
          {"Dimensions": {"Key": "SERVICE", "Values": ["Amazon Bedrock"]}},
          {"Dimensions": {"Key": "SERVICE", "Values": ["Amazon SageMaker"]}},
          {"Tags": {"Key": "WorkloadType", "Values": ["GenAI", "LLM", "ML"]}}
        ]
      }
    }
  ]
}

SageMaker-Specific Anomaly Patterns

SageMaker introduces its own set of runaway patterns that the GenAI monitor catches:

Forgotten training jobs: SageMaker training instances bill per second. A job that should run 2 hours but stalls on data loading bills indefinitely.
Spot interruption retry loops: A training job configured with automatic spot retry may loop through failed spot attempts, each incurring startup costs.
Studio kernel sessions: Jupyter kernel sessions in SageMaker Studio bill per session-hour. Developers who close the browser without stopping the kernel accumulate idle charges.
Real-time endpoint idle: Like Bedrock PT, a SageMaker real-time inference endpoint bills per hour regardless of invocation count.

Marketplace AI Model Subscription Monitoring

AWS Marketplace AI model subscriptions (e.g., third-party LLMs, image generation APIs) bill through Marketplace and appear under a different service dimension. Include the Marketplace service in cost category rules if your organization uses external model subscriptions. CAD will detect anomalies in Marketplace spend independently from Bedrock spend.

9. Feedback Loop: Improving Detection Quality

CAD’s ML model learns from explicit feedback. Without feedback, the model cannot distinguish “true anomaly (investigate)” from “expected business event (ignore).” High false positive rates lead to alert fatigue; engineers start ignoring CAD notifications.

Feedback Values

Feedback type	When to use	Effect on model
`YES`	Genuine unexpected anomaly, needed investigation	Reinforces detection; similar future patterns fire alerts
`NO`	False positive — statistical fluke, not a real problem	Model loosens threshold for this pattern; reduces false positives
`PLANNED_ACTIVITY`	Expected event: load test, migration, launch day, month-end batch	Model learns to expect this recurrence; suppresses future alerts for similar patterns

Feedback Workflow

def triage_anomaly(anomaly_id: str, assessment: str, notes: str = None):
    """
    assessment: 'YES' | 'NO' | 'PLANNED_ACTIVITY'
    Call from your Slack bot's interactive button handler or runbook automation.
    """
    ce = boto3.client('ce', region_name='us-east-1')
    
    ce.provide_anomaly_feedback(
        AnomalyId=anomaly_id,
        Feedback=assessment
    )
    
    # Log to your incident tracker
    log_anomaly_triage(anomaly_id=anomaly_id, assessment=assessment, notes=notes)

# Example: Slack button handler for CAD alert interactive message
# Button press → Lambda → provide_anomaly_feedback → close Slack thread

Operational Feedback Cadence

During first 30 days: Triage every alert. The model is in its highest learning phase. PLANNED_ACTIVITY feedback on any known events (month-end batch, weekly ETL, load tests) has the largest impact here.
After 90 days: Triage only alerts that required investigation. The model should have suppressed recurring business events.
Team responsibility: Assign CAD triage responsibility explicitly. Untriaged alerts stop contributing to model improvement. If no one marks anomalies, the model stays at initial quality.

Known Model Maturation Limitation

Even with consistent feedback, CAD does not learn across monitors. Feedback on a service-level Bedrock monitor does not transfer to a tag-based monitor covering the same workload. If you run both monitor types, triage must be performed on each monitor’s anomalies separately.

10. Setup Checklist for Bedrock FinOps Teams

Prerequisites
  [ ] Enable Cost Explorer (required for CAD; 24-hour activation delay)
  [ ] Activate cost allocation tags for 'team', 'environment', 'project' in Billing console
  [ ] Apply tags to: Bedrock inference profiles, knowledge bases, agents, PT endpoints
  [ ] Create SNS topic for cost alerts; confirm subscription to Slack/PagerDuty

Day 1: Bridge Coverage (before CAD baseline is ready)
  [ ] Create AWS Budget: Bedrock service filter, $X monthly ceiling, 80%/100% alerts → SNS
  [ ] Create CloudWatch alarm: bedrock:InvokeModel invocation count > N/5min → SNS

Day 1-10: CAD Monitor Creation
  [ ] Create AWS Service monitor (MonitorDimension: SERVICE)
  [ ] Create tag monitor (per-team coverage, if cost allocation tags active)
  [ ] Create CAD subscription: $100 absolute threshold, IMMEDIATE frequency → SNS
  [ ] Note monitor creation date; mark calendar for day 10 (first meaningful alerts)

Day 10+: Alert Response Setup
  [ ] Test alert routing: manually invoke anomaly via large test spend or review console
  [ ] Set up Slack interactive message buttons for YES/NO/PLANNED_ACTIVITY feedback
  [ ] Write runbook: CAD alert received → identify anomalous workload → containment steps
  [ ] Document common Bedrock anomaly signatures (patterns in section 6)

Ongoing
  [ ] Triage all CAD alerts within 24 hours (submit feedback)
  [ ] Monthly: review false positive rate; adjust minimum impact threshold if >5 alerts/week
  [ ] Quarterly: review PT endpoint inventory; delete any idle for >14 days
  [ ] After any planned scaling event: pre-mark as PLANNED_ACTIVITY in CAD console

Key Numbers Reference

Parameter	Value	Source
CAD detection runs per day	3× (as of Nov 2025)	AWS What’s New Nov 2025
CUR data delay	8-24 hours	AWS documentation
Minimum baseline before meaningful alerts	10 days	AWS CAD FAQ
Time for full model maturity	~90 days	AWS CAD FAQ
Maximum root causes surfaced per anomaly	10	AWS documentation
CAD service cost	Free	AWS pricing
Bedrock PT minimum billing period	1 hour (then hourly)	AWS Bedrock pricing
Claude 3 Opus PT hourly cost (1 MU, est. 2026)	~$12-18/hour	AWS Bedrock pricing
Average cost burned before cloud anomaly detection	$3,000-$15,000	Industry estimates