FinOps: Cutting Cloud Costs 20 to 40 Percent Without Slowing Delivery

Cloud spend has a habit of growing faster than the business. Environments are created for a project and never deleted, instances are sized for a peak that never arrives, and data transfer charges hide in line items nobody reads. Add AI workloads with expensive GPUs and per-token API costs, and finance teams start asking hard questions.

In our cost optimisation engagements, reductions in the range of 20 to 40 percent are common when an organisation has not previously run a structured programme, though the exact figure depends heavily on the starting point. The key is doing it without turning engineering into a ticket queue for finance. FinOps, the practice of bringing financial accountability to variable cloud spend, is how. Here is the approach we use.

Visibility first: you cannot optimise what you cannot see

The FinOps Foundation describes the practice in three phases: inform, optimise and operate. Inform comes first for good reason. Start by getting billing data from every provider into one place, ideally normalised to the FOCUS specification, the open standard for cloud cost and usage data that the major providers now support. Then build views that answer the questions people actually ask: what does each product, team and environment cost, and how is that trending?

Unit economics make the numbers meaningful. Total spend going up can be good news if the business grew faster. Track cost per customer, per transaction or per thousand API calls, and you have a metric that engineers and executives can both reason about.

Add anomaly detection early. All three major providers offer native cost anomaly alerts, and routing them to the owning team in the chat tools they already use catches runaway resources within a day instead of at month end. Pair this with forecasts so finance sees expected spend before the invoice arrives, which builds the trust that keeps FinOps a partnership rather than a policing exercise.

Tagging and allocation that actually works

Allocation depends on tagging, and tagging depends on enforcement. Agree a small, mandatory set of tags and enforce them in infrastructure as code and through cloud policies, rather than asking people to remember. Untagged resources should fail a pipeline check or be flagged automatically, not discovered in a quarterly review.

Shared costs such as networking, observability platforms and Kubernetes clusters need an agreed allocation method. For containers, tools like OpenCost or Kubecost can attribute cluster costs to namespaces and workloads. The goal is showback first, so teams can see their spend, and chargeback later if the organisation wants it.

• owner: the accountable team, not an individual.
• product or cost centre: what the spend supports.
• environment: production, staging, development or sandbox.
• lifecycle or expiry date for temporary resources.

Quick wins: waste removal and rightsizing

The first savings usually come from eliminating waste. Idle and orphaned resources are everywhere: unattached volumes, old snapshots, forgotten load balancers, unused IP addresses and test environments running around the clock. Scheduling non-production environments to shut down outside working hours is one of the simplest high-impact changes.

Rightsizing comes next. Use actual utilisation data over several weeks to downsize over-provisioned instances, databases and containers. Move to newer instance generations, which typically offer better price-performance, and evaluate ARM-based options such as AWS Graviton where your software supports it. Review storage tiers and lifecycle policies, since large volumes of rarely accessed data often sit in the most expensive tier.

• Delete unattached volumes, stale snapshots and idle load balancers.
• Schedule development and staging environments to stop outside working hours.
• Rightsize compute and databases based on observed utilisation.
• Apply storage lifecycle rules to move cold data to cheaper tiers.
• Review data transfer paths, including cross-zone and egress traffic.

Commitments and pricing models

Once the footprint is rightsized, commit to the stable baseline. AWS Savings Plans and Reserved Instances, Azure reservations and savings plans, and Google Cloud committed use discounts all trade a usage commitment for significantly lower rates. Commit after rightsizing, not before, or you lock in waste. Start with a conservative coverage target for steady workloads, then increase it as confidence grows, and review utilisation monthly.

For interruptible work such as batch processing, CI runners and some data pipelines, spot or preemptible capacity offers deep discounts in exchange for the possibility of interruption. The engineering work of making workloads tolerate that is usually worth it.

Architecture: the largest and most durable savings

The biggest long-term savings come from design decisions. Autoscaling that actually scales down, serverless for spiky low-volume workloads, caching to reduce database load, and choosing managed services where they are cheaper than self-operated equivalents all change the cost curve permanently. Chatty microservices that move data across zones or regions can generate surprisingly large network bills.

Build cost into the engineering workflow. Showing the estimated cost impact of infrastructure changes in pull requests, with tools that analyse Terraform plans, makes cost a design consideration rather than an after-the-fact surprise.

AI and GPU costs: the new frontier

AI workloads introduce two new cost profiles. Self-hosted models and training runs need GPUs, which are expensive and often left idle between jobs. Scheduling, sharing GPUs across workloads, choosing the smallest instance that meets latency needs, and using spot capacity for training where checkpointing allows all help. API-based models are billed per token, so costs scale with prompt length and traffic.

For API usage, the levers are routing simpler requests to smaller, cheaper models, using prompt caching where the provider supports it, trimming retrieved context, using batch processing for non-urgent jobs, and tracking cost per feature or per user. Put budgets and alerts on AI spend from day one; it can grow very quickly once a feature is popular.

Culture: making cost everyone's job

Tools find savings; culture keeps them. Give each engineering team visibility of its own spend and unit costs, set budgets with anomaly alerts, and review cost alongside reliability and performance in regular engineering rituals. Celebrate savings the same way you celebrate shipped features. A small central FinOps function can own tooling, commitments and reporting, while product teams own decisions about their own workloads. That balance is what lets costs fall while delivery speed stays the same.

A practical cadence helps. Hold a short monthly cost review per product, with the top movers, anomalies and open optimisation actions, and a quarterly review of commitments and architecture. Keep a shared backlog of savings opportunities with estimated value and effort, so teams can pick them up alongside feature work instead of in panicked clean-up sprints.