← Agent Frameworks 🕐 15 min read
Agent Frameworks

AWS Cost Intelligence Dashboard for Bedrock — CID/CUDOS Deployment and Custom Panels (2026)

Summary · March 2026

The AWS Cloud Intelligence Dashboards (CID) framework is the primary AWS-native FinOps visualization layer for Bedrock spending at scale.

The AWS Cloud Intelligence Dashboards (CID) framework is the primary AWS-native FinOps visualization layer for Bedrock spending at scale. It operates on top of Cost and Usage Report 2.0 (CUR 2.0) data, runs Athena queries against Glue-catalogued Parquet files, and serves dashboards through QuickSight SPICE. CUDOS v5 (currently at v5.8.1) ships with dedicated Bedrock panels but stops short of team-level token attribution, cache efficiency, and model efficiency ratios — all of which require custom Athena views and QuickSight analyses built on top of the CUDOS dataset foundation.

1. CID Framework Architecture

Data Pipeline

Management Account (Payer)
  └── AWS Data Exports → CUR 2.0 Parquet → S3 bucket (payer account)
        └── S3 Replication → Data Collection Account S3 bucket
              └── AWS Glue Crawler → Glue Data Catalog (Parquet schema)
                    └── Amazon Athena (query engine, serverless)
                          └── QuickSight SPICE datasets
                                └── QuickSight Dashboards (CUDOS, CID, KPI)

The framework operates as a hub-and-spoke: the management/payer account owns the CUR 2.0 export and S3 origin bucket. The data collection account (also called the cost analysis account) owns Glue, Athena, SPICE datasets, and QuickSight. CloudFormation StackSets push data collection modules from the management account into member accounts where needed.

Since November 2024, CID requires CUR 2.0 (legacy CUR is deprecated for new deployments). CUR 2.0 exports are Parquet-formatted, partitioned by year and month, and land under a configurable prefix such as s3://your-cur-bucket/cur2/your-export-name/.

Glue Crawler Configuration

The Glue crawler runs on a schedule (typically daily, offset by 2–4 hours after midnight UTC to allow CUR delivery to complete). It updates the Glue table schema when AWS adds new CUR columns — a common occurrence when AWS launches new services or cost allocation features. In practice, the crawler should be set to run at 03:00 UTC daily.

Glue table name convention used by CID: cur2_<export_name> in the athenacurcfn database (the database name is configurable but defaults to this).

cid-cmd CLI Deployment

cid-cmd is the primary deployment tool, installable via pip:

pip install cid-cmd

Full deployment sequence (run from CloudShell in the data collection account):

# 1. Bootstrap: deploy prerequisite CloudFormation stacks (S3, Glue, Athena workgroup)
cid-cmd bootstrap

# 2. Deploy CUDOS dashboard
cid-cmd deploy --dashboard-id cudos

# 3. Deploy CID (Cloud Intelligence Dashboard — summary view)
cid-cmd deploy --dashboard-id cid

# 4. Deploy Compute Optimizer dashboard (optional, adds rightsizing panels)
cid-cmd deploy --dashboard-id compute-optimizer-dashboard

# 5. Update existing deployments to latest version
cid-cmd update --dashboard-id cudos

# 6. Validate deployment health
cid-cmd status

Prerequisites before running cid-cmd:

  • CUR 2.0 export configured in the management account (Data Exports console, not Legacy CUR console)
  • S3 bucket replication from payer account to data collection account configured
  • QuickSight Enterprise Edition enabled in the data collection account
  • Athena workgroup and output S3 bucket created
  • IAM role with permissions for QuickSight, Athena, Glue, S3, CloudFormation

The bootstrap command provisions an Athena workgroup named CID, an S3 results bucket, and the Glue database. It does not create the CUR export itself — that must be configured manually in the Billing and Cost Management console.

2. CUDOS v5.8.1 Bedrock-Specific Panels

CUDOS v5 reorganized its dataset architecture significantly from v4. All three core datasets (summary_view, resource_view, hourly_view) now use SPICE exclusively (no direct query mode), and a new AI/ML sheet was added consolidating Bedrock, SageMaker, and Comprehend panels.

