The 2 AM Cloud Bill Shock
It’s 2 AM, and your PagerDuty alarm goes off. This time, it’s not a database crash or network congestion. It’s an AWS budget alert: your EKS cluster bill just spiked by an extra $1,800 over the past five days. You fire up your laptop and check AWS Cost Explorer, only to find a single lump sum for your pool of EC2 worker nodes. AWS and GCP only bill you for the VMs you run. They have no visibility into which namespace, microservice, or team inside your cluster is quietly burning through cash.
Your existing Grafana dashboards only reveal raw hardware metrics. You know Pod A consumes 8 CPU cores and Pod B eats up 16 GB of RAM. But how many dollars per hour does Pod A actually cost? Nobody knows. Much like mastering OpenAI/Claude costs and rate limits with Prometheus & Grafana, you need to map real infrastructure pricing directly onto running container metrics—and that’s precisely where OpenCost shines.
How Does OpenCost Work with Prometheus?
OpenCost is an open-source CNCF Sandbox project and serves as the core cost-allocation engine behind Kubecost. Its primary mission: measure and allocate Kubernetes spend in real time.
Pricing Models and Cost Allocation
Every pod running on a worker node consumes hardware resources. OpenCost reads actual requests and usage, then reconciles them directly against cloud VM pricing from AWS, GCP, Azure, or custom on-premises rate cards:
- CPU & RAM Cost: Calculates the proportion of resources requested by a container relative to total node capacity, multiplying it by the instance type’s hourly rate (for example, a c5.2xlarge at $0.34/hr in AWS us-east-1).
- Storage Cost: Calculated directly from the StorageClass (such as GP3 or io2) and the provisioned capacity of the Persistent Volume Claim (PVC).
- Network Cost: Measures internet egress traffic, as well as cross-zone and cross-region data transfers.
The Dynamic Duo: OpenCost and Prometheus
Instead of building a new exporter from scratch, OpenCost fully leverages your existing Prometheus setup. It pulls cAdvisor and kube-state-metrics data straight from the cluster as input. Acting as a computation engine, OpenCost periodically queries resource metrics, multiplies them by VM unit rates, and exposes dedicated cost metrics (such as node_cpu_hourly_cost or opencost_allocation_cpu_cost_hourly) for Prometheus to scrape and display in Grafana.
Step-by-Step: Deploying OpenCost on Kubernetes
This guide assumes your cluster already has Prometheus Operator (kube-prometheus-stack) installed. The entire integration takes less than 10 minutes.
Step 1: Create a Namespace and Verify the Prometheus Endpoint
First, isolate your OpenCost resources in a dedicated namespace:
kubectl create namespace opencost
Next, find the internal service address for Prometheus. With kube-prometheus-stack, the service typically looks like this:
http://prometheus-operated.monitoring.svc.cluster.local:9090
If you run a standard Prometheus setup, the endpoint is usually http://prometheus-k8s.monitoring.svc.cluster.local:9090.
Step 2: Install OpenCost via Helm
Add the official OpenCost Helm repository:
helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm repo update
Create a values-opencost.yaml configuration file. Ensure you point to your correct Prometheus service name and cloud provider:
opencost:
prometheus:
internal:
serviceName: "prometheus-operated"
namespaceName: "monitoring"
port: 9090
exporter:
defaultClusterId: "production-k8s-cluster"
cloudProvider: "AWS" # Change to GCP or Azure depending on your infrastructure
ui:
enabled: true
serviceMonitor:
enabled: true
namespace: opencost
additionalLabels:
release: kube-prometheus-stack
Deploy the chart to your cluster:
helm install opencost opencost/opencost \
--namespace opencost \
-f values-opencost.yaml
Step 3: Verify Pod Health and Logs
Ensure pods are running cleanly and can talk to Prometheus without issues:
kubectl get pods -n opencost
# Inspect logs to verify metric scraping
kubectl logs -n opencost -l app.kubernetes.io/name=opencost -c opencost --tail=50
If you see log entries like Querying Prometheus at http://prometheus-operated... alongside successful cloud pricing downloads, your setup is up and running properly.
Step 4: Access the OpenCost UI
Without needing complex Ingress configuration right away, you can port-forward directly to view the dashboard:
kubectl port-forward --namespace opencost service/opencost-ui 9090:9090
Navigate to http://localhost:9090 in your browser. You can immediately slice and dice costs to your liking:
- Namespace: Instantly spot whether the Data team is racking up $45/day or the Core API team is spending $12/day.
- Controller / Deployment: Break down the standalone cost of each individual microservice.
- Cost Allocation Window: Track spending trends by hour, day, or over the last 30 days.
Step 5: Write PromQL Queries for Cost Alerting
Because OpenCost exports standard metrics, you can configure alerts directly via Alertmanager or build custom Grafana panels. To ensure you extract accurate insights rather than flawed aggregations, apply advanced PromQL techniques, and use Alertmanager silences and inhibition rules to reduce notification fatigue across teams.
Calculate total hourly spend by Namespace:
sum(opencost_allocation_cpu_cost_hourly + opencost_allocation_ram_cost_hourly) by (namespace)
Calculate wasted CPU spend from over-allocated, underutilized pods (Idle Cost):
sum(opencost_allocation_cpu_idle_cost_hourly) by (namespace)
This metric is pure gold: it shows you exactly where you’re paying for idle CPU cycles that deliver zero business value.
Wrapping Up
Don’t wait until the end of the month to brace yourself for your cloud bill. Pairing OpenCost with Prometheus gives you real-time transparency into every dollar spent across Kubernetes. Once you pinpoint which containers are wasting resources, fine-tuning requests/limits and shaving 20–30% off your infrastructure bill becomes straightforward.

