Cost Configuration
Cost configuration converts resource quantities into cost estimates so teams can prioritize by financial impact. The pricing values are simple multipliers — they are not real cloud provider prices — used to produce a cost signal for comparison and prioritization.
Configure cost settings in the EcoScale dashboard. The values apply consistently across the workloads being compared, so teams can sort by net impact and identify the highest-value optimization targets.
Pricing Inputs
Section titled “Pricing Inputs”EcoScale uses two pricing inputs to estimate cost from resource requests:
| Input | Example | Purpose |
|---|---|---|
| CPU core hourly cost | 0.0416 | Cost assigned to one CPU core per hour. |
| Memory GiB hourly cost | 0.00456 | Cost assigned to one GiB of memory per hour. |
Currency and display time unit (hour, day, month) can also be configured in the dashboard. Use values that make sense for how your team discusses Kubernetes spend. The important requirement is consistency: the same pricing basis should be used across the workloads being compared.
Reading Cost Impact
Section titled “Reading Cost Impact”EcoScale uses resource requests to estimate cost. Current cost represents the estimated cost of the workload’s current request configuration. Target cost represents the estimated cost if the recommendation requests are applied. Net impact is the difference between the two.
A negative net impact means projected savings. A positive net impact means EcoScale expects the workload to need more resources — often the right recommendation when performance or reliability needs headroom.
For the underlying formula, see Cost Impact.
Accelerator Cost Context
Section titled “Accelerator Cost Context”GPU-backed workloads can dominate Kubernetes spend even at modest scale. Review accelerator pricing assumptions carefully before using cost impact to prioritize GPU workloads — their runtime and scheduling constraints often require specialized knowledge beyond standard CPU and memory optimization.