Bedrock Panels in CUDOS v5.8.1

Panel Name Data Source What It Shows Limitations
Amazon Bedrock Spend Overview summary_view Month-to-date Bedrock spend vs. prior month; daily cost trend bar chart No model-level breakout; aggregates all usage types
Bedrock Spend by Usage Type Group summary_view Stacked bar: InputTokens, OutputTokens, CacheRead, CacheWrite by day Usage type groups are AWS-defined; no custom groupings
Cost per 1000 Tokens by Usage Type Group summary_view Effective cost rate for each token type; detects pricing anomalies Calculated from cost/estimated token counts via usage type; not directly from invocation logs
Bedrock Spend per Account summary_view Multi-account breakdown of Bedrock spend by AWS account ID Account IDs only; no account name lookup unless tags are applied
Bedrock Spend per Pricing Model summary_view On-Demand vs. Provisioned Throughput vs. Batch Inference cost comparison New pricing dimensions (e.g., Bedrock AgentCore) may lag CUDOS release cycle by 1–2 months
Amazon Bedrock Spend per Region summary_view Heatmap or bar chart of spend by AWS region Does not surface cross-region inference routing costs separately
Top Bedrock Models by Cost resource_view Per-model-ID cost ranking for last 30 days Limited to 30 days; resource_view does not retain history beyond that window

Known CUDOS v5.8.1 Bedrock Limitations

  1. No IAM principal attribution. The panels do not use line_item_iam_principal — this column was added to CUR 2.0 in April 2026 and CUDOS has not yet ingested it into its standard views as of v5.8.1.
  2. No cache efficiency ratio. CacheRead and CacheWrite costs appear as separate line items but no panel computes the ratio cache_read_tokens / (cache_read_tokens + input_tokens) as a trend.
  3. No team or application attribution. The standard CUDOS views have no dimension for team, application, or cost_center unless custom cost allocation tags are added and mapped into the views.
  4. 30-day resource_view horizon. Any analysis requiring model-level attribution beyond 30 days must query summary_view or build a custom Athena view.
  5. Invocation log data not included. CUDOS is purely CUR-based. Per-request latency, prompt size, error rates, and token counts from invocation logs require a separate pipeline (CloudWatch Logs → Athena via Log Insights or a Firehose → S3 path).

3. Building Custom Bedrock QuickSight Analyses on Top of CUDOS

The correct pattern is to create a new QuickSight Analysis (not modify the CUDOS dashboard, which is managed by cid-cmd update) and point it at extended Athena views built on the same cur2_* Glue table.

Architecture for Custom Bedrock Analysis

Glue Table: athenacurcfn.cur2_<export>
  └── Custom Athena View: bedrock_cost_enriched
        └── QuickSight Dataset: "Bedrock Cost — Enriched"
              └── Custom QuickSight Analysis: "Bedrock FinOps"
                    ├── Team-Level Attribution Sheet
                    ├── Model Cost Trends Sheet
                    └── Cache Efficiency Sheet

The custom analysis inherits the CUDOS SPICE refresh schedule, so it stays current without additional refresh configuration — provided both use the same underlying Athena view or dataset.

Team-Level Attribution

Team attribution relies on IAM principal tags activated as cost allocation tags in the Billing console. The tag key (e.g., team) appears in CUR 2.0 as the column resource_tags_user_team (CUR 2.0 normalizes tag column names by lowercasing and replacing hyphens with underscores).

For IAM principal-based tags (activated after April 2026), the column is prefixed iam_principal_tag_team.

Model Cost Trend Panel Configuration

In QuickSight, create a line chart with:

  • X-axis: line_item_usage_start_date (truncated to day)
  • Y-axis: SUM(line_item_unblended_cost)
  • Color/Group by: product_model_id (a CUR 2.0 column for Bedrock that contains values like anthropic.claude-3-5-sonnet-20241022-v2:0)

Filter to line_item_product_code = 'AmazonBedrock' at the dataset level to minimize SPICE volume.

