Skip to main content
Thoras estimates cost savings and waste by analyzing your workload resource requests against predicted usage patterns. This guide explains how these calculations work and how to customize pricing data for your environment. Workloads on EC2 (or other instance-based) nodes and pods on EKS Fargate are billed differently, so Thoras prices them separately and adds the results. For a workload with pods on both, Thoras records each sample’s Fargate pods and their actual CPU and memory requests. The average node then prices only the remaining pods’ resources, and each Fargate pod is priced from its own provisioned size, so no pod is counted twice. The workload forecast has no per-pod breakdown, so its Fargate part is apportioned by replica count.

​
How Cost Calculations Work

Thoras calculates potential savings by comparing your current resource allocations with forecasted recommendations. The calculation involves three main components:

​
1. Determining Average Node Cost

Thoras establishes a baseline “average node cost per hour” for your cluster:
  1. Node Discovery - Collects node information similar to the output from kubectl get nodes -oyaml
  2. Metadata Extraction - Parses labels to identify:
    • Cloud provider (AWS, GCP, Azure, etc.)
    • Instance type (e.g., m7g.medium, n2-standard-4)
    • Capacity type (on-demand or spot)
  3. Price Matching - Matches node details against pricing data to determine hourly cost, CPU cores, and memory
  4. Cluster Averaging - Averages cost, cores, and memory across all nodes to establish cluster-wide baseline
If pricing data is unavailable for a node (e.g. unknown instance type), that node is excluded from the cluster’s “average node.” EKS Fargate nodes are always excluded, because Fargate is billed per pod (see EKS Fargate Pricing). If no nodes can be priced, Thoras defaults to 4 cores, 16GB memory, and $0.19/hour (equivalent to an AWS t3.xlarge). Note: This approach provides ballpark estimates rather than precise billing figures. The goal is directional guidance on how rightsizing workloads impacts your overall cloud spend. On EKS, you can have Thoras collect your real billed spend instead — see AWS Cost Explorer.

​
2. Calculating Workload-Level Savings

For each workload, Thoras compares original controller specifications (e.g. Deployment, StatefulSet, ArgoRollout) against forecasted resource recommendations: Over-provisioned workloads (positive delta):
  • Current requests exceed predicted usage
  • Labeled as waste in recommendation mode
  • Labeled as savings in autonomous mode
Under-provisioned workloads (negative delta):
  • Current requests fall below predicted usage
  • Tracked as Resources Needed (recommendation mode) or Resources Added (autonomous mode)
  • Thoras recommends increasing resources to improve stability
Thoras tracks the potential reduction (or required increase) in CPU cores and memory bytes per hour for each workload.

​
3. Cluster-Wide Cost Impact

Thoras aggregates workload-level changes across your entire cluster:
  1. Sum wasted or saved CPU and memory across workloads on instance-based nodes
  2. Express each as a fraction of the average node:
    • Aggregate CPU core reduction ÷ average node cores
    • Aggregate memory reduction ÷ average node memory
  3. Use the larger of the two, since the binding resource determines how many nodes are needed
  4. Multiply by average node hourly cost to estimate cluster savings
  5. Add the EKS Fargate savings or waste, which are priced per pod
This represents the maximum potential savings if all right sizing recommendations were applied autonomously by Thoras.

​
EKS Fargate Pricing

On EKS, Thoras recognizes Fargate nodes by the eks.amazonaws.com/compute-type: fargate label. Fargate bills each pod for the vCPU and memory it is provisioned, not for the node size Kubernetes reports, so Thoras prices Fargate pods separately from the average node:
  • Current cost uses the size AWS records on the pod in its CapacityProvisioned annotation (for example 0.25vCPU 0.5GB).
  • Original and recommended costs size the pod as Fargate would: the larger of the init and long-running container requests, plus 256 MB for Fargate’s Kubernetes components, rounded up to the next supported vCPU and memory combination.
  • Rates are the on-demand Linux rates for the pod’s region. EKS Fargate does not offer Spot, Arm or Windows pods, and Thoras does not price the additional ephemeral storage beyond the included 20 GB.

​
Rounding and Savings

Because Fargate rounds every pod up to a supported size, a smaller request does not always lower the bill. For example, reducing a pod from 1 vCPU and 1.5 GB to 0.6 vCPU and 1.2 GB still provisions 1 vCPU and 2 GB, so Thoras reports no savings for it. Savings appear only when a recommendation moves the pod to a smaller billable size, and recommendations that need a larger size are reported as resources added or needed, never as savings.

​
Missing or Partial Pricing

Thoras never prices a Fargate pod with the average node. When a pod cannot be priced, the dashboard shows the cost as unavailable, or marks a total as partial: the amount shown then covers only the pods that could be priced. When nothing in an amount can be priced, it is shown as unavailable rather than $0; a $0 amount always means the priced inputs add up to zero. This happens when:
  • A pod has no CapacityProvisioned annotation yet, or it cannot be parsed.
  • A pod’s node is not visible to Thoras, so its compute type is unknown.
  • Thoras has no Fargate rates for the pod’s region.
  • Thoras watches only some namespaces and the pod on a Fargate node is outside them. The node is still shown as Fargate in the node summary, but without a price.
  • A workload has no active vertical recommendation, or its original configuration cannot be determined, so its recommended or original cost cannot be sized. Its current cost is still reported.
