There's a pattern we see repeatedly when we engage with new clients. The finance team is concerned about an AWS bill that's growing faster than the business. Engineering say they're delivering value. Leadership aren't sure who to believe. And somewhere in the middle, tens of thousands of pounds are evaporating every month.
The instinct is usually to look at pricing — reserved instances, savings plans, spot capacity. These matter, but they're not the root cause. In our experience, cloud waste is primarily an ownership problem. Once you solve that, the savings follow.
Why FinOps Fails in Practice
Most FinOps programmes stall because they're treated as a finance initiative rather than an engineering one. The central cloud team produces a monthly cost report. That report gets circulated. Nobody acts on it. The cycle repeats.
The people who can change spending behaviour — engineers making architecture decisions — have no financial context when they make those decisions. They're optimising for reliability, speed, and simplicity. Cost is an afterthought. Effective FinOps bridges that gap.
Step 1: Establish Ownership Before Anything Else
The first question in any FinOps engagement isn't "how much are we spending?" It's "who is accountable for what?" Without clear ownership, cost visibility is just a list of numbers. With it, those numbers become actionable.
- Tag everything, consistently. Define a tagging standard that maps resources to teams, products, and cost centres. AWS Config rules and SCPs can enforce tags at deployment time — not just as a policy, but as a hard control.
- Build team-level cost dashboards. Aggregate spend by owner, not just by service. When a team can see their own bill — and that bill is visible to leadership — behaviour changes.
- Make cost a first-class engineering metric. Add spend to the same dashboards where teams track latency, error rates, and deployment frequency.
Step 2: Find the Waste Before Optimising
Before touching pricing constructs, find the resources that are costing you money for no return.
- Idle and oversized compute. EC2 instances running at 5% CPU utilisation, RDS databases with minimal connections. AWS Compute Optimizer provides right-sizing recommendations based on actual utilisation patterns.
- Data transfer charges. Traffic between Availability Zones, from EC2 to the internet, between regions — consistently underestimated and it adds up quickly.
- Forgotten resources. Orphaned EBS volumes, unattached Elastic IPs, unused snapshots and AMIs. Small individually, significant in aggregate.
- Development and test environments. Almost always the largest source of recoverable waste. Scheduled shutdown can reduce non-production spend by 60–70%.
Step 3: Structure Commitments Properly
Once you've eliminated waste, think about pricing optimisations — but not before. Buying reserved capacity for resources you're about to decommission is a common and expensive mistake.
Compute Savings Plans are more flexible than EC2 Reserved Instances and typically the right choice. A 70–80% coverage target for stable baseline compute, leaving 20–30% On-Demand for variable workloads, works well for most organisations. Analyse 13 months of usage before committing.
For RDS instances running continuously in production, a one-year Reserved Instance with partial upfront payment typically delivers 40% savings over On-Demand. Straightforward and low-risk.
Step 4: Architect for Cost from the Start
The highest-leverage FinOps work happens before a single line of infrastructure code is written. A few principles that make a material difference:
- Choose the right service tier. Don't default to EC2 when Lambda or Fargate is more appropriate for the usage pattern.
- Right-size from day one. Start smaller, validate with real load, scale if needed.
- Use caching aggressively. CloudFront, ElastiCache, and S3 reduce both latency and cost simultaneously.
- Design for multi-AZ with intent. Cross-AZ data transfer has a cost — make the resilience trade-off deliberately.
Step 5: Build the Operating Model
FinOps is not a one-off project. The value compounds when you build habits that keep cost discipline embedded in how teams work.
- Monthly cost reviews — structured, forward-looking, not a blame exercise.
- Cost anomaly detection — AWS Cost Anomaly Detection is a five-minute configuration that has saved clients from significant unexpected charges.
- FinOps champions in engineering teams — someone in each team who owns cost as part of their role.
- Chargeback or showback — making costs visible to the teams that incur them significantly changes decision-making behaviour.
What Good Looks Like
We've seen organisations reduce AWS spend by 30–50% within six months of implementing a structured FinOps programme — not through aggressive cuts, but through visibility, ownership, and eliminating waste that nobody knew existed.
The common thread isn't any particular tool or technique. It's that someone senior made cloud cost a priority, engineers were given the information and autonomy to act, and the process became part of how teams work rather than an annual audit.
How Kineticor Can Help
We work with UK enterprises to implement FinOps programmes that deliver measurable results. From initial cost assessments and tagging strategies to full AWS landing zone redesigns with cost governance built in, we bring the technical depth and practical experience to make the change stick.
If you'd like to understand where your AWS spend is going and what you can do about it, get in touch.