4. Athena Views for Bedrock

Standard CID Bedrock Athena View Schema

CID does not currently ship a dedicated standalone Bedrock Athena view. The CUDOS summary_view Athena view covers all services including Bedrock. The relevant CUR 2.0 columns for Bedrock within the standard view are:

Column Type Notes
line_item_product_code string 'AmazonBedrock' for all Bedrock charges
line_item_usage_type string Format: <region>-<ModelId>:<TokenType> e.g. USE1-anthropic.claude-3-5-sonnet:InputTokens
line_item_operation string Invoke for on-demand; ProvisionedThroughput for PTUs
line_item_unblended_cost double Actual cost in USD
line_item_usage_amount double Token count (in 1000s for text models)
product_model_id string Full model ID string
product_region_code string AWS region
line_item_iam_principal string Full IAM ARN (available April 2026+)
resource_tags_user_<tagkey> string Cost allocation tags, one column per activated tag
iam_principal_tag_<tagkey> string IAM principal tags (April 2026+)

Base Custom Bedrock View

-- bedrock_cost_base view
-- Create in Athena workgroup: CID
-- Replace 'your_cur_database' and 'cur2_your_export' with your actual values

CREATE OR REPLACE VIEW bedrock_cost_base AS
SELECT
  DATE_TRUNC('day', CAST(line_item_usage_start_date AS TIMESTAMP)) AS usage_date,
  DATE_TRUNC('month', CAST(line_item_usage_start_date AS TIMESTAMP)) AS usage_month,
  line_item_usage_account_id AS account_id,
  product_region_code AS aws_region,
  product_model_id AS model_id,
  -- Extract model family from model_id (e.g. 'anthropic.claude', 'amazon.titan')
  SPLIT_PART(product_model_id, '.', 1) || '.' || SPLIT_PART(product_model_id, '.', 2) AS model_family,
  -- Token type extracted from usage_type suffix
  CASE
    WHEN line_item_usage_type LIKE '%InputTokens'       THEN 'InputTokens'
    WHEN line_item_usage_type LIKE '%OutputTokens'      THEN 'OutputTokens'
    WHEN line_item_usage_type LIKE '%CacheReadTokens'   THEN 'CacheReadTokens'
    WHEN line_item_usage_type LIKE '%CacheWriteTokens'  THEN 'CacheWriteTokens'
    ELSE 'Other'
  END AS token_type,
  line_item_operation AS operation_type,
  -- IAM principal attribution (requires CUR 2.0 with IAM principal data enabled)
  COALESCE(line_item_iam_principal, 'unknown') AS iam_principal,
  -- Cost allocation tags (replace tag key names with your activated tags)
  COALESCE(resource_tags_user_team,        'untagged') AS team,
  COALESCE(resource_tags_user_application, 'untagged') AS application,
  COALESCE(resource_tags_user_env,         'untagged') AS environment,
  -- Financials
  line_item_unblended_cost AS unblended_cost,
  -- Usage amount in CUR 2.0 for Bedrock is in 1000s of tokens
  line_item_usage_amount * 1000.0 AS token_count_raw,
  line_item_usage_amount AS usage_amount_raw
FROM athenacurcfn.cur2_your_export
WHERE line_item_product_code = 'AmazonBedrock'
  AND line_item_line_item_type NOT IN ('Credit', 'Refund', 'Tax')
  AND year >= '2025'
;

Extended View: Daily Aggregation with Cache Metrics

-- bedrock_cost_enriched view
-- Pivots token types into columns for cache efficiency calculations

