If you want durable cloud cost cuts, stop chasing one-off savings and build a FinOps operating model: give every dollar an owner, make spend visible in near real time, and turn optimization into a repeatable engineering practice rather than a quarterly fire drill. That is the short answer. The longer answer, which I will walk through for both AWS and Google Kubernetes Engine (GKE), is a practical framework you can start applying this week.
I have seen teams shave 20 to 40 percent off a bloated cloud bill without a single migration, purely by fixing visibility, rightsizing, and commitment coverage. None of it requires heroics. It requires discipline and a few well-placed automations.
Why Cloud Bills Grow Faster Than Anyone Expects
Cloud spend rarely explodes for one dramatic reason. It grows through accumulation:
- Idle non-production environments running 24/7.
- Over-provisioned instances chosen by guessing rather than measuring.
- Storage snapshots and orphaned volumes nobody deletes.
- On-demand pricing on steady-state workloads that should be committed.
- Kubernetes requests set far above actual usage, so nodes scale for reservations that are never consumed.
The core problem is accountability decay. Engineers provision resources fast, but no feedback loop ties that decision to a cost. FinOps closes that loop.
The FinOps Framework in Three Phases
The FinOps Foundation describes a lifecycle of Inform, Optimize, and Operate (FinOps Foundation). I use those phases as the backbone of every engagement because they map cleanly to how engineering teams actually work.
Phase 1: Inform (make spend visible and attributable)
You cannot cut what you cannot see. Before touching a single instance, get allocation right.
On AWS, enforce a tagging policy and activate cost allocation tags. A minimal standard I recommend:
owner(team or individual)environment(prod, staging, dev)service(the application or component)cost-center
Enforce tags at creation time with a Service Control Policy or an Infrastructure as Code check. Here is a Terraform pattern that fails the plan if required tags are missing:
variable "required_tags" {
type = list(string)
default = ["owner", "environment", "service", "cost-center"]
}
resource "aws_instance" "app" {
ami = var.ami_id
instance_type = "m6i.large"
tags = {
owner = "platform-team"
environment = "prod"
service = "checkout-api"
cost-center = "eng-1042"
}
lifecycle {
precondition {
condition = alltrue([for t in var.required_tags : contains(keys(self.tags), t)])
error_message = "All required cost allocation tags must be set."
}
}
}
On GKE, use namespaces and labels as your allocation dimension, then enable GKE cost allocation so spend flows into BigQuery billing export by namespace and label. Standardize on labels like team, env, and app in every deployment manifest.
The deliverable for this phase is a shared dashboard showing spend by team and environment, refreshed daily. When people see their own numbers, behavior changes before you optimize anything.
Phase 2: Optimize (rightsize, schedule, and commit)
With visibility in place, attack cost in this order. I sequence it deliberately: eliminate waste first, then optimize what remains, then commit to what is stable.
1. Delete waste. Orphaned resources are pure loss.
# AWS: find unattached EBS volumes
aws ec2 describe-volumes \
--filters Name=status,Values=available \
--query "Volumes[].{ID:VolumeId,Size:Size,AZ:AvailabilityZone}" \
--output table
# AWS: find old snapshots owned by your account
aws ec2 describe-snapshots --owner-ids self \
--query "Snapshots[?StartTime<='2024-01-01'].[SnapshotId,VolumeSize,StartTime]" \
--output table
Schedule non-production shutdowns. A dev fleet that runs 12 hours a day, 5 days a week instead of 24/7 costs roughly a quarter as much. On AWS use Instance Scheduler or a simple EventBridge rule; on GKE scale node pools to zero off-hours.
2. Rightsize based on measured usage. For EC2, pull utilization from CloudWatch or Compute Optimizer. The pattern is: if p95 CPU and memory sit well below the instance capacity for two weeks, drop a size.
For GKE, the biggest lever is aligning requests with real consumption. Kubernetes schedules on requests, so inflated requests force the cluster autoscaler to add nodes you are paying for but not using. Use the Vertical Pod Autoscaler in recommendation mode to see the gap:
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: checkout-api-vpa
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: checkout-api
updatePolicy:
updateMode: "Off" # recommendation only, no auto-eviction
Then compare kubectl describe vpa checkout-api-vpa recommendations against your manifest and adjust. Pair this with the Horizontal Pod Autoscaler for load-driven scaling and the Cluster Autoscaler so nodes track demand.
3. Commit to stable baseline. Once workloads are lean, cover predictable usage with discounts.
- AWS: Compute Savings Plans give flexibility across instance families and regions. Start conservative. Cover your steady baseline (often 60 to 80 percent of usage) and leave headroom on-demand.
- GKE: use Committed Use Discounts for baseline vCPU and memory, and Spot VMs for fault-tolerant, stateless, or batch workloads. Spot can cut node cost dramatically, but only put interruptible work there.
A quick rule I apply: never buy commitments on top of un-rightsized infrastructure. You will lock in the waste.
Phase 3: Operate (make it continuous)
One-time cleanup regresses within a quarter. The Operate phase wires FinOps into your normal engineering rhythm.
- Budgets and alerts. Set AWS Budgets and GCP Budget alerts per team with anomaly detection on top.
- Cost in code review. Tools that estimate the cost delta of a Terraform change put the number in front of the engineer before merge.
- A monthly review. Bring engineering, finance, and product together. Look at unit cost (cost per request, per tenant, per transaction), not just total spend. Unit economics is where cloud spend reduction becomes a business conversation.
- Showback or chargeback. Even showback, simply reporting each team's spend, drives accountability without the accounting overhead of full chargeback.
A Concrete 30-Day Plan for Cloud Cost Cuts
If you need a starting sequence, here is what I would do in the first month:
- Week 1: Turn on Cost Explorer / billing export, enforce the tagging standard, and stand up a shared dashboard.
- Week 2: Delete orphaned volumes, snapshots, and idle load balancers. Schedule non-prod shutdowns.
- Week 3: Run Compute Optimizer and VPA recommendations. Rightsize the top 10 spenders.
- Week 4: Model commitment coverage on the now-leaner baseline. Purchase conservative Savings Plans or CUDs. Set budgets and alerts.
By day 30 you will have both a measurable reduction and, more importantly, the machinery to keep it down.
AWS and GKE: Where the Levers Differ
The FinOps principles are identical across clouds, but the mechanics differ enough to matter.
| Lever | AWS cost optimization | GKE cost management |
|---|---|---|
| Allocation | Cost allocation tags | Namespace/label cost allocation |
| Rightsizing | Compute Optimizer | Vertical Pod Autoscaler |
| Autoscaling | Auto Scaling Groups | HPA + Cluster Autoscaler |
| Commitments | Savings Plans / Reserved Instances | Committed Use Discounts |
| Cheap capacity | Spot Instances | Spot VMs |
For Kubernetes specifically, the request-versus-usage gap is usually the single largest source of hidden spend. Two of every three clusters I audit are provisioning nodes for CPU and memory reservations that pods never touch. Fixing that alone often funds the rest of the program.
This kind of platform work sits at the center of what our team does across our cloud and infrastructure capabilities, and the specifics shift by sector. Regulated workloads in the industries we support often carry data residency and retention constraints that change which optimization levers are safe to pull, so context matters.
Common Mistakes That Undermine Savings
- Optimizing before measuring. You will rightsize the wrong things.
- Buying commitments too aggressively. A three-year commit on a workload you are about to refactor is a trap.
- Setting VPA to auto-evict in production without testing. Recommendation mode first.
- Treating FinOps as a finance-only initiative. Engineers make the decisions that create cost, so they must own the loop.
Cut waste, measure before you optimize, and make the practice continuous. That is how cloud cost cuts stick instead of bouncing back next quarter.
FAQ
How much can a FinOps framework realistically save?
It depends entirely on your starting maturity. Teams with no tagging, no scheduling, and pure on-demand pricing typically find the largest gains from waste elimination and commitment coverage. Teams already running autoscaling and commitments see smaller but steadier improvements from unit-cost tuning. Measure your own baseline rather than relying on a headline percentage.
What is the difference between AWS Savings Plans and Reserved Instances?
Reserved Instances commit you to a specific instance configuration in exchange for a discount, while Compute Savings Plans commit you to a dollar-per-hour spend level and apply across instance families, sizes, and regions. Savings Plans offer more flexibility, which is why I usually recommend them for evolving workloads. Reserved Instances can still make sense for very stable, unchanging footprints.
Why is Kubernetes so hard to cost-optimize?
Because cost is driven by node capacity, but scheduling is driven by pod requests, not actual usage. If teams over-request CPU and memory, the cluster autoscaler adds nodes to satisfy reservations that are never consumed. Aligning requests with measured usage using the Vertical Pod Autoscaler is the highest-leverage fix in most GKE environments.
Should I use Spot instances for production workloads?
Spot Instances and Spot VMs can be interrupted with little notice, so they suit stateless, fault-tolerant, or batch workloads that tolerate disruption. For stateful or latency-critical production services, keep them on on-demand or committed capacity. Many teams run a hybrid: a committed baseline plus Spot for elastic, interruptible work.
Who should own FinOps in an engineering organization?
Ownership is shared. Finance provides budgets and reporting cadence, but engineers make the provisioning decisions that create cost, so they must own optimization within their services. A small central platform or FinOps function sets standards, builds dashboards, and manages commitments, while individual teams stay accountable for their own spend.
