The structural problem that tooling cannot fix
At AIG, working across a large-scale on-premise to Azure migration, the cost conversation was happening in two separate rooms. Engineers were making infrastructure decisions based on architecture requirements. Finance was reviewing the bill at month end. Nobody was in the room where both conversations happened at the same time.
That is not an AIG problem. It is the default state of most cloud programmes. The engineer spinning up a three-AZ EKS cluster is doing the right thing technically. Resilience across availability zones is correct. The NAT gateway in each zone is correct. The cost of that decision lands on a report two weeks later, passes through three layers of review, and by the time anyone talks to the engineer the architecture has been running a month and changing it requires a project board and a change request.
Apptio, CloudHealth, AWS Cost Explorer, Spot.io. All useful. None of them change who made the deployment decision or whether that person ever sees the consequence of it. FinOps tooling solves the visibility problem. The accountability problem is organisational, and it requires a different kind of fix.
The security architect in the room nobody invites to FinOps
There is a conversation that almost never happens between security teams and whoever owns cloud cost management. Security controls are a significant and consistently underestimated driver of cloud spend. The controls are correct. The cost implications are rarely surfaced explicitly at the point the architecture decision is made.
Here is what that looks like in practice across a typical multi-region AWS environment.
| Control | Why it exists | Cost reality |
|---|---|---|
| VPC endpoints | Prevents data exfiltration via public AWS APIs. Keeps traffic off the internet entirely. | ~$440/mo (10 services, 3 AZ, 2 regions) before data processing |
| NAT gateways per AZ | Eliminates single-AZ failure as a network path dependency. | ~$192/mo base, plus $0.045 per GB processed |
| GuardDuty all accounts | No account is a blind spot for threat detection. | $1 per million events. Large estate: tens of millions monthly. |
| CloudTrail all regions | No region is a logging gap, even quiet ones. | $2 per 100k events. 10 quiet regions still accumulate. |
| Secrets Manager all credentials | Stops secrets sprawl in environment variables and code. | $0.40 per secret per month. 500 secrets adds up quietly. |
None of these controls should necessarily be removed. The point is that each one represents a decision with both a security rationale and a cost consequence, and someone with authority to make trade-offs needs to own that explicitly. In most organisations, security says the control is required and finance reports the cost. Nobody sits at the intersection of both and has the authority to resolve the tension.
Building that room, where security, engineering, and finance review cost decisions together, is the precondition for effective FinOps. The technology is a secondary concern.
Four maturity stages, described honestly
The FinOps Foundation describes a Crawl, Walk, Run progression. It is a reasonable framework. What it underplays is what it actually takes to move between levels, because each transition requires something different from the organisation, not just a new tool or process.
Commitment purchasing: the decision that causes the most regret
Reserved Instances and Savings Plans are the most impactful single lever in cloud cost reduction for stable workloads. They are also where I have seen the most expensive procurement mistakes. The pattern is consistent: committing to a three-year term based on current usage without modelling what happens when the architecture changes.
Compute Savings Plans are the more forgiving option. They apply automatically across EC2 instance families, Fargate, and Lambda. A one-year Compute Savings Plan at a conservative commitment level captures meaningful savings without locking you to a specific instance type that may be superseded or migrated away from in eighteen months.
EC2 Reserved Instances offer deeper discounts but require commitment to a specific instance family in a specific region. They make sense for genuinely stable baseline workloads: a production database cluster, a fixed-size worker pool for a predictable batch process. They do not make sense for application tiers that are actively being re-architected or migrated to containers.
Where security architecture creates FinOps debt
Two patterns create long-term cost problems that are genuinely difficult to unwind once they are in place.
The first is over-segmentation of networking. Putting every environment and every application in its own VPC with its own NAT gateway and its own Transit Gateway attachment is a defensible security decision. At scale, an organisation with fifty accounts, three environments each, three NAT gateways each, is paying over fourteen thousand pounds per month before any data processing costs. A centralised networking model with shared Transit Gateway and VPC endpoints for AWS services achieves equivalent segmentation at significantly lower cost. Most organisations build the distributed model first because it is conceptually simpler, and then find themselves redesigning networking under cost pressure two years later rather than as a planned activity.
The second is maximum-retention logging across all services. CloudTrail in all regions, VPC Flow Logs at full resolution, GuardDuty findings to S3, WAF logs, ALB access logs. The security rationale is sound: you do not know which logs you will need until you need them. The cost reality for a high-traffic environment is tens of thousands of pounds per year in storage and processing alone. Tiered storage with Intelligent-Tiering, enforced retention policies, and selective Flow Log filtering for high-volume sources are all mechanisms to contain this without creating investigation blind spots.
Three actions that have disproportionate impact
If you are trying to start a FinOps practice in an organisation that does not have one, three actions consistently deliver results relative to their effort cost.
Enforce tagging at provisioning time via SCP or Azure Policy. Not a policy document. Actual enforcement that prevents resource creation without required tags. Half a day to implement. Every cost conversation that follows becomes immediately more productive because the data has an owner.
Identify the top five cost drivers and find the person who made the deployment decision for each one. Give that person a monthly cost report for that specific resource. One direct conversation between a cost report and the person who made the decision is worth more than six months of dashboard access at the organisational level.
Run a Trusted Advisor or Compute Optimizer review and action the recommendations with a defined turnaround time. The recommendations are not always right. Reviewing them forces a decision: either justify the current configuration or change it. Both outcomes are useful.