CREATE OR REPLACE VIEW bedrock_cost_enriched AS
SELECT
  usage_date,
  usage_month,
  account_id,
  aws_region,
  model_id,
  model_family,
  team,
  application,
  environment,
  iam_principal,
  SUM(CASE WHEN token_type = 'InputTokens'      THEN unblended_cost ELSE 0 END) AS input_cost,
  SUM(CASE WHEN token_type = 'OutputTokens'     THEN unblended_cost ELSE 0 END) AS output_cost,
  SUM(CASE WHEN token_type = 'CacheReadTokens'  THEN unblended_cost ELSE 0 END) AS cache_read_cost,
  SUM(CASE WHEN token_type = 'CacheWriteTokens' THEN unblended_cost ELSE 0 END) AS cache_write_cost,
  SUM(unblended_cost)                                                            AS total_cost,
  SUM(CASE WHEN token_type = 'InputTokens'      THEN token_count_raw ELSE 0 END) AS input_tokens,
  SUM(CASE WHEN token_type = 'OutputTokens'     THEN token_count_raw ELSE 0 END) AS output_tokens,
  SUM(CASE WHEN token_type = 'CacheReadTokens'  THEN token_count_raw ELSE 0 END) AS cache_read_tokens,
  SUM(CASE WHEN token_type = 'CacheWriteTokens' THEN token_count_raw ELSE 0 END) AS cache_write_tokens,
  -- Total tokens that could be cached (input + cache read attempts)
  SUM(CASE WHEN token_type IN ('InputTokens','CacheReadTokens') THEN token_count_raw ELSE 0 END) AS cacheable_tokens
FROM bedrock_cost_base
GROUP BY 1,2,3,4,5,6,7,8,9,10
;

Adding Custom Dimensions via Tags

To slice by department or cost center, add the activated tag column to the SELECT and GROUP BY. Tag column names follow the pattern resource_tags_user_<lowercase_tag_key_with_underscores>. For IAM principal tags (April 2026+), the pattern is iam_principal_tag_<lowercase_key>.

If you need to join account IDs to human-readable account names, the CID framework’s optional Account Map module writes a account_map Glue table containing account_id → account_name mappings pulled from AWS Organizations. Join it:

JOIN account_map am ON b.account_id = am.account_id

5. SPICE Refresh Strategy for Bedrock Data

Dataset Size Estimation

A typical mid-scale Bedrock deployment making 500,000 inference calls per day generates approximately 2 million CUR line items per month (input, output, cache read, cache write rows, plus on-demand vs. PTU split). At ~500 bytes per Parquet row pre-aggregation, that is roughly 1 GB of raw Parquet per month — small relative to full-estate CUR data (which for large accounts runs 50–200 GB/month).

After SPICE compression (columnar, typically 4–6x for this data shape), a 12-month Bedrock history in SPICE requires approximately 2–3 GB of SPICE capacity.

Refresh Schedule Recommendation

Dataset Refresh Type Schedule Rationale
CUDOS summary_view Full refresh Daily at 06:00 UTC CUR data finalizes at ~03:00 UTC; 3hr buffer covers delivery delays
bedrock_cost_enriched Incremental refresh Daily at 06:30 UTC Offset by 30 min from CUDOS to avoid Athena concurrency pressure
bedrock_cost_base Not materialized in SPICE Query-time (Athena direct query) Used only by bedrock_cost_enriched as a view, not a standalone QS dataset

Incremental refresh configuration for bedrock_cost_enriched:

  • Incremental refresh window: last 3 days (Bedrock CUR can restate up to 2 days prior)
  • Lookback column: usage_date
  • Minimum refresh interval: daily (15-minute incremental refresh available but unnecessary for billing data)

SPICE Capacity Cost

Scenario Monthly SPICE needed Cost at $0.38/GB
12 months Bedrock-only enriched view ~3 GB ~$1.14/month
12 months full CUDOS estate (large account) 40–80 GB $15–$30/month
Full CUDOS + custom Bedrock views combined 45–85 GB $17–$32/month

SPICE allocation of 10 GB is included per Author license. A typical FinOps team of 3 authors gets 30 GB included — sufficient for most Bedrock-only deployments without additional purchase.

6. QuickSight Calculated Fields for Bedrock

These calculated fields are defined at the QuickSight dataset level (applied before SPICE ingestion) or at the analysis level (applied in visual calculations). Dataset-level is preferred for reuse across multiple analyses.

Cost per Million Tokens

# Cost per million input tokens (dataset-level calculated field)
# Avoids division by zero when input_tokens is 0

