Cloud Costs

The Cloud Costs page connects to your cloud provider to track live spend, remaining credits, your resource inventory, and wasted spend from idle or underutilized resources.

What you'll see

• Live billing per connected account, plus a daily spend chart per service (AWS and Azure; see Live Cloud Billing below)
• A service and region breakdown of your spend (AWS and Azure)
• Credits remaining
• Idle and underutilized resources, so you can reclaim wasted spend
• Budgets: set one and get warned as you approach it

Connecting a provider

Add a cloud provider connection on this page with read-only billing credentials:

• AWS: Access Key ID and Secret Access Key (plus region)
• Azure: Tenant ID, Client ID, Client Secret, and Subscription ID
• GCP: a service account with billing-account access

Use least-privilege, billing-read-only credentials. Once connected, KubeWatch pulls billing data and populates the breakdowns and idle detection.

Click the pencil icon on a connected account to rename it or replace its credentials, without deleting and re-adding it. Leaving "Update credentials" unchecked keeps the existing ones as they are. This is also how to fix an account stuck showing a signature/authentication error after a credential rotation: paste the corrected key in and save.

Live Cloud Billing

Pick a billing period from the dropdown (the last 30 days, live; any of the last 12 calendar months; or a custom range) to query that period directly from each provider's cost API, not a cached snapshot. AWS and Azure both support real historical queries and a daily-granularity spend chart per service. GCP's Budgets API only ever reports the current budget cycle: selecting a historical period for a GCP account shows a note explaining that, rather than silently re-showing the current numbers under the wrong date.

Idle & Underutilized Resources

Any instance that isn't currently running (stopped, deallocated, or similar) but still has an attached disk is flagged here: cloud providers don't bill for compute on a stopped instance, but the disk keeps costing money for as long as it exists, so this is real, reclaimable spend. Utilization-based rightsizing for instances that are running (e.g. an oversized instance sitting at 2% CPU) isn't implemented yet; that needs each provider's monitoring API (CloudWatch, Azure Monitor, Cloud Monitoring), a separate, larger integration.

Infrastructure Estimates

The Infrastructure Estimates tab lists every compute instance (EC2, Azure VM, or GCP instance) in the connected cloud account, with a cost estimate for each, from a direct instance-list call rather than the billing API above. This is deliberately every instance the account has, not just the ones running Kubernetes: it's meant to match what you'd see in the cloud provider's own console.

If a Kubernetes cluster monitored via the Kubernetes Agent is running on this same cloud account, some instances in this list are the exact same physical machines already shown on the Nodes page with their own cost estimate. That's expected, not a duplicate bug: a Kubernetes node is itself a cloud VM. KubeWatch tags any matching instance with a Kubernetes node badge linking back to its Nodes page entry, so it's clear why the same machine appears in both places, while the total on this page still only counts it once.

Pricing accuracy

Estimates here are priced live and region-aware wherever possible, pulled directly from AWS's Price List API and Azure's Retail Prices API for the instance's own region, not a single global rate applied everywhere, which previously made a London instance and a Virginia instance show the same price. GCP's pricing catalog has no equivalent exact-match lookup per machine type, so GCP estimates use a live, region-specific blended per-vCPU/per-GB rate for the instance's machine family instead of one exact price. If a live price can't be resolved (an unrecognized instance type, a transient API error, or no pricing credential configured), KubeWatch falls back to a hand-maintained static rate table rather than showing nothing.

The Nodes page prices AWS, Azure, and GCP nodes the same live, region-aware way, resolved by the Kubernetes Agent itself rather than the dashboard backend; see that agent's livePricing.enabled Helm value. It's off by default, since it's a new outbound call the agent didn't previously make; turning it on requires nothing extra for Azure, AWS needs the node's own IAM role to allow pricing:GetProducts, and GCP needs an API key set via livePricing.gcpApiKey (restricted to the Cloud Billing API, not tied to any specific GCP project). Any node the agent can't resolve a live price for, whichever provider and for whatever reason, falls back to the existing static/capacity-based estimate rather than showing nothing.

This page no longer includes a separate "Container Cost Estimates" section: it used to price every container, Docker included, against global, hardcoded per-vCPU/per-GB rates with no cloud context at all, which produced a number for workloads that may not even be running on a cloud VM. Container-level cost attribution needs a real cost-allocation model (e.g. splitting a node's actual bill by each container's share of requested resources) rather than an invented flat rate; it isn't implemented yet.