Cost Views

Cost Views are curated, CloudYali-managed lenses on your cloud bill. Each view is a saved combination of filters + grouping + chart that answers one specific question — for example, "Where is my cross-region data-transfer spend going?" or "What does each team cost this month?"

You don't build a view to get value: CloudYali ships a tight, predefined set so that a new account with billing data connected sees correct numbers on first open, with zero configuration.

Screenshots pending

The images for this page are captured from the live docker-compose stack against the CLO-15 sample-data profile once the Cost Views UI (CLO-10 / CLO-11) and sample data (CLO-15) land. See Cost Views — Developer Notes for how to run the stack locally. Until then, the surfaces are described below so the structure is final.

What is a View?

A View is a stored object with three parts:

Part	What it is	Example
Filters	Which billing line items the view selects. Boolean AND / OR / NOT over billing fields (service, usage type, region, account, charge type, …) and over virtual tags (team, environment, …), using equals, in, and contains.	usage_type contains "DataTransfer-Regional"
Grouping	The single dimension the selected spend is broken down by — any billing field or virtual tag.	group by region
Chart type	How the view renders by default — a stacked bar or a line chart.	bar

Because a view filters billing line items plus their virtual tags, it can select spend that has no resource attached — regional data-transfer charges, for instance, carry a service, usage type, and region but no resource_id. Those rows are first-class in a view, never dropped (see The Unattributed bucket below).

In v1, all views are CloudYali-managed and read-only — you browse and run them, you don't author your own yet. User-authored views are a later phase.

Collections — overlapping chips, not folders

Views are organized into Collections such as Networking, Showback, and Optimization.

The key idea: a collection is a tag on a view, not a folder. A single view can belong to several collections at once — Data Transfer – Between Regions, for example, lives in both Networking and Optimization. Collections are therefore shown as filter chips, and a view with two tags appears under both. There is no "move to folder" — nothing has a single home.

Views that carry no collection tag are gathered under an Uncategorized group purely in the UI, so no view is ever orphaned.

Two different "un-" words

Uncategorized describes views with no collection tag (a list-page grouping). Unattributed describes cost that has no resource or no value for the grouped dimension (a bucket inside a view's results). They are unrelated — see the next section.

The render surface

Selecting a view opens its render surface:

• A chart (stacked bar or line) of the grouped spend over time.
• A data table of the same grouped numbers below the chart.
• A time-range control — Last 7 / 30 / 90 days (default 30) — that re-queries and re-renders.
• A Share of Total Cost chip (see below).
• The Unattributed bucket, always visible in both chart and table.

Time range, cost type, and granularity

• Time ranges: three fixed presets — Last 7, 30, or 90 days (default 30). Custom date ranges and month-to-date are not part of v1.
• Cost type: amortized cost, applied consistently across the chart, the table, and the total, so reserved-instance and savings-plan spend is spread evenly rather than spiking on the purchase day.
• Granularity: daily — every view returns a per-day time series plus per-group totals.

Share of Total Cost

Every view shows a Share of Total Cost chip:

Share of Total Cost = this view's total ÷ your full cloud bill for the same period.

The denominator is always the full, unallocated bill — not the filtered subset. That choice is what keeps the number honest, and it has one consequence worth understanding:

Views are filters — they do not sum to your bill

Views can overlap (the same line item can match several views) and they can leave spend uncovered. So the Share-of-Total percentages across your views do not add up to 100%, and the view totals do not sum to your bill. A view answers "how big is this slice relative to the whole bill," not "here is a partition of the bill." A view covering the entire bill reads 100.00%; an empty view reads 0.00%.

The Unattributed bucket

Inside a single view, the grouped numbers obey a strict conservation guarantee:

The group costs in a view always sum to that view's filtered total, to the cent.

To make that true even for spend that has no resource or no value for the grouped dimension, CloudYali folds those rows into one explicit, visible Unattributed group rather than dropping them. This covers two cases:

• Resourceless line items — e.g. regional data-transfer charges where resource_id is empty.
• Missing tag values — when you group by a virtual tag (say, team) and some line items have no value for that tag.

Unattributed is real spend, shown in the chart and the table — not noise and not an error. It is the visible proof that nothing was silently discarded. This is also why the marquee view, Data Transfer – Between Regions, can reconcile into the full bill exactly: its resourceless rows land in Unattributed instead of disappearing.

The starter set (illustrative)

v1 ships 4–6 curated views across at least two collections, including at least one resourceless data-transfer view. The exact list is finalized with FinOps curation, but the shape is:

View	Filters / grouping	Collections
Data Transfer – Between Regions	regional transfer usage types, grouped by region/service (resourceless gate view)	Networking, Optimization
RDS Compute by Purchase Option	RDS compute, grouped by purchase option	Optimization
Cost by Team	grouped by the team virtual tag (showback)	Showback
Compute Cost by Environment	grouped by the env virtual tag	Showback

Data Transfer – Between Regions carries two collection tags, demonstrating the many-to-many nature of collections.

Related documentation

• Cost Reports — scheduled daily and monthly cost summaries delivered to your inbox.
• Cost Optimization — savings recommendations across your cloud accounts.