ifelse(
  {input_tokens} > 0,
  ({input_cost} / {input_tokens}) * 1000000,
  NULL
)

# Cost per million output tokens
ifelse(
  {output_tokens} > 0,
  ({output_cost} / {output_tokens}) * 1000000,
  NULL
)

# Blended cost per million total tokens (input + output + cache)
ifelse(
  ({input_tokens} + {output_tokens} + {cache_read_tokens}) > 0,
  ({total_cost} / ({input_tokens} + {output_tokens} + {cache_read_tokens})) * 1000000,
  NULL
)

Cache Hit Rate

The cache hit rate measures what fraction of total cacheable token volume was served from cache (avoiding full processing cost).

# Cache hit rate (percentage)
# cache_read_tokens: tokens served from cache
# cacheable_tokens: input_tokens + cache_read_tokens

ifelse(
  {cacheable_tokens} > 0,
  ({cache_read_tokens} / {cacheable_tokens}) * 100,
  0
)

Interpretation: A cache hit rate of 40% means 40% of prompts that could have been cached were successfully served from cache. Rates below 20% on workloads with repeated system prompts indicate suboptimal caching setup.

Cache Savings Estimate

# Estimated savings from cache reads vs. paying full input price
# Requires knowing the input token unit price for the model
# This approximation uses the average input cost rate as a proxy

ifelse(
  {input_tokens} > 0,
  {cache_read_tokens} * ({input_cost} / {input_tokens}),
  0
)

Note: This is an approximation. Cache read pricing is typically 10% of input token pricing (varies by model), so actual savings are cache_read_tokens * (input_price - cache_read_price). The exact delta requires joining against a reference table of Bedrock pricing by model.

Model Efficiency Ratio

The model efficiency ratio compares output tokens produced per dollar spent — a proxy for cost efficiency across models serving similar tasks.

# Output tokens per dollar (higher is more efficient)
ifelse(
  {total_cost} > 0,
  {output_tokens} / {total_cost},
  NULL
)

Month-over-Month Cost Change

# Percentage change vs. prior month (using periodOverPeriodDifference)
# This is a period comparison calculation at visual level

periodOverPeriodPercentDifference(
  sum({total_cost}),
  [{usage_month} ASC],
  1,
  [MONTH]
)

7. Cross-Account CID Deployment

Architecture

Management/Payer Account
  ├── AWS Data Exports: CUR 2.0 → s3://payer-cur-bucket/
  ├── S3 Replication Rule → Data Collection Account S3 bucket
  └── CloudFormation StackSets → push data collection modules to member accounts (optional)

Data Collection Account  (dedicated, separate from payer)
  ├── S3: receives replicated CUR data from payer
  ├── Glue: catalog for CUR Parquet + optional invocation log tables
  ├── Athena: workgroup CID, queries Glue tables
  ├── QuickSight Enterprise: CUDOS dashboard + custom analyses
  └── Covers ALL member accounts' Bedrock spend automatically
        (because CUR from payer account aggregates all org member spend)

All AWS Organization member accounts’ Bedrock costs appear in the payer CUR by default. No per-account setup is needed for cost visibility — every line_item_usage_account_id in the CUR represents a member account.

Account Identification

By default, CUDOS shows account IDs. To show account names, deploy the CID Account Map module:

cid-cmd bootstrap --module account-map

This deploys a Lambda that calls organizations:ListAccounts on a schedule and writes account name mappings to a separate Glue table. The CUDOS dashboard joins against this table automatically after the module is deployed.

Per-Account Bedrock Quota Guardrails

Cross-account CID provides spend visibility but not spend limits. For guardrails, configure AWS Budgets at the management account level with Bedrock-scoped budget filters (Service = Amazon Bedrock), plus per-linked-account budgets for accounts with known usage profiles.

8. CID vs. Custom Grafana

Decision Matrix

