# Data Explorer
## Data Explorer Overview
Data Explorer is a reporting tool for building multi-dimensional cost and usage reports. You define which measurements you want (cost, usage, counts) and which dimensions to break them down by and Data Explorer aggregates the underlying billing records into a table you can read on a daily, weekly, or monthly interval.
Use Data Explorer when a [MegaBill view](https://docs.finout.io/user-guide/inform/megabill#views) or a [dashboard widget](https://docs.finout.io/user-guide/inform/finops-dashboards/custom-dashboards) doesn't give you the row-level shape you need — for example, when you want a single table that combines several dimensions, applies a specific aggregation function, or surfaces resource-level metrics like running hours or object counts.
**Use cases**
Data Explorer fits scenarios such as:
* Breaking down costs by Resource ID, with filters for usage type, product family, or service.
* Tracking sub-service usage like S3 storage or NAT Gateway, measured in hours or gigabytes.
* Surfacing untagged data to guide your tagging strategy and improve cost allocation coverage.
**Measurements vs. Dimensions**
**Measurements** - Numerical values or quantitative data used to represent a particular aspect of the analyzed data. These can include numbers such as cost types, and usage.
**Dimensions** - Categories or classifications that help organize and group related measurements. These can include the service type, region, or any tags. Dimensions provide context to the measurements and allow for deeper analysis and understanding of the data. Dimensions affect the level of detail in the view.
## Creating a New Data Explorer
1. Navigate to **Data Explorer** in the navigation bar on the left side of the console.
2. Click **New Data Explorer**. The **Create new explorer** side window appears.
3. **Name**: Provide a name for your report.
4. **Description** (optional): Add a description for your report.
5. **Time Frame and Interval**: Define the relevant dates for your report data and the interval (day, week, or month).
6. **Filters** (optional): Filter the report using MegaBill components such as services, Cost Centers, or Virtual Tags.
7. **Dimensions** (optional): Add dimensions using MegaBill components such as services, Cost Centers, or Virtual Tags. Dimensions control how rows are grouped in the output.
8. **Measurements**: Define what each row should report. You can combine any of the following:
* **Cost/Usage Data**: Add a Cost or Usage Type field and choose how to aggregate values — **Sum**, **Average**, **Minimum**, or **Maximum**. To add another measurement, click **+**.
{% hint style="info" %}
**Note:** Aggregation functions operate across the billing records grouped into each row, not across days in the timeframe. The interval you choose (day, week, or month) controls grouping; the aggregation function controls how values within each group are combined.
{% endhint %}
| Function | What it does | When to use |
| ----------- | -------------------------------------------------- | ---------------------------------------------------------------- |
| **Sum** | Adds all values in the group. | Total cost or usage for a service, SKU, or tag combination. |
| **Average** | Divides Sum by the number of records in the group. | Typical cost per line item (e.g., per instance, per deployment). |
| **Minimum** | Smallest single billing record in the group. | Identifying low-cost outliers. |
| **Maximum** | Largest single billing record in the group. | Spotting spikes or anomalies. |
To make the difference concrete, here's a single grouped row. Data is grouped by **Instance Type** and **Day**:
| Sum (Net Amount) | Count | Average | Instance Type | Day |
| ---------------- | ----- | ------- | ------------- | ----------- |
| $9.00 | 4 | $2.25 | db.t3.medium | 24 Jul 2025 |
The **Sum (Net Amount)** of $9.00 is the total cost of all billing records that fall under *db.t3.medium* on 24 July 2025. The **Count** of 4 means four individual billing line items belong to this group. The **Average** of $2.25 is $9.00 ÷ 4 — the average cost per billing record, not a daily or time-based average.
* **Dimensional Analysis** (optional): Count the number of unique values within a dimension, or count the total number of entries within a dimension (including duplicates). For details, see the [Dimension Analysis section](https://docs.finout.io/user-guide/inform/data-explorer#h_e0e5ae30de). To add another dimensional analysis, click **+**.
* **Finout Predefined Queries** (optional): Prebuilt, standardized queries for common reporting needs, so you don't need to assemble them from scratch. For details, see the [Finout Predefined Queries section](https://docs.finout.io/user-guide/inform/data-explorer#h_c67965ba36).
* **Additional Billing Metrics** (optional): Select additional billing metrics that surface Savings Plan and Reservation information from the CUR. See the [AWS documentation](https://docs.aws.amazon.com/cur/latest/userguide/cur-sp.html) for details on Savings Plans.
9. **Columns management** (optional): Reorder or rename the selected fields. Drag measurements up or down using the dots beside each measurement.
10. **Order by**: Set the row order based on a selected measurement.
11. Click **Save** to generate the report. Once saved, the report displays with all selected data.
## Working with Data Explorer
### Open and manage existing reports
1. Navigate to **Data Explorer** to see the list of saved reports.
2. From the list, you can edit, duplicate, or delete any report.
{% hint style="info" %}
**Note**: You can open a Data Explorer report in a new browser tab directly from the Data Explorer list.\
Right-click the data explorer and select **Open in New Tab**, or use:
* **Command + Click** on macOS
* **Ctrl + Click** on Windows or Linux
This lets you compare multiple reports side by side.
{% endhint %}
### Open a report
1. Navigate to **Data Explorer**.
2. Choose a **Data Explorer report.**
### Export a report to CSV
1. Open the report you want to export.
2. Click **Download CSV** and choose one of the following options, then click **Export**.
1. **Top Results Export**: Instantly export a CSV file with the top 10 thousand rows.\
or
2. **Full Data Export**: Generate and send a detailed report of your endpoint with up to 6 full months of data.
For Full Data Export:
* Choose an **Endpoint.** See [Endpoints](/settings/endpoints.md) for more information.
* **Time Frame -**The default time frame is based on your report, but you can adjust it to any time range you prefer.
### Edit, duplicate, or delete a report
From an open report, you can:
* **Edit Data Explorer**: make the necessary edits and click **Save**.
* **Duplicate Data Explorer**: create a copy of the report.
* **Delete Data Explorer**: remove the report.
## Dimension Analysis
In Dimension Analysis, two key concepts are used to gain insights into your data:
* **Count Distinct Dimensions**: Counts the number of unique values within a specific dimension.\
*Use Case #1*: Analyzing user tags - Counting distinct dimensions shows how many unique tags exist across all resources. This helps you understand the diversity and categorization within that dimension.\
*Use Case #2*: Determine the distinct number of resources for each service per day- Identify the various values for each user tag and check the number of instance types for EC2/RDS or the number of regions per account.
* **Count Dimensions**: Counts the total number of entries or occurrences within a dimension, including duplicates.
Note: This feature is supported for every dimension in Data Explorer and is available for all accounts.
1. Select one of the following:
* **Count Distinct** - Count the values that are unique from one another based on what was selected above.
* **Count** - Count all the values that have been selected.
Note: If you selected the same dimension as in the report, you will only receive one return per value.
2. Click **Dimension**.\
The Dimension window appears.
3. Mark the dimensions that you want to be used for the analysis and click **Apply Group By**.
4. Click to add another dimensional analysis.\
## Finout Predefined Queries
Predefined queries are prebuilt, standardized queries designed to streamline data retrieval and analysis. Created to address common data needs or reporting requirements, they allow for quick access to specific data sets or insights without the need to craft complex queries from scratch.
### Resource Normalized Runtime
The Resource Normalized Runtime metric measures the total operational time of resources within a specified timeframe, normalized against the total hours in that period. It is calculated by dividing the total running hours of all resources by the total number of hours in the timeframe.
{% hint style="info" %}
**Note**: When grouping by date, each timeframe is set to 24 hours.
{% endhint %}
**Formula**:
* Resource Normalized Runtime = Total Running Hours / Total Hours in Timeframe
* Numerator (Total Running Hours): The cumulative sum of hours all queried resources were active during the specified timeframe.
* Denominator (Total Hours in Timeframe): The total number of hours within the specified timeframe.
Note: When grouping by date, this is set to 24 hours.
**Example Calculations:**
**Scenario 1**: 5 Resources Over 3 Days
| **Date** | **Total Running Hours** | **Total Hours in Timeframe** | **Resource Normalized Runtime** |
| ---------- | ----------------------- | ---------------------------- | ------------------------------- |
| 2024-07-28 | 79 | 24 | 3.29 |
| 2024-07-29 | 85 | 24 | 3.54 |
| 2024-07-30 | 74 | 24 | 3.08 |
*2024-07-28*:
Total Running Hours: 79 hours (cumulative for all 5 resources)
Total Hours in Timeframe: 24 hours
Resource Normalized Runtime: 79 / 24 = 3.29
**Scenario 2**: 3 Resources Over 2 Days with Resource IDs
| **Date** | **Resource ID** | **Total Running Hours** | **Total Hours in Timeframe** | **Resource Normalized Runtime** |
| ---------- | --------------- | ----------------------- | ---------------------------- | ------------------------------- |
| 2024-07-28 | i-abc123 | 30 | 24 | 1.25 |
| 2024-07-28 | i-def456 | 40 | 24 | 1.67 |
| 2024-07-29 | i-ghi789 | 35 | 24 | 1.46 |
*i-abc123*:
Total Running Hours: 30 hours
Total Hours in Timeframe: 24 hours
Resource Normalized Runtime: 30 / 24 = 1.25
**Scenario 3**: 4 Resources Over 1 Day
| **Date** | **Total Running Hours** | **Total Hours in Timeframe** | **Resource Normalized Runtime** |
| ---------- | ----------------------- | ---------------------------- | ------------------------------- |
| 2024-08-01 | 24 | 24 | 1.00 |
*2024-08-01*:
Total Running Hours: 24 hours (cumulative for all resources running the entire day)
Total Hours in Timeframe: 24 hours
Resource Normalized Runtime: 24 / 24 = 1.00
**Scenario 4**: Aggregated Resources Over Multiple Days Without Date Column
| **Resource ID** | **Total Running Hours** | **Total Hours in Timeframe** | **Resource Normalized Runtime** |
| --------------- | ----------------------- | ---------------------------- | ------------------------------- |
| i-abc123 | 120 | 240 | 0.50 |
| i-def456 | 200 | 240 | 0.83 |
| i-ghi789 | 160 | 240 | 0.67 |
| i-jkl012 | 80 | 240 | 0.33 |
*i-abc123*:
Total Running Hours: 120 hours
Total Hours in Timeframe: 240 hours (10 days x 24 hours/day)
Resource Normalized Runtime: 120 / 240 = 0.50
**Scenario 5**: Aggregated Total Running Hours Without Date or Resource ID
| **Total Running Hours** | **Total Hours in Timeframe** | **Resource Normalized Runtime** |
| ----------------------- | ---------------------------- | ------------------------------- |
| 2100 | 600 | 3.50 |
| 2400 | 600 | 4.00 |
| 3000 | 600 | 5.00 |
| 1800 | 600 | 3.00 |
*Entry 1*:
Total Running Hours: 2100 hours
Total Hours in Timeframe: 600 hours
Resource Normalized Runtime: 2100 / 600 = 3.50
### Resource Normalized Runtime vCPU
Resource Normalized Runtime vCPU: This metric calculates the total normalized vCPU runtime used by resources over a specified timeframe. It is determined by multiplying the total running hours of each resource by its vCPU count and dividing by the total number of hours in the timeframe.
{% hint style="info" %}
**Note**: When grouping by date, each time frame is set to 24 hours.
{% endhint %}
**Formula**:
* Resource Normalized Runtime vCPU = Σ (Running Hours x vCPU) / Total Hours in Timeframe
* Numerator: The cumulative sum of the product of running hours and vCPU count for each resource.
* Denominator (Total Hours in Timeframe): The total number of hours within the specified timeframe. When grouping by date, this is set to 24 hours.
**Example Calculations:**
**Scenario 1**: Multiple Resources with vCPUs Grouped by Day
| **Date** | **Resource ID** | **vCPU** | **Running Hours** | **Normalized Runtime vCPU** |
| ---------- | --------------- | -------- | ----------------- | --------------------------- |
| 2024-07-28 | i-12345678 | 5 | 24 | 5.00 |
| 2024-07-28 | i-12345677 | 6 | 12 | 3.00 |
| 2024-07-28 | i-12345676 | 3 | 16 | 2.00 |
| 2024-07-28 | i-12345675 | 2 | 17 | 1.42 |
| 2024-07-28 | i-12345674 | 16 | 20 | 13.33 |
*i-12345678*:
Calculation: (5 x 24) / 24 = 5.00
The resource consumed 5.00 vCPU days.
**Scenario 2**: Mixed vCPU Resources Over 2 Days
| **Date** | **Resource ID** | **vCPU** | **Running Hours** | **Normalized Runtime vCPU** |
| ---------- | --------------- | -------- | ----------------- | --------------------------- |
| 2024-07-28 | i-98765432 | 8 | 18 | 6.00 |
| 2024-07-28 | i-87654321 | 4 | 10 | 1.67 |
| 2024-07-29 | i-76543210 | 2 | 5 | 0.42 |
*i-98765432*:
Calculation: (8 x 18) / 24 = 6.00
The resource consumed 6.00 vCPU days.
**Scenario 3**: Aggregated vCPU Resources Over Multiple Days
| **Date** | **Resource ID** | **vCPU** | **Running Hours** | **Normalized Runtime vCPU** |
| ---------- | --------------- | -------- | ----------------- | --------------------------- |
| 2024-07-30 | i-55555555 | 10 | 40 | 16.67 |
| 2024-07-30 | i-44444444 | 6 | 20 | 5.00 |
| 2024-07-31 | i-33333333 | 3 | 15 | 1.88 |
*i-55555555*:
Calculation: (10 x 40) / 24 = 16.67
The resource consumed 16.67 vCPU days.
**Scenario 4**: vCPU Resources Without Date or Resource ID
| **vCPU** | **Running Hours** | **Total Hours in Timeframe** | **Normalized Runtime vCPU** |
| -------- | ----------------- | ---------------------------- | --------------------------- |
| 8 | 200 | 600 | 2.67 |
| 4 | 150 | 600 | 1.00 |
| 6 | 240 | 600 | 2.40 |
*Entry 1*:
Calculation: (8 x 200) / 600 = 2.67
The resources consumed 2.67 vCPU days in the timeframe.
### EBS Running Hours
This metric calculates the total running hours of EBS resources within a specified timeframe and tracks the cumulative hours that they have been active.
**Formula**:
-EBS Running Hours = Sum of Running Hours for EBS Resources in a selected timeframe.
-Total Running Hours: The cumulative sum of hours that individual EBS resources were active within the selected timeframe.
\- Per resource: The total hours for each resource are summed based on the timeframe and aggregation type.
\- For grouped resources: When multiple resources are grouped, their running hours are summed together to give the total running hours.
**Example Calculations**:
**Scenario 1**: Single Resource Over 2 Days, Group by Day
| **Date** | **Total Running hours** |
| ---------- | ----------------------- |
| 2024-08-01 | 22 |
| 2024-08-02 | 18 |
For 2 days:
* Total Running Hours for August 1: 22 hours
* Total Running Hours for August 2: 18 hours
The total running hours over these two days for a single resource is 40 hours.
**Scenario 2**: 3 Resources Over 4 Days, Group by Day
| **Date** | **Total Running Hours** |
| ---------- | ----------------------- |
| 2024-09-05 | 65 |
| 2024-09-06 | 72 |
| 2024-09-07 | 80 |
| 2024-09-08 | 78 |
For 4 days with 3 resources:
* Total Running Hours for September 5 for all 3 resources: 65 hours
* Total Running Hours for September 6 for all 3 resources: 72 hours
* Total Running Hours for September 7 for all 3 resources: 80 hours
* Total Running Hours for September 8 for all 3 resources: 78 hours
The total running hours over these four days is 295.
**Scenario 3**: 5 Resources Over 1 Month (August)
| **Date Range** | **Total Running Hours** |
| ------------------------ | ----------------------- |
| 2024-08-01 to 2024-08-31 | 3,000 hours |
The total running hours for August for all 5 resources is 3000 hours.
### S3 Number of Objects
The S3 Number of Objects metric calculates the average number of objects stored in your S3 buckets from the last 24 hours of a selected timeframe. This metric is derived from CloudWatch data and helps monitor object count trends in your S3 buckets, providing insights into storage usage.
{% hint style="info" %}
**Note**: The resource ID will be automatically added to your Data Explorer report when selecting this predefined query.
{% endhint %}
**Scenario 1**: Number of Objects in S3 Buckets, Broken Down by Virtual Tag Teams
You want to create a report of the number of S3 objects in a bucket over April.
{% hint style="info" %}
**Note**: The S3 Number of Objects metric calculates the average number of objects stored in your S3 buckets from the last 24 hours of the selected timeframe. For example, in the table below, Bucket001, Team A, had an average of 1,500,000 objects on April 30th.
{% endhint %}
| **Resource ID** | **Team** | **Number of S3 Objects** |
| --------------- | -------- | ------------------------ |
| Bucket 001 | Team A | 1,500,000 |
| Bucket 001 | Team B | 800,000 |
| Bucket 002 | Team A | 1,100,000 |
| Bucket 003 | Team C | 500,000 |
| Bucke t003 | Team B | 900,000 |
**Scenario 2**: Number of Objects in S3 Buckets in Q1 2024, Broken Down by Month
You want to create a report for Q1 with object counts in monthly intervals to monitor the growth of data in your S3 buckets over time.
| **Resource ID** | **Month** | **Number of S3 Objects** |
| --------------- | --------- | ------------------------ |
| Bucket 001 | January | 1,200,000 |
| Bucket 002 | January | 900,000 |
| Bucket 001 | February | 1,500,000 |
| Bucket 003 | February | 600,000 |
| Bucket 002 | March | 1,000,000 |
| Bucket 003 | March | 800,000 |
**Scenario 3**: Number of Objects in S3 Buckets, Broken Down by Virtual Tag Teams and by Week
You want to create a report for the previous month with weekly intervals, showing the number of objects in each S3 bucket, broken down by virtual tag teams.
| **Resource ID** | **Team** | **Week** | **Number of S3 Objects** |
| --------------- | -------- | -------- | ------------------------ |
| Bucket 10 | Team A | Week 1 | 11,000 |
| Bucket 10 | Team A | Week 2 | 8,800 |
| Bucket 10 | Team B | Week 1 | 3,000 |
| Bucket 20 | Team A | Week 3 | 21,800 |
| Bucket 20 | Team B | Week 2 | 16,700 |
### Daily Actual Storage
Daily Actual Storage transforms AWS's billing-focused GB-Month reporting into actionable, day-by-day storage insights. While AWS Cost & Usage Reports (CUR) are perfect for monthly invoicing, they create a blind spot for engineering teams who need to see what's happening daily on their storage infrastructure.
Daily actual storage shows how many GB were in your storage for a particular day, and not the normalized daily GB (1GB / day per month) from the CUR. Finout converts these normalized daily GB back into precise daily GB measurements, revealing the actual storage footprint on your daily storage (S3, EBS Snapshots, EFS, etc). \
\
Due to the varying number of days each month, the CUR may show artificial daily spikes or drops at the start and end of the month. Using actual daily storage values keeps the data consistent and reflects the actual GB storage.
{% hint style="info" %}
**Note**: The **Normalized Storage** column only returns values when **GB-Mo** is selected as the unit. If any other unit is used, the column will display **0**.
{% endhint %}
**Daily Usage Example**
If you store 1 GB of data for just 1 day, that’s about 1/30 of a month:
* **CUR daily storage data:** 1 GB × (1 ÷ 30) = 0.033 GB-Mo\
Since you used only a fraction of the month, you’re charged only a fraction of the cost. This is a **pro-rated charge**; you only pay for what you use.
* **Finout Daily Actual Storage:** 1 GB stored for a whole month = 1 GB-Mo
### **FAQs**
**Question**: What is the difference between the object count from CloudWatch and the object count from AWS CUR.
**Answer**: The CUR alone does not provide object-level or detailed bucket insights without integrating other AWS tools such as S3 Storage Lens (with advanced metrics) or S3 Inventory. Without these, the CUR will only show aggregated S3 storage usage and costs.
**Question**: How can I get object count data per S3 bucket in the AWS CUR?
**Answer**: To obtain object count data per S3 bucket in the CUR, you need additional services:
\- S3 Storage Lens with advanced metrics- This is required for detailed usage insights.
\- S3 Inventory: Provides detailed reports at the object level but does not integrate directly into the CUR.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.finout.io/user-guide/inform/data-explorer.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.