Cost alerts follow the same rules: a period that cannot be priced at all neither triggers an alert nor counts as under the threshold, and an alert on a partial total says that it covers only the pods that could be priced. The node summary continues to estimate a finished Fargate pod’s cost while its node and provisioned-capacity metadata remain visible.

​
History

Fargate costs are recorded with each new metrics sample, for the collection interval it represents; a retried collection is counted once. History before the upgrade that adds Fargate pricing, and periods when samples were not collected, contain no Fargate costs, and Thoras does not reconstruct them from older data. Within a period, Fargate costs are averaged over all of the workload’s samples, like average-node costs, so a brief Fargate period affects only its own share of the period. History uses retained five-minute buckets for recent hours, hourly buckets for approximately a month, and daily buckets for older periods. At range boundaries, a bucket is included when its start falls inside the selected range. Older history therefore has coarser time precision; Thoras does not spread a sample’s cost across the empty portion of a bucket.

​
Idle Spend

For Fargate, requested spend uses the pod’s provisioned size. Used spend estimates the supported billable size needed by its measured usage, including Fargate’s memory overhead. Usage within the same billable tier produces no idle-dollar estimate. Missing usage or pricing makes that portion unavailable. CPU and memory usage charts continue to show the physical resource measurements. Node-price overrides and billing calibration apply only to the EC2 portion of a mixed workload. Fargate uses the regional rates recorded with each sample.

​
Sourcing Pricing Data

Because Thoras operates in an air-gapped environment without real-time cloud API access, pricing data comes from a built-in static price list that is periodically updated in product releases. This includes the regional EKS Fargate rates, taken from the AWS Price List. These estimates do not require AWS credentials; collecting your actual billed spend with AWS Cost Explorer is a separate, optional feature.

​
Handling Spot Pricing

Spot instance pricing fluctuates based on supply and demand. Rather than tracking real-time spot prices, Thoras uses published average savings percentages from cloud providers. For example, according to AWS EC2 Spot Instance Advisor, a spot m7g.medium provides an average 59% savings over on-demand pricing (as of February 5, 2026). Note: Your actual spot costs may differ from dashboard estimates because Thoras uses static averages rather than current market rates.

​
Preemptible Instances

Preemptible instances (GCP’s predecessor to their spot offering) are priced using spot pricing data as a proxy. While not exact, the two pricing models are typically close. Your actual preemptible costs may vary from dashboard estimates.

​
Overriding Average Node Cost

You can manually override the calculated average node cost when:
  • Your cluster uses an bespoke instance types
  • You have custom pricing agreements or reserved instance discounts
  • You want more precise cost calculations based on your actual billing
To override the average node cost, navigate to the cluster settings in the Thoras dashboard and enter your custom value. Overrides apply to workloads on instance-based nodes only; EKS Fargate pods are always priced with their regional Fargate rates.

​
What’s Included (and What’s Not)

Included in cost calculations:
  • CPU and memory resource costs
  • Node-level infrastructure pricing
Not included in cost calculations:
  • Reserved instance or savings plan discounts, including Compute Savings Plans applied to Fargate
  • Committed use discounts (GCP)
  • Custom pricing agreements
  • Fargate ephemeral storage beyond the included 20 GB
For workloads with significant non-compute costs, treat Thoras savings estimates as a lower bound on total potential savings.

​
Horizontal Scaling Savings and Waste

Vanilla HPA is reactive by design. To protect against sudden traffic spikes, teams typically run workloads at 20-30% utilization. Thoras’s predictive horizontal scaling allows workloads to run at much higher instantaneous utilization (80-90%) by scaling proactively based on forecasts. However, Thoras uses vanilla HPA as a safety backstop, always scaling to the higher value between the Thoras forecast and vanilla HPA’s recommendation. Realizing savings from this improved utilization requires increasing HPA’s target utilization metric, which is a manual configuration change. Because savings depend on customer action to adjust HPA settings, cost estimates exclude horizontal scaling savings.

​
Mixed Instance Types

Thoras handles heterogeneous clusters gracefully:
  • Mixed capacity types - Averages across spot and on-demand instances
  • Multiple instance types - Blends pricing across different machine types
  • Multi-cloud - Averages across cloud providers if nodes span multiple clouds
Note: This averaging approach ignores bin-packing optimizations that tools like Karpenter might achieve. Actual savings may be higher if your autoscaler can consolidate workloads onto fewer nodes.

​
Node Detail Collection

Thoras snapshots node metrics every 5 minutes and rolls up aggregates hourly and daily. Cost projections are based on these aggregated usage patterns.