Factor CID / CUDOS Grafana + CloudWatch
Primary data source CUR 2.0 (billing actuals, finalized daily) CloudWatch metrics (near-real-time, pre-aggregated)
Token-level billing accuracy High (CUR is the bill) Moderate (CloudWatch TokenCount metrics; no cost data)
Latency / p95 / error rates Not available (CUR has no latency data) Available natively
Team attribution Via cost allocation tags in CUR Via CloudWatch dimension filtering
Setup cost Medium (CUDOS deployment, Glue, QuickSight author seats) Medium (Grafana Cloud or self-hosted, CloudWatch data source)
Operational overhead Low after deployment; cid-cmd update for upgrades Higher; custom dashboard maintenance
Best for FinOps, chargeback, CFO/CTO cost reporting Engineering, SRE, latency optimization, live debugging
Cross-account coverage Native (single payer CUR covers all accounts) Requires CloudWatch cross-account observability setup per account
Historical depth Unlimited (as long as CUR data is in S3) 15 months CloudWatch default; custom metrics shorter

When to Use CID

  • FinOps team needs chargeback reporting by team or application
  • CFO or VP Engineering wants monthly cost trends by model family
  • Organization runs 10+ AWS accounts and needs a consolidated Bedrock spend view
  • You need cache efficiency ROI reporting tied to actual billing

When to Use Grafana

  • Engineering team needs sub-minute latency dashboards alongside cost
  • Grafana is already the organization’s standard ops dashboard
  • You need to correlate Bedrock latency spikes with infrastructure events
  • Real-time model error rate monitoring is required

Migration Path: CloudWatch Grafana → CID

  1. Deploy CID alongside existing Grafana setup (non-destructive)
  2. Map existing Grafana cost panels to equivalent CUDOS panels; identify gaps
  3. Build custom Athena views to fill the gaps
  4. Migrate FinOps reporting to QuickSight; retain Grafana for operational/latency panels
  5. Decommission cost panels in Grafana after 30-day parallel run confirms accuracy

The two tools are complementary, not mutually exclusive. A mature Bedrock FinOps setup typically runs both: CID for billing actuals and chargeback, Grafana for real-time operational health.

9. KPI Dashboard Design for FinOps Teams

The six most actionable Bedrock FinOps KPIs for a QuickSight executive dashboard:

KPI 1: Monthly Bedrock Spend vs. Budget

  • Visual: KPI card with month-to-date spend, budget threshold line, and variance %
  • Calculated field: SUM(total_cost) filtered to current month
  • Alert threshold: Flag when MTD spend reaches 80% of monthly budget before month-end

KPI 2: Cost per Million Output Tokens by Model

  • Visual: Horizontal bar chart sorted descending; each bar is one model
  • Why it matters: A model costing $15/M output tokens vs. $3/M for equivalent quality represents 5x waste
  • Calculated field: See Section 6

KPI 3: Cache Hit Rate Trend

  • Visual: Line chart, daily, 90-day window; reference line at 30% (FinOps baseline target)
  • Why it matters: Cache hit rates below 20% on conversational or document Q&A workloads indicate system prompts are not being cached — a quick engineering fix with outsized cost impact
  • Calculated field: See Section 6

KPI 4: Top 5 Teams by Bedrock Spend (MoM Change)

  • Visual: Table with team name, current month spend, prior month spend, delta %, and model breakdown sparkline
  • Requirement: team cost allocation tag activated in billing console
  • Action trigger: Any team with >50% MoM increase warrants a conversation

KPI 5: On-Demand vs. Provisioned Throughput Cost Split

  • Visual: Donut chart; label each segment with cost and % of total Bedrock spend
  • Calculated field: Filter operation_type = 'ProvisionedThroughput' for PTU cost
  • Action trigger: If PTU cost exceeds 60% of total Bedrock spend, validate that PTU utilization (from invocation logs) is above 70% to justify the reservation

KPI 6: Bedrock Spend as % of Total AWS Bill

  • Visual: KPI card; denominator is total line_item_unblended_cost across all services
  • Why it matters: Surfaces when AI workloads are displacing compute as the primary cost driver — a CFO-level signal that AI governance is needed

10. Alert Integration

Architecture

