AWS Builder Center is the official home for builders on AWS. Share and read what others are working on, follow people who inspire you, explore training and workshops, and find tools to support what you're building.
How to enable natural language cost queries across multiple business units using Amazon Quick Topics and Cost and Usage Dashboard Operations Solution(CUDOS) datasets
Organisations with multiple business units or operating companies sharing a consolidated AWS billing estate often struggle with dashboard filter limitations when using Cloud Intelligence Dashboards (CID). The QuickSuite chat agent embedded in dashboards is scoped to the current filter state and cannot query the underlying datasets directly. This article shows how to configure QuickSight Q Topics over CUDOS SPICE datasets.
The Problem
Organisations with multiple operating companies — business units within an enterprise, brands within a holding company, airlines within a group — share a common frustration with traditional BI dashboards: every question starts with a filter change.
Consider a large enterprise with multiple business units sharing a consolidated AWS account structure. Their FinOps team uses the Cost and Usage Dashboard Operations Solution (CUDOS), part of the Cloud Intelligence Dashboards (CID) framework, for cost visibility. The dashboards are powerful, but a typical workflow looks like this:
- Open CUDOS dashboard
- Change the account
- Find the relevant visual
- Note the answer
- Change the filter to "Business Unit B"
- Repeat
The Quick default chat agent embedded in dashboards can answer natural language questions — but it's scoped to the dashboard's current filter state and visuals, not the underlying dataset. It cannot cross-filter, compare payers side-by-side, or answer questions the dashboard author didn't anticipate.
Amazon QuickSight Quick Topics solve this by connecting the natural language engine directly to the underlying SPICE datasets — bypassing dashboard filter constraints entirely.
The Solution: Quick Topics on CUDOS Datasets
Quick Topics let you define a subject area over one or more SPICE datasets, enrich it with business context (synonyms, calculated fields, semantic types), and expose it to users via a natural language search. Users ask questions in plain English; Quick translates them into queries against the raw data.
Target Datasets
The CUDOS framework deploys key Athena views materialised into SPICE. For this write-up, I have considered the below datasets only, but this can be extended to any datasets:
| Dataset (SPICE) | Grain | Use Case |
|---|---|---|
| summary_view | Daily, multi-dimensional (service, operation, usage type, region) | High-level spend trends, month-over-month(MoM) comparisons |
| hourly_view | Hourly, resource-level | Spike analysis, time-of-day patterns |
| resource_view | Resource-level with tags | Resource attribution, waste identification |
| ta-organizational-view | TA check per account | Operational health, optimisation recommendations |
By creating a Quick Topic across these four datasets, you enable questions like:
- "What did Business Unit B spend on EC2 last month?"
- "Show me the top 5 most expensive resources in the logistics division"
- "Which operating company has the most critical Trusted Advisor findings?"
- "Compare S3 spend across all airlines quarter over quarter"
No filter changes. No dashboard navigation. Just a question.
Architecture
The data flows through the following stages:
- CUR export — AWS Data Exports delivers CUR 2.0 data to Amazon S3
- Query layer — Amazon Athena queries the CUR views (summary_view, hourly_view, resource_view, ta-organizational-view)
- Caching — SPICE datasets cache the Athena results for fast querying
- Topic layer — The Quick Topic sits on top of all four SPICE datasets with synonyms, calculated fields, named filters, and named entities configured
- User access — Users ask natural language questions via the Quick Chat bar; QuickSight translates them to queries against the raw SPICE data
Implementation Guide
Step 1: Create the Quick Topic
- Navigate to Quick → Topics → Create Topic
- Name it descriptively:
FinOps Cost & Operations Intelligence - Add a description: "Ask questions about AWS cost, usage, and operational health across all operating companies"
- Add the four SPICE datasets: summary_view, hourly_view, resource_view, ta-organizational-view
Step 2: Configure Dimensions
Dimensions are the categorical fields users will filter and group by. Please note that the column names might differ based on how your views are setup. For each dataset, review and configure. You also have the options to filter and choose which columns you need to include as part of the Topic. Include only those that will contribute to the search.
| Field | Semantic Type | Role | Notes |
|---|---|---|---|
| linked_account_name | Organisation | Dimension | Primary BusinessUnit identifier |
| linked_account_id | Identifier | Dimension | AWS account ID |
| service | None | Dimension | AWS service name |
| region | Location | Dimension | Enables "where" questions |
| usage_type | None | Dimension | Granular usage classification |
| resource_id | Identifier | Dimension | Individual resource |
| tag_environment | None | Dimension | Environment tag (prod/dev/staging) |
| tag_cost_centre | None | Dimension | Business cost attribution |
| charge_type | None | Dimension | Usage, Tax, Credit, Fee |
| purchase_option | None | Dimension | On-Demand, Reserved, Spot, Savings Plan |
Key configuration: Set PayerAccountId as the primary Organisation semantic type — enables "who" questions. Set usage_date as the Default Date for hourly_view and resource_view (enables 'last week', 'yesterday' queries). Set month as the Default Date for summary_view (enables 'last month', 'this quarter' queries).
Step 3: Configure Measures
| Field | Default Aggregation | Not Allowed | Notes |
|---|---|---|---|
| unblended_cost | Sum | None | Primary cost metric |
| amortized_cost | Sum | None | RI/SP-adjusted cost |
| usage_amount | Sum | None | Consumption volume |
| net_unblended_cost | Sum | None | Post-discount cost |
| public_on_demand_cost | Sum | None | List price baseline |
| ri_sp_effective_cost | Sum | None | Commitment-covered cost |
| estimated_savings | Sum | Average | TA savings estimate |
Step 4: Add Synonyms
This is where you teach Quick your organisation's language. Synonyms bridge the gap between how your data is labelled and how your users speak.
Field-Level Synonyms:
| Field | Synonyms |
|---|---|
| unblended_cost | spend, cost, charges, bill, expenditure |
| linked_account_name | business unit, operating company, airline, brand, division |
| service | AWS service, product, service name |
| amortized_cost | committed cost, effective cost, amortized spend |
| usage_amount | consumption, usage, volume |
| purchase_option | pricing model, purchase type, commitment type |
| ta-organizational-view checks | Trusted Advisor, TA, health checks, recommendations |
Value-Level Synonyms (Critical for Multi-Org):
| Field | Value | Synonyms |
|---|---|---|
| PayerAccountId | Business Unit A | Business Unit A or short names what users will normally use |
| PayerAccountId | Business Unit B | Business Unit B or short names what users will normally use |
| PayerAccountId | Business Unit C | Business Unit C or short names what users will normally use |
This means a user can ask "What did Business Unit A spend on compute last quarter?" and Quick resolves "Business Unit A" to the correct account filter — no manual filter change required.
Pro tip: The CUR 2.0 data dictionary (https://docs.aws.amazon.com/cur/latest/userguide/data-dictionary.html) contains field descriptions that map closely to how users ask questions. Use these descriptions as a source for synonyms — e.g., the CUR field line_item_usage_amount is described as "the amount of usage incurred" → add "usage incurred", "consumption amount" as synonyms for usage_amount.
Step 5: Add Calculated Fields
Calculated fields let you derive business metrics that don't exist in the raw data:
| Calculated Field | Expression | Synonyms | Default Aggregation |
|---|---|---|---|
| Savings Plan Coverage Rate | sum(ri_sp_effective_cost) / sum(public_on_demand_cost) * 100 | SP coverage, commitment coverage, savings plan utilisation | Average |
| On-Demand Waste | sum(unblended_cost) - sum(ri_sp_effective_cost) | waste, uncovered spend, on-demand exposure | Sum |
| Cost Per Day | sum(unblended_cost) / countDistinct(usage_date) | daily run rate, daily cost, burn rate | Average |
| Month-over-Month(MoM) Change | percentDifference(sum(unblended_cost), [usage_date], -1, Month) | MoM change, monthly change, month over month | None |
⚠️ Percentages and rates must use Average aggregation, not Sum. Mark Sum as "Not Allowed" for derived ratios to prevent misleading results. Note: The table below shows starter calculated fields. The CUDOS framework includes additional derived metrics (e.g., RI utilisation rate, normalised usage, data transfer cost ratio). Add these iteratively as users request them — start narrow, validate accuracy, then expand.
Step 6: Add Named Entities
Named entities return pre-defined table layouts when users ask for a concept:
| Entity Name | Fields Returned |
|---|---|
| Business Unit summary | linked_account_id, unblended_cost, amortized_cost, mom_change, savings_plan_coverage_rate |
| Resource details | resource_id, service, linked_account_name, unblended_cost, usage_amount, tag_environment |
| TA health | linked_account_name, check_name, check_status, estimated_savings, flagged_resources |
Step 7: Give custom instructions to the Topic and test it out
You are an AWS Cost Intelligence assistant that answers questions about AWS cloud spending, usage, and cost optimization using CUDOS (Cloud Intelligence Dashboards) data stored in Amazon QuickSight SPICE. Data Context: You are working with pre-aggregated CUDOS views ingested into SPICE datasets. These views are derived from AWS CUR 2.0 data but have simplified, pre-joined schemas. The primary datasets are: - summary_view (monthly/daily aggregated costs) - hourly_view (hourly granularity) Terminology Mappings: - "cost" or "spend" → SUM(unblended_cost) unless they specify amortized/public - "account" → account_id (this is a STRING dimension, never aggregate it mathematically) - "last month" → previous full month in the dataset - "RI" or "reserved instance" → purchase_option = Reserved - "Savings Plan" or "SP" → purchase_option = SavingsPlan Important: SPICE-Specific Behavior: - Data is pre-ingested into SPICE. You cannot run arbitrary SQL — you work with the fields available in the SPICE datasets. - account_id is a STRING dimension. Never SUM, AVG, or perform arithmetic on it. - Filters are applied on SPICE-cached data, not live Athena queries.
Step 9: Link to a QuickSight Space
-
Navigate to QuickSight → Spaces (or create a new Space for your FinOps community)
-
Share the Topics with the Space — this makes the Q search bar available to all Space members
-
Users can use the default chat agent with the Space to ask questions
Optionally embed the space to a custom chat agent The following is an example system prompt for the chat agent.
You are an AWS Cloud Intelligence assistant connected to Spaces linking the following Topics: ## Connected Topics CUDOS Topic (summary_view, hourly_view): Cost/usage data — unblended_cost, amortized_cost, public_cost, usage_quantity, linked_account_id, service, region, instance_type, purchase_option, charge_type, month/usage_date. TAO Topic (ta_organizational_view): Trusted Advisor org-wide check results — account_id, check_name, category (Security, Cost Optimization, Fault Tolerance, Performance, Service Limits), status (error=Red, warning=Yellow, ok=Green), region, resource_id, estimated_monthly_savings, is_suppressed, metadata. ## Rules 1. Ground every answer in Topic data. Query the linked SPICE datasets. Never fabricate numbers. 2. Cite your source. Every data point must reference its Topic: - "From the CUDOS Topic (summary_view)..." - "From the TAO Topic..." - "Cross-referencing CUDOS and TAO Topics..." 3. Be specific. Include exact numbers, account IDs, service names, check names, regions, and time periods. Never say "some accounts" or "significant savings" without data. 4. Cross-reference Topics when valuable: - TAO Cost Optimization findings + CUDOS spend data = prioritized savings by account - CUDOS cost spikes + TAO Service Limits = capacity risk correlation - TAO Security Red findings + CUDOS account spend = risk-weighted prioritization 5. When data is unavailable: - State: "This data is not available in the connected Topics." - Name which Topic would contain it - Suggest checking the relevant QuickSight dashboard or AWS console - Never estimate or invent data ## Terminology Cost (CUDOS Topic): - "cost"/"spend" → SUM(unblended_cost) - "amortized cost" → amortized_cost - "on-demand cost" → public_cost - "savings" (cost context) → public_cost minus amortized_cost - "account" → linked_account_id (STRING dimension, never aggregate mathematically) - "service" → service - "daily cost" → group by usage_date from hourly_view - "monthly cost" → group by month from summary_view - "RI" → purchase_option = 'Reserved' - "Savings Plan"/"SP" → purchase_option = 'SavingsPlan' - "on-demand" → purchase_option = 'OnDemand' - "spot" → purchase_option = 'Spot' Trusted Advisor (TAO Topic): - "red"/"critical"/"error"/"action required" → status = 'error' - "yellow"/"warning" → status = 'warning' - "green"/"ok"/"passed" → status = 'ok' - "security" → category = 'Security' - "cost optimization"/"waste" → category = 'Cost Optimization' - "performance" → category = 'Performance' - "fault tolerance"/"resilience"/"HA" → category = 'Fault Tolerance' - "limits"/"quotas" → category = 'Service Limits' - "findings"/"flags"/"issues" → rows in the dataset - "affected accounts" → COUNT DISTINCT(account_id) - "potential savings" → SUM(estimated_monthly_savings) where status IN ('error','warning') ## Defaults - Cost queries: exclude charge_type = 'Credit' and 'Refund' unless explicitly asked - TA queries: show only Red and Yellow findings; exclude suppressed items unless asked - Top-N: default to 10 - Cost rounding: USD to 2 decimal places - TA severity order: Red first, then Yellow, then Green ## Response Format Every analytical response must include: - What the data shows — specific metrics from Topics - Why it matters — business or operational impact to your organization - Recommended next steps — clear actions your team can take Example: > From the TAO Topic: 14 accounts have Red findings for IAM Access Key Rotation (47 keys unrotated >90 days). Cross-referencing CUDOS Topic: 3 of these accounts represent 68% of your org spend ($142K/month). We recommend prioritizing key rotation in these high-spend accounts first: 111111111111 ($52K), 222222222222 ($28K), 333333333333 ($17K). Style: - Simple queries → concise answer with source citation - Trends/comparisons/recommendations → detailed analysis, bullet points, structured summaries - Tone: clear, helpful, and business-friendly — as if advising your cloud operations or FinOps team - Use "your" and "your organization" when referring to the customer's environment - Avoid internal AWS jargon; prefer plain business language Data freshness: Topic data reflects the last SPICE refresh. For real-time data, check the live dashboard or AWS console directly.
Test the Chat agent: Prompt: What is the highest spend service across all the linked accounts? Share insights by usage.
Before and After
Before (Dashboard-only):
- User: "What did Airline A spend on S3 last month?"
- Steps: Open CUDOS → Change Payer filter to "Business Unit A" → Navigate to S3 tab → Read visual
- Time: ~2 minutes, requires dashboard familiarity After (Quick Topic):
- User types: "What did Business Unit A spend on S3 last month?"
- Quick returns: £14,230 (with visual breakdown)
- Time: ~5 seconds, no training required
Example Questions Now Possible
| Question | Datasets Used |
|---|---|
| Compare EC2 spend across all payers this quarter | summary_view |
| Which resources cost more than £1000/day in production? | hourly_view, resource_view |
| Show me Business Unit B storage details for March | resource_view |
| How many critical Trusted Advisor findings does BA have? | ta-organizational-view |
| What's our savings plan coverage by Payer Accounts? | summary_view (calculated field) |
| Top 10 most expensive resources across all airlines | resource_view |
| Daily burn rate trend for Airline C last 30 days | hourly_view (calculated field) |
Automating Topic Configuration
For organisations with existing business glossaries or data dictionaries, Quick Topics configuration can be partially automated:
- Export your business dictionary — terms, synonyms, and field mappings — as a CSV
- Use the QuickSight API — CreateTopic and UpdateTopic APIs accept synonym definitions programmatically
- Template approach — create a base topic configuration (JSON) that new deployments can import and customise with org-specific synonyms
This is especially valuable for partner-deployed CUDOS instances where the same framework is rolled out to multiple customers with different terminology.
Best Practices
- Start narrow, expand later — Begin with summary_view and a few synonyms. Validate accuracy before adding all four datasets. Use the "verify answers" feature to mark responses as Accepted.
- Invest in value synonyms — The biggest ROI comes from teaching QuickSight your organization's shorthand for accounts, teams, and services.
- Set correct aggregations — Percentages and rates must use Average, not Sum. Mark Sum as "Not Allowed" for derived ratios.
- Use the feedback loop — QuickSight shows every question users asked and whether it answered correctly. Review weekly and add missing synonyms.
- Separate concerns — Create one Topic for cost intelligence (summary + hourly + resource views) and a second for operational health (ta-organizational-view) if the user base differs.
- Refresh cadence — Ensure SPICE datasets refresh on the same schedule as your CUR pipeline (typically daily). Stale data erodes trust.
Prerequisites
- Amazon QuickSight Admin/Pro or Author/Pro license
- CUDOS deployed via Cloud Intelligence Dashboards with SPICE datasets
- CUR 2.0 or Legacy CUR configured with Athena integration
- SPICE capacity sufficient for your dataset sizes
Conclusion
Dashboard filters were designed for a world where authors anticipated every question. In multi-organization environments, the combinatorial explosion of filters makes this impractical. QuickSight Quick Topics flip the model: instead of pre-building every view, you teach the system your business language and let users ask what they need.
For organizations running CUDOS, the four core datasets already contain the answers. Quick Topics simply make those answers accessible through natural language — no filter gymnastics required.
The result: a FinOps team that spends less time navigating dashboards and more time acting on insights.
This pattern works equally well for both single and multi-organization scenario.
Further Reading
- Language
- English
Relevant content
asked 5 years ago
asked 2 years ago
