Allocation before rightsizing
Rightsizing without allocation creates a savings claim that can't be verified — you can't tell which team or project benefited, and you can't tell whether the resize regressed an important customer. Allocate first, then optimize.
Common rightsizing targets
Idle or under-utilized EC2/Compute instances, over-provisioned managed databases, Kubernetes node pools with low bin-packing efficiency, and stale EBS/Persistent Disk volumes attached to unused workloads.
Who tovin.io is for
Frequently asked
Should rightsizing be automated?
For Kubernetes node pools, yes (Karpenter, CAST AI). For RDS and managed databases, manual review with change windows is safer — automated downsizing of a primary database is a high-blast-radius action.
What about right-typing (instance family changes)?
Often higher savings than right-sizing alone (e.g. ARM-based Graviton vs x86). Same allocation-first rule applies — know which project benefits before changing the workload.