CloudWatch Alarm (Bedrock TokenCount or InvocationCount threshold)
  → SNS Topic (BedRockCostAlerts)
    → EventBridge Rule (filters for budget breach or anomaly events)
      → Lambda (formats alert payload, optionally calls QuickSight Anomaly API)
        → Slack / email / PagerDuty

AWS Cost Anomaly Detection (separate service, not CloudWatch)
  → EventBridge event: aws.cost-management / CostAnomaly
    → SNS notification to FinOps team

CloudWatch Alarms for Bedrock

CloudWatch metrics available for Bedrock include InvocationCount, InputTokenCount, OutputTokenCount, CacheReadInputTokenCount, InvocationLatency, and InvocationThrottles. These are per-model-ID dimensions.

Example alarm: flag when daily InputTokenCount for a specific model exceeds a rolling 7-day average by 3 standard deviations, which catches runaway agents or prompt injection loops before they cause material cost damage.

Cost Anomaly Detection Integration

AWS Cost Anomaly Detection (a separate service from CloudWatch) natively monitors Bedrock spend with ML-based anomaly detection. Configure a monitor scoped to Service = Amazon Bedrock:

{
  "MonitorType": "DIMENSIONAL",
  "MonitorDimension": "SERVICE",
  "MonitorName": "Bedrock Cost Anomaly Monitor",
  "AnomalySubscriptions": [{
    "Threshold": 20.0,
    "ThresholdExpression": "GREATER_THAN",
    "MonitorArnList": ["arn:aws:ce::123456789012:anomalymonitor/..."],
    "Subscribers": [{"Address": "arn:aws:sns:us-east-1:...:BedRockCostAlerts", "Type": "SNS"}],
    "Frequency": "DAILY",
    "SubscriptionName": "Bedrock Daily Anomaly Alert"
  }]
}

Cost Anomaly Detection events fire into EventBridge as aws.cost-management source events, enabling automated remediation workflows (e.g., disabling an inference profile if spend anomaly is detected).

QuickSight Anomaly Detection

QuickSight’s built-in anomaly detection (available in Enterprise Edition) can be added to any time-series visual on the Bedrock FinOps dashboard. It uses Random Cut Forest (RCF) to flag anomalous data points inline in the visual. Configuration: right-click a line chart visual → Add Insight → Anomaly Detection. QuickSight anomaly detection does not send external alerts; it surfaces anomalies visually within the dashboard only.

11. CID Costs

QuickSight License Costs (Enterprise Edition, us-east-1, 2026)

License Type Monthly Cost SPICE Included Use Case
Author $24/user 10 GB FinOps engineers who build/edit dashboards
Author Pro $40/user 10 GB Authors who also use Q (natural language queries)
Reader $3/user (capped) or $0.30/session None Stakeholders who view dashboards only
Reader Pro $5/user None Readers with Q access

A typical FinOps setup: 2–3 Authors ($48–72/month) + 15–20 Readers ($45–60/month) = roughly $93–132/month in license fees before SPICE overage.

SPICE Capacity Costs

  • Included: 10 GB per Author license (2 Authors = 20 GB included)
  • Additional SPICE: ~$0.38/GB/month (Enterprise Edition)
  • Full CUDOS deployment for a large AWS estate: 40–80 GB total → $7–22/month in additional SPICE beyond the included allocation

Athena Query Costs

  • Athena charges $5.00 per TB of data scanned
  • CUDOS SPICE refreshes run Athena queries against CUR Parquet in S3
  • CUR 2.0 Parquet with partition pruning (by year/month) scans only the relevant partition
  • Typical CUDOS daily refresh: 2–5 GB scanned → $0.01–$0.025/day → ~$0.30–$0.75/month

Total Monthly Cost Estimate (Mid-Scale Bedrock Deployment)

Component Monthly Cost
QuickSight licenses (3 Authors + 15 Readers) ~$117
Additional SPICE (20 GB beyond included) ~$7.60
Athena query cost (daily SPICE refreshes) ~$0.50
Glue crawler (daily) ~$0.10
S3 storage for CUR data (12 months, ~50 GB) ~$1.15
Total ~$126/month

