Cloud Cost Optimization: 15 Leaks You Can Fix This Month

Quickstart

If you only have an hour, start here. These steps prioritize “low-risk, high-confidence” savings: things that are obviously unused, obviously oversized, or missing guardrails.

Overview

“Cloud spend” feels mysterious when it arrives as a single monthly invoice. Cloud cost optimization becomes straightforward once you split costs into drivers (compute, storage, network, managed services) and ownership (teams/services/environments). This post gives you a month-long plan and a list of 15 common leaks you can fix with minimal drama.

Core concepts

FinOps: the “operating system” for cloud spend

FinOps is simply the collaboration layer between engineering, finance, and product that turns cloud bills into actionable signals. You don’t need a big program to start—you need clear ownership, good data (tags), and a habit of making tradeoffs visible.

The four cost drivers

Unit economics: the metric that stops arguments

“We spent $X” is rarely useful on its own. Better: cost per unit (per request, per user, per job, per GB processed). Unit economics helps you decide whether to optimize, refactor, or accept spend as the price of growth.

Tags and allocation: you can’t fix what you can’t attribute

If you can’t map spend to a team/service/environment, optimization becomes guesswork. The simplest tagging strategy that works at scale is:

• team: who owns the resource
• service: what system it belongs to
• env: prod / staging / dev
• cost-center (optional): how finance groups it

Risk-managed optimization

The most expensive cloud cost project is the one that causes downtime. Favor changes that are: reversible (easy rollback), measurable (you can see impact), and scoped (limited blast radius).

Step-by-step

This is a practical month plan for cloud cost optimization. You can run it with a small team and basic access to your billing data, cloud inventory, and metrics.

Week 1 — Visibility and guardrails

Week 2 — Delete and downgrade (low-risk savings)

The goal is to find things that are provably unused or over-retained. This week is where most teams get quick wins without changing application code.

#!/usr/bin/env bash
set -euo pipefail

# Quick AWS inventory for common cost leaks (read-only).
# Requirements: aws CLI configured. Optional: jq for nicer output.
# Tip: start in non-prod accounts/projects.

echo "== Stopped EC2 instances (still pay for attached storage/EIPs) =="
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=stopped" \
  --query "Reservations[].Instances[].[InstanceId,InstanceType,State.Name,Tags]" \
  --output table || true

echo "== Unattached EBS volumes (often pure waste) =="
aws ec2 describe-volumes \
  --filters "Name=status,Values=available" \
  --query "Volumes[].[VolumeId,Size,VolumeType,CreateTime,Tags]" \
  --output table || true

echo "== Elastic IPs not associated (hourly cost) =="
aws ec2 describe-addresses \
  --query "Addresses[?AssociationId==null].[PublicIp,AllocationId,Tags]" \
  --output table || true

echo "== Load balancers with no targets (common zombie) =="
# You may have ALB/NLB/CLB; start with target groups for ALB/NLB:
aws elbv2 describe-target-groups \
  --query "TargetGroups[].TargetGroupArn" --output text 2>/dev/null | while read -r arn; do
    count="$(aws elbv2 describe-target-health --target-group-arn "$arn" \
      --query "length(TargetHealthDescriptions)" --output text 2>/dev/null || echo 0)"
    if [[ "$count" == "0" ]]; then
      echo "Empty target group: $arn"
    fi
  done

echo "Done. Review candidates with owners before cleanup."

Week 3 — Right-sizing (where big savings often live)

Right-sizing means aligning capacity with actual usage. The trap is right-sizing based on a single “quiet day.” Use 14–30 days of metrics, and always keep a safety margin for spikes.

#!/usr/bin/env python3
import csv
import sys
from collections import defaultdict

# Usage:
#   python3 cost_report.py billing.csv
#
# Expected columns (rename to match your export):
#   - service: e.g., "Compute Engine", "EC2", "S3"
#   - cost: numeric (monthly or daily)
#   - team: optional tag/label (empty means "unallocated")

path = sys.argv[1] if len(sys.argv) > 1 else None
if not path:
  print("Usage: python3 cost_report.py <billing.csv>", file=sys.stderr)
  sys.exit(2)

by_service = defaultdict(float)
by_team = defaultdict(float)
unallocated = 0.0
total = 0.0

