FinOps Inform
Cloud best practices: the FinOps playbook for UK CTOs
Discover cloud best practices in our FinOps playbook for UK CTOs. Optimize costs, enhance accountability, and boost deployment speed today!
Embedding FinOps into engineering workflows is a highly effective approach to cloud cost optimisation, significantly reducing spend while preserving deployment velocity, as explained in this digital transformation in operations guide. The savings are rarely in the obvious places. They are buried in how software was built, how resources were provisioned, and how nobody was made accountable for the bill. Koritsu AI's agent Kori, drawing on analysis from Askan Technologies and Thoughtworks, has identified the highest-leverage steps below.
- Make cost visible at the point of decision: PRs, CI pipelines, and design reviews, not monthly finance reports.
- Assign team ownership with mandatory tagging before any other optimisation work begins.
- Remove idle and orphaned resources first. That alone typically recovers 30โ40% of wasted spend, based on industry analysis of idle and overprovisioned cloud resources.
- Rightsize before buying committed discounts. Committing to the wrong baseline locks in overspend.
- Automate non-production shutdowns. Scheduling alone can cut non-production compute costs by around 70%, especially in development and test environments.
What can you do in the next 30 days?
The fastest wins require no architectural changes. Delegate these to your platform engineering team and measure results against your billing baseline.
- Enable account-level billing visibility across AWS Cost Explorer, Azure Cost Management, or Google Cloud Billing and share read access with engineering leads.
- Implement mandatory resource tags: team, service, environment, and cost centre. Block untagged deployments via policy-as-code from day one.
- Schedule non-production instance shutdowns outside working hours. This is low-risk and can deliver immediate savings of about 70% on non-production compute costs.
- Audit and delete orphaned resources: unattached volumes, unused load balancers, idle NAT gateways, and forgotten snapshots.
- Run provider-native rightsizing recommendations (AWS Compute Optimiser, Azure Advisor, GCP Recommender) and action the top ten findings.
Pro Tip: Set up auto-stop rules for development instances using native scheduler services or infrastructure-as-code lifecycle hooks. Pair this with snapshot lifecycle policies to avoid storage accumulating silently. The effort is under a day; the saving is immediate and recurring.
Watch for one risk: scheduling shutdowns without communicating to engineers causes friction. Announce changes, document the schedule in your internal developer platform, and provide a self-service override for genuine out-of-hours work.
How do you put cost visibility into engineers' daily tools?
Integrating cost signals into the tools engineers already use is more effective than any periodic finance report. The reason is simple: by the time a monthly report lands, the architectural decision that caused the spike has already been merged, deployed, and forgotten.
The practical implementation looks like this. Add Infracost to your pull request pipeline so engineers see a cost delta before they merge infrastructure changes. Surface showback data in your internal developer platform so teams can see their spend without navigating billing consoles. Add a cost field to your Architecture Decision Records so cost is a first-class consideration at design time, not an afterthought.
Thoughtworks frames this as part of engineering effectiveness: reporting, recommendations, and remediation should be integrated into the delivery lifecycle. When cost data lives next to latency and error rates in the same dashboard, engineers treat it as an engineering metric rather than a finance problem.
Pro Tip: Add unit cost metrics, cost per transaction or cost per active user, to your observability dashboards alongside latency and error budgets. When an engineer can see that a query change reduced cost per transaction by 15%, optimisation becomes intrinsically motivating rather than externally mandated.
For reducing costs in CI/CD pipelines, pre-merge cost gates are the most reliable control. Set a threshold, say a 10% cost increase on a single PR, that triggers a mandatory review before merge.
Core FinOps governance: tagging, allocation, and guardrails
GOV.UK guidance and Askan Technologies both identify mandatory tagging as the foundational practice. Without it, you cannot allocate costs to teams, features, or environments reliably, and every other optimisation effort produces numbers nobody trusts.
The minimum tag taxonomy for a mid-market UK organisation:
team: the engineering squad or domain responsible for the resourceservice: the product or platform componentenvironment: production, staging, development, or sandboxcost-centre: the finance code for chargeback or showback
Once tags are in place, the governance layer follows a clear sequence:
- Enforce tags via policy-as-code (AWS Service Control Policies, Azure Policy, or GCP Organisation Policies). Block deployment of untagged resources automatically.
- Set budget alerts at 80% and 90% of monthly targets per team. Alerts go to the team lead and the FinOps champion, not only to finance.
- Define anomaly playbooks: who investigates, within what timeframe, and what the escalation path is if spend cannot be explained within 24 hours.
- Assign a FinOps champion per engineering domain. This person owns the monthly cost retro for their area, not the CFO.
Finance sets the guardrails and the budget envelopes. Engineering owns the day-to-day decisions within them. That separation is what makes the model scale without creating approval bottlenecks.
Which technical levers move the needle most?
Prioritise by effort-to-saving ratio. The sequence that works in practice:
- Idle resource removal: zero architectural change, immediate saving.
- Instance scheduling: low effort, high recurring impact, especially for non-prod.
- Rightsizing: use provider recommenders, then validate against actual utilisation data over a 14-day window before acting.
- Spot and preemptible instances: suitable for fault-tolerant batch workloads, CI runners, and stateless services. Not appropriate for stateful production databases.
- Alternative CPU families: ARM-based instances can deliver around 40% better price-performance for compatible workloads. Graviton on AWS is the most mature option; validate compatibility before migrating.
- Storage lifecycle policies: move infrequently accessed data to cold storage tiers automatically. Most organisations leave this unmanaged.
At the application layer, caching, query optimisation, and replacing expensive recurring queries with materialised views often deliver savings that infrastructure changes cannot. A query running every 30 seconds against a large dataset costs more than the instance it runs on.
Pro Tip: Always rightsize before purchasing Savings Plans or Reserved Instances. Committing to the current baseline locks in the waste. Rightsize first, establish the new steady-state over 30 days, then buy commitments against that lower baseline.
How do you measure savings and prove ROI to the board?
Establish a billing baseline before any optimisation work begins. Without it, you cannot prove what changed or by how much. Three KPIs cover most reporting needs:
- Team spend: total cloud cost per squad per month, tracked against budget.
- Unit cost: cost per transaction, per active user, or per API call, depending on your product model.
- Budget burn rate: percentage of monthly budget consumed at each point in the month, used to forecast overruns before they happen.
Typical waste across organisations comes from idle or overprovisioned resources. FinOps programmes that address this systematically can substantially reduce total cloud costs. These are reasonable figures to consider when setting board expectations.
For continuous monitoring, ingest billing data daily at minimum, hourly where your provider supports it. Anomaly alerts should fire when spend deviates more than 20% from the rolling seven-day average for any tagged service. The response playbook: identify the resource within two hours, contain or terminate within 24 hours, and document the root cause for the monthly retro.
Reporting cadence: daily dashboards for engineering teams, a weekly FinOps review with engineering leads, and a monthly CFO report showing actuals versus baseline, unit cost trend, and forecast for the remainder of the quarter.
A practical 0โ12 month roadmap
| Phase | Weeks | Lead owner | Key deliverables | Expected saving |
|---|---|---|---|---|
| Visibility and tagging | 1โ4 | Platform engineering | Billing access, tag taxonomy, baseline established | 0% (foundation) |
| Quick wins and budgets | 1โ12 | Platform engineering + FinOps champion | Scheduling, orphan cleanup, budget alerts live | 10โ20% |
| Rightsizing and commitments | 12โ24 | Lead engineers per domain | Rightsizing complete, Savings Plans purchased | Additional 15% |
| Automation and architecture | 24 | Engineering leads + architects | Spot adoption, storage tiering, unit cost instrumentation | Additional 10โ30% |
Common pitfalls: tag drift (enforce via policy, not convention), overstated forecasts (use conservative ranges with the board), and over-committing before rightsizing is complete. The FinOps Foundation's inform, optimise, operate model maps directly onto these phases. Move to the next phase only when the current one has measurable, stable outputs.
Continuous monitoring, anomaly detection, and cost allocation
Cost allocation only works when tagging is enforced and billing data is ingested continuously. Allocate costs to teams and services first, then to features or business capabilities as your model matures. Showback, showing teams their costs without charging them back, is the right starting point for most organisations. Chargeback, where teams are financially accountable, requires mature tagging and a trusted baseline before it is credible.
Anomaly detection should operate at the service level, not the account level. An account-level alert that fires when total spend rises 15% is too coarse to be useful. A service-level alert that fires when a specific tagged workload doubles overnight is actionable within minutes. For cloud observability and cost, integrating cost anomaly signals into the same alerting channel as infrastructure alerts means engineers respond to cost events with the same urgency as availability events.
When should you use committed or reserved discounts?
Committed discounts, Savings Plans on AWS, Reserved Instances, Azure Reserved VM Instances, and GCP Committed Use Discounts, deliver meaningful rate reductions on predictable workloads. The decision criteria are straightforward: commit only to resources you are confident will run at that scale for the commitment period.
One-year commitments are appropriate for stable production workloads with at least 90 days of consistent utilisation data. Three-year commitments suit core infrastructure that is unlikely to change significantly. Never commit to a resource type you are actively rightsizing or planning to migrate. The saving from a commitment is worthless if the underlying resource is overprovisioned.
Compute Savings Plans on AWS offer the most flexibility: they apply across instance families, sizes, and regions. Start there before moving to more specific Reserved Instance purchases.
Building a FinOps culture across engineering teams
Cloud cost is not a technology problem. It is a process problem, and process problems require cultural change. The FinOps culture guide for engineering teams identifies three conditions that make the shift stick: cost data must be visible to engineers, engineers must have the authority to act on it, and the organisation must celebrate cost improvements alongside feature delivery.
Monthly cost retros per engineering domain are more effective than quarterly all-hands reviews. Keep them short: 20 minutes, focused on the top three cost movements, one owner per action. Finance attends as an observer, not a chair.
Cross-team collaboration works best when a FinOps champion sits within each engineering domain rather than in a central team. Central FinOps teams become bottlenecks. Embedded champions become advocates.
UK compliance and regulatory considerations
UK organisations running production workloads on AWS, Azure, or GCP face several compliance requirements that directly affect cost architecture. Data residency obligations under UK GDPR require that personal data processed in the UK remains within approved jurisdictions. Storing data in cheaper regions outside the UK or EEA may violate these obligations, so cost decisions about storage location must be reviewed against your data classification policy.
The Financial Conduct Authority's operational resilience rules, which apply to regulated financial services firms, require demonstrable recovery capabilities. Multi-region architectures built for resilience carry higher baseline costs; these cannot simply be removed as a cost-saving measure without a formal risk assessment.
HMRC's Making Tax Digital programme and broader public sector cloud frameworks (including Crown Commercial Service agreements) also influence procurement and cost governance for public sector-adjacent organisations. Ensure your cost allocation model maps to the cost categories your auditors and regulators expect to see.
Koritsu AI: verified savings, no upfront cost
Most cloud cost programmes stall because the analysis never translates into engineering action. Koritsu AI closes that gap. The AI agent Kori continuously monitors your AWS, Azure, or GCP billing, surfaces anomalies and rightsizing opportunities in real time, and produces engineering-grade savings reports your teams can act on directly, not slide decks for a steering committee.
The engagement model is built around results. You start with a free cloud cost assessment, and Koritsu AI charges only on realised savings verified against your billing data. No upfront retainer, no speculative forecasts. From there, an ongoing FinOps-as-a-service subscription keeps Kori monitoring continuously and gives your teams access to expert support when architectural decisions get complex.
If you are a CTO or finance lead at a UK organisation spending materially on cloud and you have not yet established a billing baseline, that is where to start. Request a free assessment and Koritsu AI will identify where the spend is going and what can be recovered.
Key takeaways
Embedding cost ownership into engineering workflows, not delegating it to finance, is what separates organisations that sustain cloud savings from those that recover ground and then lose it again.
| Point | Details |
|---|---|
| Visibility before optimisation | Establish a billing baseline and mandatory tagging before any rightsizing or commitment purchases. |
| Rightsize before committing | Run provider recommenders, validate over 14 days, then buy Savings Plans against the new baseline. |
| Automate non-prod shutdowns | Scheduling alone can cut non-production compute costs significantly. |
| Embed cost in engineering tools | Add cost deltas to PRs and unit cost metrics to observability dashboards so engineers act at the point of decision. |
| Koritsu AI for verified delivery | Koritsu AI's success-fee model means you pay only on savings confirmed against your billing data, starting with a free assessment. |
The gap between knowing and doing
The technical knowledge required to cut cloud spend by 30โ45% is not scarce. Every major cloud provider publishes rightsizing recommendations. The FinOps Foundation has documented the operating model in detail. Thoughtworks and Askan Technologies have published the engineering culture playbook. What is scarce is the organisational will to make cost a first-class engineering metric and the execution capacity to act on findings before the next sprint starts.
The organisations that close that gap share one characteristic: they treat cloud cost as an engineering problem with a measurable outcome, not a finance report with a complaints column. Unit cost per transaction sits next to p99 latency on the dashboard. Anomaly alerts go to the on-call engineer, not the finance inbox. The FinOps champion is a senior engineer, not an analyst.
Koritsu AI's approach is built on that premise. Kori surfaces findings in the language engineers understand, and the success-fee model means the incentive is always aligned with delivery, not analysis.
Useful sources
- Managing your spending in the cloud, GOV.UK: UK government guidance on cloud cost governance, tagging, and accountability frameworks.
- Cost-Aware Engineering: How to Build FinOps Culture Inside Engineering Teams, Askan Technologies: Practical guidance on embedding cost visibility into CI/CD, PRs, and observability workflows.
- FinOps for engineering teams: making developers cost-conscious without slowing innovation, Askan Technologies: Source for the 30โ45% savings range and the 30โ40% waste figures used in this guide.
- Driving engineering effectiveness through FinOps principles, Thoughtworks: Thoughtworks' case for integrating FinOps into engineering effectiveness and the delivery lifecycle.
- Cloud cost optimisation: save 40% on your AWS/Azure/GCP bill, Citadel Cloud Management: Source for ARM/Graviton price-performance data and the FinOps Foundation three-phase model.
- FinOps as a Service, Koritsu AI: Koritsu AI's success-fee engagement model and ongoing platform subscription options.
- Cloud FinOps framework benefits: a practitioner's guide, Koritsu Blog: Framework for rolling out FinOps governance at scale across engineering domains.