12. Well-Architected FinOps Review Checklist for Bedrock

AWS Solutions Architects conducting a Well-Architected review under the Cost Optimization Pillar and Generative AI Lens ask the following questions for Bedrock workloads. These map to specific CID/CUDOS panels or gaps that trigger custom build.

  1. “Are all Bedrock API calls tagged with cost allocation tags at the inference profile or IAM principal level?”

    • Failure: costs appear as untagged in bedrock_cost_enriched team dimension
    • Remediation: create Application Inference Profiles per team/app; activate team and application as cost allocation tags

  2. “Do you have a daily view of spend by model family, and can you identify the top 3 cost drivers?”

    • Verification: CUDOS “Top Bedrock Models by Cost” panel covers 30 days; custom summary_view query covers longer periods

  3. “What is your prompt cache hit rate, and have you validated it against your target?”

    • Failure: no team can answer this question without custom panels (CUDOS does not expose cache hit rate)
    • Remediation: deploy bedrock_cost_enriched view and cache hit rate calculated field

  4. “Do you use Provisioned Throughput for any Bedrock models, and what is the measured utilization vs. the reservation capacity?”

    • CID shows PTU cost share; utilization requires invocation log analysis outside CID

  5. “Is there a budget alert configured for Bedrock at the account and/or organization level?”

    • Verification: AWS Budgets console; Cost Anomaly Detection monitor scoped to Bedrock

  6. “Do you review Bedrock spend as part of monthly cost reviews, and does your FinOps team have a QuickSight dashboard for this?”

    • Maturity gate: CID/CUDOS deployed + custom Bedrock analysis with KPI dashboard

  7. “Have you evaluated cross-region inference routing for cost optimization?”

    • CUDOS “Bedrock Spend per Region” panel shows regional spend; cross-region inference pricing differential requires separate analysis

  8. “Are on-demand workloads that have predictable baselines candidates for Provisioned Throughput?”

    • Requires sustained daily token count trend from bedrock_cost_enriched to size PTU correctly

  9. “Is your token volume growing faster than your business outcomes (tokens per unit of value)?”

    • Advanced FinOps metric: requires joining Bedrock token data with application-level outcome metrics outside AWS billing

  10. “Do you have a Bedrock cost incident runbook — a documented process for responding to a 3x cost spike?”

    • Tooling: Cost Anomaly Detection alert → EventBridge → on-call page → predefined response actions (disable inference profile, reduce concurrency limits, escalate to team)

Key Gaps and Pending AWS Features (June 2026)

  • Invocation log integration into CID: Not yet supported. Bridging CUR cost data with CloudWatch invocation logs (which have per-request token counts and latency) requires a custom pipeline — typically Firehose → S3 → Athena — then a JOIN with CUR data on usage_account_id + usage_date.
  • CUDOS IAM principal columns: As of v5.8.1, line_item_iam_principal is not surfaced in standard CUDOS views. The column is present in CUR 2.0 after April 2026, but CUDOS view SQL has not been updated to include it. Workaround: create custom bedrock_cost_enriched view with the column included.
  • Sub-hourly CUR granularity: CUR 2.0 delivers hourly granularity at best. Real-time cost monitoring requires CloudWatch metrics as a separate data path.
  • Bedrock AgentCore cost visibility: The amazon-bedrock-agentcore usage types appeared in CUDOS v5.8.1 under the AI/ML section but are not yet broken out from the main Bedrock spend panels. Monitor CUDOS changelog for dedicated AgentCore panels.

Sources: AWS Cloud Intelligence Dashboards documentation; CUDOS v5 changelog (github.com/aws-solutions-library-samples/cloud-intelligence-dashboards-framework); AWS Bedrock CUR 2.0 documentation; AWS blog “Introducing granular cost attribution for Amazon Bedrock” (2026-04); AWS blog “Monitor and optimize your Amazon Bedrock usage with Amazon Athena and Amazon QuickSight”; QuickSight SPICE best practices documentation; AWS Cost Anomaly Detection EventBridge integration guide.