with open(path, newline="") as f:
  reader = csv.DictReader(f)
  for row in reader:
    try:
      cost = float(row.get("cost", "0") or 0)
    except ValueError:
      continue

    service = (row.get("service") or "unknown").strip() or "unknown"
    team = (row.get("team") or "").strip()

    total += cost
    by_service[service] += cost
    if team:
      by_team[team] += cost
    else:
      unallocated += cost

def top(d, n=10):
  return sorted(d.items(), key=lambda kv: kv[1], reverse=True)[:n]

print("== Top services ==")
for svc, c in top(by_service, 10):
  print(f"{svc:30s} {c:12.2f}")

print("\n== Top teams (allocated) ==")
for team, c in top(by_team, 10):
  print(f"{team:30s} {c:12.2f}")

print("\n== Allocation ==")
pct_unalloc = (unallocated / total * 100.0) if total > 0 else 0.0
print(f"Total cost:        {total:.2f}")
print(f"Unallocated cost:  {unallocated:.2f} ({pct_unalloc:.1f}%)")

if pct_unalloc > 10.0:
  print("\nTip: Add/standardize tags (team/service/env). Unallocated spend hides the biggest leaks.")

Week 4 — Commitments, scheduling, and “keep it fixed” automation

Once your baseline is reasonable, you can safely apply longer-term optimizations: reserved capacity / savings plans / committed use, autoscaling and schedules, and policy enforcement so old problems don’t creep back.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.2.3
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "200m"
              memory: "256Mi"
            limits:
              cpu: "1000m"
              memory: "512Mi"
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Common mistakes

Most cost optimization efforts fail for predictable reasons: they optimize the wrong thing, break something, or don’t stick. Here are the pitfalls to avoid (and what to do instead).

FAQ

What is cloud cost optimization, in practical terms?

Cloud cost optimization is the discipline of reducing waste while keeping reliability and performance intact. Practically, it means deleting unused resources, right-sizing what remains, using the right storage tiers and retention, managing data transfer, and adding guardrails so leaks don’t reappear.

Where do most teams find the first meaningful savings?

Usually in idle resources (stopped instances, unattached volumes, unused IPs/load balancers), over-retained data (logs/snapshots/artifacts), and overprovisioned compute. These are measurable and typically low-risk when handled with ownership and rollback plans.

How do we right-size safely without causing outages?

Use 14–30 days of metrics, size to p95 (not average), keep headroom, and make changes in small steps. Validate with user-facing signals (latency/error rate) and always document a rollback path.

Should we focus on reserved instances / savings plans / committed use?

Yes, but after you fix the baseline. Commitments amplify whatever baseline you have: if it’s oversized, you lock in waste. Start conservative on steady-state capacity, prefer flexible commitments when uncertain, and revisit monthly.

How important are tags for cost optimization?

Tags (or labels) are foundational. Without allocation, you can’t answer “who owns this spend,” and optimization becomes slow and political. Aim to reduce “unallocated” spend steadily and enforce tagging on new resources.

What are the biggest “hidden” cloud cost drivers?

Data transfer/egress, NAT gateway processing, managed database replicas and provisioned IOPS, log ingestion and retention, and Kubernetes request inflation are common surprises. The fix is usually visibility (dashboards/alerts) plus a small design change (routing, caching, autoscaling, retention).

How often should we review cloud spend?

At least monthly for a comprehensive review, with weekly checks for anomalies in high-spend environments. A lightweight cadence that works: weekly “top anomalies” plus a monthly “top services + top teams + unallocated spend” review.

Cheatsheet

Use this for a monthly cloud cost optimization review. It’s intentionally compact: the goal is to spot the biggest leaks fast and assign owners.

Wrap-up

Cloud cost optimization doesn’t require a massive rewrite. In your first month, you can save real money by fixing the obvious leaks: delete unused resources, reduce retention, right-size the biggest workloads, make egress visible, and enforce ownership with tags. The lasting payoff comes from guardrails that prevent regressions.

If you want to make these changes safer and more repeatable, pair cost work with infrastructure-as-code and runbooks. The related posts below cover Terraform pitfalls, CI/CD patterns, and Kubernetes basics that help keep cost changes controlled.

Related posts

• Terraform Mistakes: State, Modules, and the ‘One Big Plan’ Trap
• Serverless Done Right: When Functions Beat Containers
• Cloud Networking Basics: VPCs, Subnets, NAT, and Security Groups
• Docker for Developers: Images, Layers, and Caching Explained
• Kubernetes Without Tears: Pods, Services, Ingress in One Story
• CI/CD That Stays Green: Pipeline Patterns That Scale