Savings
Savings priced against your own bill
KubeOn measures what each workload uses and prices the difference with your billed rates. Every finding shows the rule that found it and a monthly saving, and turns into a change proposal your team can review.
Spot planner
Spot candidates backed by evidence, never a static discount
The Spot planner picks workloads ready to move, with their prices and savings from real data. On AWS it shows interruption risk per instance type from the public Spot Instance Advisor, and it keeps on-demand as the fallback. The candidates you select become reviewed proposals.
- Prices from real quotes, not assumed discounts
- On-demand fallback kept through Karpenter
- Selected candidates become proposals
Commitments
What you committed to, and when it ends
KubeOn reads AWS Savings Plans and Reserved Instances, Google Cloud committed use discounts, and Azure reservations and savings plans, so renewals and coverage gaps show before the bill reflects them. A node change never leaves family-bound commitments paid for and unused.
- Coverage and expiry by commitment
- Read-only cloud APIs
- Node proposals respect what you already bought
Managed databases
Database savings the bill can prove
From the billing export, KubeOn finds steady on-demand database spend you could reserve, previous-generation instance classes, gp2 storage and Multi-AZ outside production, for RDS and Aurora, Cloud SQL, Azure SQL, Cosmos DB, DynamoDB and other managed databases.
- No database access needed
- Reservations sized to the 30-day floor
- Older classes and gp2 storage
Container requests
Requests sized from p95 usage, with headroom and a floor
For each workload, KubeOn takes p95 CPU and memory per pod over 7 days, from Prometheus when it is configured and from the agent's hourly samples when it is not. Requests under 30% utilized are flagged, and the recommendation is p95 plus 20%, never below 0.025 cores or 0.25 GB.
- p95 over 7 days, per pod, per container group
- 20% headroom, with floors so small services stay schedulable
- Workloads at 2% or less are flagged as abandoned instead
Node groups and families
Smaller nodes when both resources sit idle, a new family when one does
Node groups are sized from 14 days of peak hourly requests with 20% headroom. When 40% or more of both CPU and memory is spare, KubeOn proposes smaller nodes. When 50% or more of one resource is spare, it proposes a different family, with the saving capped at the typical price gap of one family step.
- Peak requests, not averages, so the sizing survives your busiest hour
- Karpenter NodePool snippets or managed node group steps
- Works for EC2, Azure VM and Compute Engine node pools
# Use smaller nodes in prod-use1-a / generalapiVersion: karpenter.sh/v1kind: NodePoolmetadata: name: generalspec: template: spec: requirements: - key: karpenter.k8s.aws/instance-category operator: In values: ["m"] - key: karpenter.k8s.aws/instance-cpu operator: Lt values: ["9"] # was 16 vCPU; peak requests fit in 8
Volumes and storage
Orphaned, released and oversized volumes, checked before deletion
A volume that keeps billing a day after its PersistentVolume disappeared is orphaned. A PV left in Released or Available that still bills is reclaimable. A volume whose peak use over 14 days is far below its size is oversized. Volumes without a PV or a cluster tag are shown as an upper bound until checked.
- Snapshot-then-delete scripts that touch only available volumes
- Over-provisioned PVCs sized to peak times 1.5, never below 1 GiB
- File system volumes estimated as an even share of their file system
Off-hours schedules
Dev and test namespaces that sleep at night
Namespaces in dev, test and QA clusters that cost $200 a month or more get an off-hours proposal: scaled down outside 07:00 to 20:00 on weekdays. The saving is estimated on the 103 hours a week they would be idle.
- kube-downscaler annotations, ready to commit
- Only non-production environments
- Up to 20 schedule proposals at a time, largest first
# Generated for dev-use2 / catalog ($1,410/month, dev environment)apiVersion: v1kind: Namespacemetadata: name: catalog annotations: downscaler/uptime: Mon-Fri 07:00-20:00 UTCWhere the Kubernetes savings are
off the monthly bill: $21,842 a month found at our sample company
Sample company, not a customer result
Savings rules
Every finding, with the rule behind it
Savings are monthly, recomputed every 30 minutes, and ranked high above $100 a month and medium above $10.
| Finding | Rule |
|---|---|
| Right-size container requests | p95 usage over 7 days, flagged under 30% of request, recommended max(p95 x 1.2, 0.025 cores / 0.25 GB) |
| Right-size node groups | Peak hourly requests over 14 days x 1.2; oversized when 40% or more of both CPU and memory is spare |
| Change node family | 50% or more of one resource spare; saving capped at the typical price gap of one family step |
| Abandoned workloads | CPU at or below 2% of request over 14 days; the whole cost counts as recoverable |
| Orphaned volumes | Still billing 24 hours or more after the PV disappeared, from a cluster that is still reporting |
| Released volumes | PV in Released, Available or Failed with a backing volume that still bills |
| Over-provisioned volumes | At least 24 hourly samples over 14 days; recommends max(peak x 1.5, 1 GiB) when 30% or more is reclaimable |
| Off-hours schedules | Dev, test and QA namespaces at $200 or more a month, scaled down outside weekday working hours |
| GPU | GPU nodes and GPU requests with low utilization, priced at the GPU node rate |
| Possible orphans | Billed every day for 7 days with no PV and no cluster tag; shown as an upper bound, kept out of the total |
Savings your engineers can check
Container rightsizing
CPU and memory requests from p95 usage with headroom.
Node sizing
Smaller nodes or a different family from peak requests.
Storage cleanup
Orphaned, released and oversized volumes, priced per month.
Off-hours schedules
Non-production namespaces scaled down at night and weekends.
GPU utilization
Idle and under-used GPU nodes priced at their real rate.
Proposals for every finding
Each saving becomes a reviewable change with a patch.
Savings: your questions answered
KubeOn
Keep exploring
Evaluate savings with your team
Bring your platform and FinOps priorities. We will walk through the data, controls and evidence for your evaluation.