How to Cut Cloud Spend 30% Without Touching Your Architecture

The average enterprise overspends on cloud by 30–40%. Not because engineers are wasteful, but because the visibility tools that would surface waste do not exist, or the team is too busy shipping features to look. FinOps — cloud financial operations — is the discipline that closes this gap. And it does not require a single line of architecture change to deliver the first 20–30% of savings.

This is a practical breakdown of the interventions we use across AWS, Azure, and GCP that move the needle fastest — ranked by impact and effort.

1. Right-sizing: the highest-ROI intervention

Most cloud workloads run on compute instances that were sized for peak load — or for a peak load that never came — and were never revisited. In practice, the average EC2 instance, Azure VM, or GCP Compute Engine node runs at 15–25% average CPU utilisation. Dropping from a 16-core instance to an 8-core instance on an underutilised service cuts that line item in half with zero code change.

The challenge is visibility: without tagging discipline, you cannot see which instances belong to which service, which team, or which environment. The first step in any right-sizing programme is enforcing tagging policies — owner, environment, service, cost centre — so that recommendations can be routed to the right team and tracked to completion.

Tools: AWS Compute Optimizer, Azure Advisor, GCP Recommender all surface right-sizing recommendations automatically. The limiting factor is never the tool — it is the process for acting on recommendations without requiring engineers to pick up each one manually.

2. Reserved capacity and savings plans

On-demand pricing is the most expensive way to run stable workloads. For any workload that runs continuously — production databases, core API services, data pipelines — committing to one-year or three-year reserved capacity cuts costs by 30–72% versus on-demand, depending on the cloud and instance type.

The risk most teams want to avoid is over-committing to capacity they do not use. The FinOps answer is a coverage model: buy reservations to cover your stable baseline, pay on-demand for variable headroom. AWS Savings Plans and Azure Reserved Instances apply automatically across matching usage, which makes them more flexible than the instance-specific reservations of earlier years.

For teams running LLM workloads, GPU reserved capacity deserves separate attention. A reserved A100 or H100 instance on AWS or Azure can be 60% cheaper than on-demand — significant when inference costs represent a growing share of total cloud spend.

3. Idle and zombie resource cleanup

Every cloud environment accumulates resources that were created for a sprint, a demo, or a proof of concept, and were never deleted. Unattached EBS volumes, idle load balancers, unused Elastic IPs, forgotten dev environments that run 24/7 — each line item is small. In aggregate, they typically represent 8–15% of a mature environment's monthly bill.

Automated cleanup policies — tagging resources with a TTL, flagging anything that has had zero traffic for 30 days, and routing those findings to a team-specific Slack channel — are more effective than periodic manual audits. The key is making the default action “delete unless opted out,” not “keep unless someone complains.”

4. Storage tier optimisation

Data grows monotonically and cloud storage pricing is tiered. Most teams put everything in the highest-performance tier and never move it. S3 Intelligent-Tiering, Azure Blob lifecycle policies, and GCP Object Lifecycle Management can automatically migrate objects to cheaper tiers based on access patterns — without any application change.

For data warehouses: partitioning and clustering on Snowflake, BigQuery, or Redshift can reduce query costs by 50–80% by limiting the data scanned per query. This is not an architecture change — it is a configuration change that pays for itself in the first billing cycle.

5. Showback and chargeback for engineering accountability

The structural reason cloud spend grows unchecked is that the people making spending decisions — engineers choosing instance sizes, standing up environments, running experiments — are not the people receiving the bill. Showback closes this gap: give every team a real-time view of their cloud spend, tagged to their services and environments.

Chargeback goes further by allocating actual costs to team budgets. Both approaches require tagging discipline and a cost visibility platform, but the behavioural change they drive — engineers who think about cost as a first-class metric alongside latency and reliability — delivers compounding savings over time.

FinOps for AI workloads

LLM inference costs are becoming a significant line item for organisations running AI in production. The FinOps principles apply directly: right-size your model to the task (GPT-4o for complex reasoning, a smaller model for classification), implement prompt and context optimisation to reduce token usage, cache repeated completions, and route traffic to the most cost-effective model per request type.

SST's LLMInsight platform provides exactly this visibility for AI spend — real-time tracking across providers, model comparison, and routing recommendations. Paired with our cloud FinOps programmes, most clients see 20–40% reduction in total cloud and AI spend within the first 90 days.

If you want to understand where your cloud budget is actually going, talk to our FinOps team.

Related: Multi-Cloud Migration & FinOps

SST delivers FinOps programmes that cut cloud spend 20–40% across AWS, Azure, and GCP — without slowing engineering.