Skip to content
Cloud guide

Cloud Cost Optimization: A FinOps Playbook

A step-by-step approach to cutting cloud waste — rightsizing, savings plans, storage tiering and the FinOps culture that makes savings stick.

Server racks and network cabling in a cloud data center
Radiatus at a glance
  • Since 2021Independent studio
  • 31 servicesAcross 5 practices
  • 13 productsBuilt & run in-house
  • 24/7Managed support
On this page

Cloud bills rarely balloon because of one bad decision. They creep — an oversized instance here, a forgotten test environment there, storage that never gets tiered, a NAT gateway quietly moving terabytes. FinOps is the practice of bringing engineering, finance and product together so those costs stay visible, accountable and continuously optimised. This is the playbook we use when we run a cost review as part of our cloud & infrastructure work.

1. Get visibility before you cut anything

You can't optimise what you can't see. Before touching a single instance, make sure every euro, dollar or rupee of spend can be traced to an owner.

  • Tag everything with at least owner, environment, service and cost-centre, and enforce tags in your infrastructure-as-code and with tag policies so new resources can't be created untagged.
  • Turn on the native cost data: AWS Cost and Usage Reports (CUR), Azure Cost Management exports and Google Cloud billing export to BigQuery. These are the raw material for every later decision.
  • Report spend by team and service, not just by account. Untagged or "shared" spend is usually where the waste hides, so track how much of the bill is unattributed and drive it down.

If you run more than one cloud, a single view matters. We built CloudMonitor for exactly this: one dashboard for AWS, Azure and GCP spend, inventory and waste detection, with anomaly alerts when a service suddenly costs more than it did yesterday.

2. Remove the obvious waste

The first pass is housekeeping, and it is low risk because nothing in production changes:

  • Delete unattached volumes, old snapshots and AMIs/images nobody references
  • Release idle elastic/static IPs and remove load balancers with no healthy targets
  • Put non-production environments on a schedule — off at night and at weekends
  • Set retention on logs and metrics; "keep forever" is a cost decision, not a default
  • Check data-transfer lines: cross-AZ chatter, NAT gateway processing and internet egress are frequent surprises

3. Rightsize relentlessly

Look at actual CPU, memory and network utilisation over a representative window (at least a couple of weeks, covering month-end or seasonal peaks), not at peak-of-peak. Instances that idle most of the day are the easiest win. AWS Compute Optimizer, Azure Advisor and Google Cloud's recommender all produce rightsizing suggestions — treat them as a starting list, then validate against your own performance tests.

Rightsizing is also a chance to modernise: newer instance generations and ARM-based families (such as AWS Graviton) often deliver better price-performance, provided your software and dependencies support the architecture. Make rightsizing a recurring review, not an annual clean-up.

4. Commit only to your reliable baseline

For steady-state workloads, commitment discounts are the biggest single lever: AWS Savings Plans and Reserved Instances, Azure Reservations and Savings Plans, and Google Cloud committed use discounts. AWS, for example, advertises savings of up to 72% versus On-Demand for Savings Plans; the discount you actually get depends on term length, payment option and how flexible the commitment is.

The rule is simple: commit to the floor, not the average. Cover the usage you are confident will still exist for the whole term, keep the variable top layer on-demand, and run fault-tolerant work on spot or preemptible capacity. Rightsize before you commit, or you lock in waste for one to three years.

5. Tier your storage

Not all data needs hot, instantly accessible storage. Lifecycle policies that move ageing objects to infrequent-access and archive tiers (S3 Standard-IA / Glacier classes, Azure Cool/Cold/Archive, GCS Nearline/Coldline/Archive) can cut storage costs substantially with no application changes. Two cautions: archive tiers charge for retrieval and have minimum storage durations, and very small objects can cost more to transition than they save. Model the access pattern first — or use intelligent-tiering where the provider offers it.

6. Make savings stick with culture

The tooling is the easy part. Durable savings come from three habits:

  • Showback: every team sees a cost dashboard for the services it owns, refreshed daily.
  • Budgets and anomaly alerts that reach the owning team, not just finance.
  • Unit economics: cost per customer, per transaction or per environment, reviewed in the same meeting as reliability and delivery metrics.

Once cost is a quality attribute alongside latency and uptime, engineers make better trade-offs without being told. If you run Kubernetes, the same principles apply inside the cluster — see our guide to Kubernetes cost control.

The goal of FinOps isn't the lowest possible bill — it's the highest possible value per unit of spend, decided by the people who own the workloads.

Where to start this week

  1. Export last month's bill and find the ten most expensive services and the share that is untagged.
  2. Schedule non-production environments off outside working hours.
  3. Pull the provider's rightsizing recommendations and validate the top five.
  4. Only then look at commitments, sized to your post-rightsizing baseline.

If your cloud bill has outgrown your ability to explain it, a focused cost review is usually the fastest way back to control. Our managed IT services team can run these reviews on a cadence, and our DevOps & automation engineers can bake tagging, schedules and budgets into your Terraform so the savings don't drift back.

Written by the Radiatus engineering team. Questions or corrections? Email us.

Want help putting this into practice?

Talk to a senior engineer about your specific situation — no sales script.

Talk to an Engineer