FinOps savings aren't where you think.
The compute fallacy
Open ten FinOps decks at random. Eight will lead with right-sizing EC2 or VM instances. It is the cleanest story to tell: we measure CPU, we recommend a smaller box, we save 12 percent on the line item.
On the bills we audit, EC2 is rarely the largest waste pool. It is the most visible one. Engineers like working on it. The savings are real but capped. Spend a quarter on right-sizing and you might claw back 8 percent of the bill. Spend the same quarter on the three line items below and the number is two to three times that.
The first pile: cross-region and cross-AZ data transfer
Networking is invisible. Every architecture diagram glosses over the lines between boxes. The bill does not. On AWS, data transfer can be 12 to 18 percent of the total bill on a multi-AZ, multi-VPC topology. On Azure, the equivalent is bandwidth and ExpressRoute charges. On both, most of the spend is for traffic the team never intended.
The pattern: a service in account A makes a database call to account B. The call routes through a NAT gateway because that's how the original landing zone was built. Six months later, a logging pipeline copies the same data across regions for compliance reasons no one remembers. None of it is wrong. All of it adds up.
The fix is architectural, not commercial. VPC endpoints, PrivateLink, intra-AZ placement of co-located services. The savings show up the same week we deploy the change.
The second pile: storage that the team forgot existed
Snapshots, old backups, AMIs, EBS volumes that were detached during an incident and never reattached. Logs that ship to S3 with a thirty-day lifecycle policy that was never written.
On a typical mid-market estate we find storage waste in the range of 6 to 14 percent of the bill. The fix is mechanical: lifecycle policies, retention review, snapshot rotation. The reason it stays unfixed is that no one owns it. The platform team thinks the application teams will tag. The application teams think the platform team has a default policy. Both teams are wrong. Until the bill has an owner, the waste stays.
"Right-sizing compute is the second sprint, not the first. The first sprint is networking and storage and managed-service inventory."
Danny Zak / FinOps Lead
The third pile: idle managed services
Managed databases that ran in a non-production environment three years ago, with multi-AZ enabled because that was the template. RDS replicas no one queries. ElastiCache clusters provisioned for a launch that did not happen. Snowflake warehouses left running. OpenSearch domains for a feature that shipped and was deprecated.
The cost is small per service. The count is large. A bill we audited recently had 47 RDS instances of which 12 had zero connections for 90 days. Total monthly waste: about €11,000. The team did not know they were running.
The fix is inventory plus policy. Every managed service gets an owner tag. Every untagged or zero-traffic service triggers a review after 30 days. Nine out of ten flagged services get deprovisioned. The tenth turns out to have a reason; that's fine.
What this means for the FinOps roadmap
Right-sizing compute is the second sprint, not the first. The first sprint is networking and storage and managed-service inventory. The numbers are bigger, the politics are smaller (no one defends untagged storage), and the changes ship without engineer time.
The second sprint can then be right-sizing, with a budget and a measurement plan. By that point the team has trust in the FinOps practice, because the bill has already dropped by 20 percent or more from the boring changes.
The savings story most consultancies tell is the wrong story because the easy answer (right-size EC2) is the visible answer. The honest answer is more boring. The honest answer pays better.