- How Kubernetes information is collected and organized
- The logic used to calculate waste
- How weights are used
Information Collection
Snow Cloud Cost uses many data sources across available clouds to gather information about your Kubernetes usage. The table below lists the sources and what specifically is used for Snow Cloud Cost Kubernetes telemetry.| Cloud Provider | Source | Details Used |
|---|---|---|
| AWS | CUR file | Cost Metrics |
| AWS | CloudWatch agent | K8s |
| AWS | Direct API calls | Recommendations |
| AWS / Azure / GCP | Prometheus agent* | K8s |
| Azure | Billing file & direct API calls | Cost Metrics |
| Azure | Azure log client | K8s |
| GCP | BigQuery | Cost Metrics & K8s |
| GCP | GCP monitoring client | K8s & recommendations |
The Kubernetes information collected is comprised of Cost Data used to determine billing amounts, and Mapping Data used to correlate usage to specific billable resources.
Mapping data is the basic information collected from the cloud provider which is stored in the Snow Cloud Cost database, including:
- Static information derived from metrics
- Limits (cpu-limit, memory-limit)
- Requests (cpu-request, memory-request)
- Entities (clusters, nodes, pods, namespaces, node-groups, etc.)
- Relationships between the above
- Dynamic information defining actual usage for:
- Nodes and pods
- Multiple metrics (CPU, memory, storage, data transfer, network, etc.)
All of this data is combined and processed to assign each K8s entity its proportional share of the total K8s costs. Costs are distributed to reflect actual usage. The diagram below demonstrates the flow of data within Snow Cloud Cost.
The next diagram illustrates how Snow Cloud Cost correlates the usage with the cost.
Waste Calculation
All resources (CPU, memory, etc.) not in use are considered waste. Waste at the pod happens when usage is less than requested resources, and waste at the node level happens when total pod usage is smaller than the node capacity.You can use namespaces to subdivide clusters. This is especially helpful when different teams or projects share a Kubernetes cluster. There is no limit on namespaces supported by a cluster, each logically segregated but still able to communicate with one another.
Waste at the node level not associated with any namespace is shown on the Kubernetes Cost & Usage Explorer as not allocated.
Example 1 - No waste at the pod level
As the actual usage is higher than requested, there is no waste.
Example 2 - Waste at the pod level
As the actual usage is lower than the requested usage, the pod is underutilized and waste occurs.
Example 3 - Waste at the node level
This example shows a node with 32GB of memory populated with 3 pods using 30 GB. This leaves 2 GB unused memory that Snow Cloud Cost identifies as waste.
For waste at the pod level, Snow Cloud Cost applies the calculation for any resource with known reservation settings against the data collected for actual usage. For waste at the node level, Snow Cloud Cost applies the calculation for resources where the capacity data is known versus the actual usage data, that is aggregated from pods.
Note that currently Snow Cloud Cost only shows memory and CPU waste on pod and node levels. Pod level waste is still measured as part of the pod's usage, so the cost of waste is accounted for in its namespace.
Using the Allocate Waste Cost option as shown below, you can distribute node level unused cost among the pods of each node, portioning the pod's usage within the node. This ensures each cost is associated with an actual namespace for accounting purposes.
Doing so means that in the Kubernetes Cost & Usage Explorer, when grouping by namespace it's possible to see:
- Namespaces which are Not allocated representing the cost of nodes without a namespace
- Costs of specific namespaces, for example the devops name space shown below with the cost $597.46
When Allocate waste cost is selected, the following occurs:
- Not allocated namespaces are no longer shown as costs are allocated proportionally across existing namespaces
- The devops namespace's cost increased to $724 which rep[resents its share of the not allocated resources, based on its proportional costs for the other metrics.
Weights
The weight feature is only available for AWS cloud accounts.Weights are used when Snow Cloud Cost might not be able to definitively determine a pod's cost. In this situation, Snow Cloud Cost provides users with the choice to assign weights per instance type so the costs are applied appropriately. If no weights are specified, Snow Cloud Cost assigns a default 1:1 ratio between the resources.
The examples below illustrate how weights are used to solve a number of issues.
In AWS, behind each node there’s an EC2 instance, with a fixed price based on its type. This raises a challenge in dividing the cost to pods hosted by this instance. In a simplified example where each pod used 25% of the node’s capacity, dividing the cost is easy. The waste in this example is obviously $50.
However the reality is that the ratio of pod usage versus node capacity varies with each resource. Snow Cloud Cost binds the cost-worth of each pod to a range, but cannot provide a definitive cost value for an entire pod individually. Simply put, there is no one correct answer.
The value of each isolated resource (CPU, RAM, network) is subjective. The only objective value is the total cost for the entire instance. To overcome this, Snow Cloud Cost provides users with the option to assign weights per instance type to split the costs according to their preference.
Remember, if no weights are specified, Snow Cloud Cost assigns the default 1:1 ratio between the resources. The weight options are found under Kubernetes > Preferences.
Was this helpful?
Related Articles
Connecting Kubernetes Clusters to Snow Cloud Cost 8Number of Views Accessing the Snow Cloud Cost API 8Number of Views Creating and Managing Budgets in Snow Cloud Cost 9Number of Views Adding an Azure Pay As You Go Account 8Number of Views Adding an Azure Enterprise Agreement (EA) Account 7Number of Views
Revenera Assistant
Online
Hi, I am Reva - Ask me anything.
Updates
No new updates
Chat
Home
Updates
/**/
Thanks for the feedback!
Your feedback has been saved.Rate this response:
1
2
3
4
5
Add Additional feedback ( Optional )
0/240
English
English
Language changed successfully
Something went wrong
Email sent successfully
Something went wrong
Case create successfully
Are you sure you want to cancel
the case creation?
Please select a product to submit the case.
Please select a product version to submit the case.
0/255
Upload Attachment
File Upload
Maximum file
size allowed is 3 MB.
File type
not supported.
Supported file types:
Documents (.txt, .doc, .docx, .pdf), Images (.jpg, .png), Comma Separated Files
(.csv) Speadsheets (.xlsx, .xls)
Are you sure you want to cancel the case creation?
Case closed successfully
File Upload
Maximum file size allowed is 3 MB.
File type not supported.
Supported file types:
Documents (.txt, .doc, .docx, .pdf), Images (.jpg, .png), Comma Separated Files
(.csv) Speadsheets (.xlsx, .xls)
Are you sure you want to close this case
| Products | Region | Phone Numbers |
|---|---|---|
| FlexNet Operations FlexNet Embedded FlexNet Publisher FlexNet Connect FlexNet Code Insight InstallAnywhere InstallShield |
North America * |
+1 630-332-2513 (toll) +1 877-279-2853 (toll-free in North America) |
| Europe * |
+44 1925 944367 (toll) +44 800 047 8642 (toll-free in Europe) |
|
| Japan * | +81 3-4540-5335 (select option 2) | |
| Australia * |
+61 3 9895 2177 +61 1800 560 603 (toll-free in Australia) |
|
|
Usage Intelligence (formerly
Revulytics) Compliance Intelligence |
Please use the Case Portal to submit your support ticket or reach out to your Revenera contact. | |
File Upload
Maximum file
size allowed is 3 MB.
File type
not supported.
Supported file types:
Documents (.txt, .doc, .docx, .pdf), Images (.jpg, .png), Comma Separated Files
(.csv) Speadsheets (.xlsx, .xls)
© 2026 Flexera Software. All Rights Reserved.
Case id: 00001065
Activity: Status change: 2 hours ago