FinOps for multi-cloud teams: a 2025 playbook

Multi-cloud is now the default posture for any team of meaningful size: AWS for the data plane, GCP for analytics, Azure for the corporate identity layer. But the FinOps practices that worked when one cloud owned 80% of the bill quietly break down at the seams. The native cloud cost signal on each platform speaks a different dialect, the reservation math has nothing to do with the next platform's savings plans, and the audit trail your finance team wants is nowhere to be found. This playbook is here to make multi-cloud cost operating work the way it should — continuously, defensibly, and without one rogue NAT gateway quietly burning eighteen thousand dollars a month while finance waits on the quarterly invoice. It distils what an hourly FinOps loop actually does, how the four major levers (rightsizing, idle hygiene, reservations, savings plans) compose across AWS, GCP and Azure, and how to keep a cost allocation map that survives SOC 2 (https://www.aicpa-cima.com/topic/assurance-services/soc-2) or EU CSRD (https://www.efrag.org/csrd) evidence requests without bolting on a new tool. Why multi-cloud FinOps is harder than single-cloud FinOps Three forces turn "list of recommendations + monthly report" into something that is genuinely useful again only when it runs every hour, on every account, against the native cost signal each cloud already exposes: The dialects diverge. AWS Cost Explorer (https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html), Azure Cost Management (https://learn.microsoft.com/azure/cost-management-billing/costs/overview-cost-management) and Google Cloud's Active Assist (https://cloud.google.com/recommender/docs/active-assist/overview) each model utilization strictly differently and each recommends cost actions using a different taxonomy. A "rightsizing" recommendation in one platform is conceptually the same as a "machine type change" in another, but they show up as incomparable rows in a spreadsheet. The reservation math doesn't compose. AWS Savings Plans (https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html), Azure Reservations (https://learn.microsoft.com/azure/cost-management-billing/reservations/save-compute-costs-reservations) and Google Cloud Committed Use Discounts (https://cloud.google.com/docs/cuds) have nothing to do with each other. A reserved-instance pool on AWS cannot apply to a GCP analytics workload. A FinOps team running multi-cloud has to plan commitments per-cloud, balance the under-utilisation penalty separately on each, and surface a single shared view across the three commitment ledgers. Cost allocation drifts. Tags are the cleanest FinOps tool for cost allocation, and tags are also the worst-implemented concept in cloud governance. Tagging policies enforced 90% of the way produce allocation charts that are right to within ten percent on good days and forty percent on bad days. Multi-cloud multiplies the drift because each platform has its own tag inheritance model. A real FinOps loop has to address all three forces continuously. Quarterly optimisation batches are too slow — by the time the report lands, the workloads that drove the spike have rotated, and the next sprint's tag audit is already late. Theuer, an agent that runs 24/7 against the native cloud cost signal, scored recommendations before they reach the repo, and writes each saving back to a diff reviewable in pull request becomes more than a cost tool — it is the connective tissue between engineering, finance and platform teams. What "24/7" FinOps actually means "Continuous" FinOps is the phrase most teams reach for but few actually practice. The bar that the phrase implies is higher than most teams realise: Hourly inventory, not weekly. A week-old inventory of resources misses the new oversized instance spun up at 4pm Friday by a developer chasing a deadline. The cost allocation map must refresh every hour, against trailing usage, trailing spend and the native cloud cost signal each platform exposes natively. Scoring, not listing. A raw list of "rightsize this, stop that, delete the other" is not the deliverable — it is the noise that FinOps teams get burned on. Score each candidate against a threshold before it ever becomes a recommendation. The threshold has to be set in the language of finance (projected dollar saving) and platform (blast radius, rollback complexity), then honoured. Diffs that pass review. Every recommendation that survives the scoring filter has to land in an IaC pull request — Terraform (https://www.terraform.io/), Pulumi (https://www.pulumi.com/), Crossplane (https://www.crossplane.io/) — with the diff, the rollback command and the forecasted saving written into the description. Nothing reaches production without your existing review, policy and merge gates. Verified savings, not projected ones. A saving is only counted when, a week after the rightsizing change went live, the platform re-reads the workload, account and time window and confirms the bill actually dropped. Workloads that regressed are removed from the next invoice. This is the diff between "we think we saved $3,184/month" and "we verified $3,184/month". The agent model is the only one that holds all four bars at once. A human-run quarterly sprint optimises day five and then sleeps for seventy-five days; by then the drift is back. The agent model scales: every new account, every new region, every new workload is brought into the same loop the morning it appears. The four cost levers, in order When the FinOps agent crawls a multi-cloud estate, the actions it can take fall into four branches. The order matters — start with the smallest blast radius and lowest commitment first: Idle resource hygiene The highest-percentage-of-savings, lowest-risk pass is always the idle-resource audit: resources that are running but doing no useful work. A NAT gateway with no attached traffic, an EBS volume owned by a retired autoscaling group, a Cloud Pub/Sub topic that no service subscribes to, a Cosmos DB container that nobody queries — all of these are pure waste. The clean way to score idle candidates is to combine two signals: The cloud's native signal. AWS Config's compliance flags, Azure Advisor's "unused" recommendations, Active Assist's idle-resource flags. Each platform exposes a baseline; you do not have to recompute it. Trailing usage from the audit trail. A workload that ran a single daily batch job at midnight every day for the last thirty days is not "idle" by every useful definition — it is "scheduled". Use trailing-usage context before recommending deletion. Tallywyrm maintains a fallback rule: a resource is "idle" only when both signals agree within a trailing window. This dual-signal check is what keeps a multi-day batch processing pipeline from being deleted at 9am by an over-eager rightsizing pass. Rightsizing Once the idle pass is clean, the next branch is rightsizing — workloads that are running, doing real work, but on a flavor larger than they need. The agent scores these against trailing CPU, memory and network metrics, picks a target instance family that preserves the workload's tail-latency budget, and proposes a one-line change in the IaC repo. The two mistakes that teams make when they write a rightsizing loop themselves: Picking targets by average, not p95. The average CPU on a load-balanced stateless service tells you very little; the p95 latency under peak is what your SLO cares about. Always right-size against p95 plus a safety margin. Right-sizing against mean is how you produce a workload that catches on fire at 4pm on Black Friday. Ignoring the instance family. T3 → T4g on AWS Graviton (https://aws.amazon.com/ec2/graviton/) is usually a 20% additional saving on top of the rightsizing delta. It also requires re-architecting the AMIs. The rightsizing recommendation must always come paired with the family question — don't ship a rightsizing PR that handwaves the platform-specific implications. Reservations Once idle and oversize are clean, you have a stable baseline of compute usage that is genuinely required. That baseline is what you reserve against. The mistake teams make is buying reservations before the baseline is clean — at which point they're locked into a discount on a workload they could have deleted. Multi-cloud reservation strategy is not three independent commitments; it is one portfolio. The principles: Standardise the unit. Pick a single unit of compute-anchor (vCPU-hour, normalized across the three clouds via a single benchmark workload). Plan reservations against that unit. Cap the commitment. Anchor no more than sixty to seventy percent of baseline to reservations; the remainder goes to on-demand for elasticity. Anything more than that converts burst risk into reserved-capacity loss. Refresh against the audit trail. A reservation that has been under-utilised for a trailing 30 days is a candidate for re-sale or reduction; the agent should surface it. Likewise, a workload that has been on on-demand for a trailing 90 days at stable utilization is a reservation candidate. Savings plans Savings plans are the next-lever commitment after reservations, and they apply most cleanly to AWS Compute and GCP CUDs. They are usually a one to three year commitment paid monthly, with no per-resource management. The trap teams fall into is committing too early against a baseline that is still moving. Run reservations first, wait one quarter, then run savings plans against the post-reservation baseline. Cost allocation that survives an audit Multi-cloud cost allocation has two non-negotiable properties: Defensible to a dollar. Each line of the finance team's monthly cost dashboard ties to a specific resource ID, in a specific account, in a specific region, scoped under a specific IaC module. The auditor's question "what is this $4,200 line" gets answered with a PR, a deploy timestamp and a measurement timestamp — not a guess. Continuously reconciled. The allocation map is rebuilt every hour against the inventory, not reconciled quarterly at the end of the month. The end-of-quarter surprise ("we spent 17% more than we thought") is the failure mode this is here to prevent. The technical prerequisites for both properties to hold are: tag coverage enforced at the IaC layer (every resource must inherit tags from its module), a cost-allocation taxonomy owned by finance (not by engineering, not by platform), and a reconciliation job that joins tagged spend to the inventory every hour. Where teams get this wrong is treating tag coverage as a retrospective cleanup exercise. Tag coverage is a forward-looking infrastructure guarantee: if a resource is created without a tag, the IaC validator fails at PR time and the resource never reaches the cloud. The retrospective cleanup is then reading what already exists and fixing the drift. The audit-trail evidence your auditor will sign off on The six frameworks most multi-cloud teams have to align with in 2025 — SOC 2 Type II (https://www.aicpa-cima.com/topic/assurance-services/soc-2), ISO 27001 (https://www.iso.org/standard/27001), FedRAMP Moderate (https://www.fedramp.gov/), EU CSRD (https://www.efrag.org/csrd), SEC climate disclosure (https://www.sec.gov/spotlight/exchange-commission-delayed), GDPR (https://gdpr-info.eu/) — have distinct evidence formats, but they share a common requirement: each saving must be attributable end to end. Concretely, the audit trail is a CSV with a signed manifest mapping every row to: The resource (account / region / resource-id) The diff (IaC pull request URL, diff hunk) The PR lifecycle (reviewer, approver, merge timestamp) The deployment (deploy timestamp, deployer) The verification (trailing-usage re-read, before/after cost delta) The invoice entry (the row of the monthly invoice this saving landed on) The signed manifest is the artifact your auditor will sign off on. It is what makes a recommendation-grade saving into a finance-grade saving. The agent = the connective tissue The agent is not the "AI suggestion tool" FinOps teams have heard about for the last decade. It is a continuous loop that: Reconciles compute, storage and managed-service resources against trailing usage, trailing spend and the native cloud cost signal each platform exposes; Scores idle and oversized assets before they reach the repo; Opens one pull request per change through the existing IaC review pipeline; Re-reads the workload a week later and verifies the bill actually dropped; Writes the verification to the audit trail with the diff, the PR, the deploy and the measurement timestamp. The savings are real, attributable, and audited. That's the contract. The implementation detail doesn't matter — what matters is that the contract holds end to end, every hour, across every account. FAQs from FinOps leads A few questions that come up most often when teams are evaluating an agent model versus a quarterly human-sprint model: Doesn't an agent risk over-automating? The agent opens pull requests; it never merges. The reviewer, approver and merge decision are yours. The agent never holds a merge token, never holds a privileged account against your repos, and never bypasses a required approver. Risk management is preserved end to end. How is a "verified" saving verified? A saving is verified when the week after the rightsizing change went live, Tallywyrm re-reads the workload, the account and the time window, and confirms the bill actually dropped the forecasted amount. If the workload regressed, the saving is removed from the next invoice. Customers have used the same verification export for SOC 2 and EU CSRD evidence requests without modification. What data does the agent see? Read-only access to the accounts you grant, brokered through your existing OIDC trust wherever the cloud supports it. We refuse long-lived static access keys. The agent cannot write against billing APIs, identity providers, IAM policy, or any control-plane service. The credential grant is the smallest one that produces a useful saving. From playbook to implementation The single highest-leverage next step is to instrument the four cost levers above as concrete IaC modules your team can review. Once the modules exist — one for each cloud, callable from your existing Terraform / Pulumi / Crossplane repos — the agent has a stable surface to write changes against, and your team has a stable surface to review changes from. After that, the audit-trail evidence becomes a signed CSV exported weekly with a manifest mapping every row to its source PR and measurement. That CSV is what your SOC 2 auditor, your CSRD auditor and your finance team all sign off on without needing a separate evidence harvest. A 24/7 FinOps agent operating against a live multi-cloud estate, scoring against native cost signal and writing changes back as IaC pull requests, is the unit of work. The hour-by-hour loop is the deployment pattern. The audit trail is the artifact. The savings is the outcome. --- This guide is part of the Tallywyrm field guides series on FinOps practice for multi-cloud teams. For the deeper multi-cloud waste-audit play — the scoring thresholds, the audit-evidence map and the worked report — see the multi-cloud waste audit playbook (/blog/multi-cloud-waste-audit-playbook) (pillar 2). New pillars land as the practice evolves — start with the FAQ (/faq) for the security, credential scope and percentage-of-savings pricing questions, then talk to the team (mailto:tallywyrm@polsia.app) about a real audit on one of your own accounts.

FinOps for multi-cloud teams: a 2025 playbook

Send us your last month’s bill. We’ll show you what the agent finds.

Multi-cloud waste audit playbook: a hand-on-keyboard pass for AWS, GCP and Azure

AWS rightsizing with Terraform: a practical 2026 guide

Azure rightsizing with Terraform: a practical 2026 guide

FinOps for multi-cloud teams: a 2025 playbook

Send us your last month’s bill. We’ll show you what the agent finds.

Related posts

Multi-cloud waste audit playbook: a hand-on-keyboard pass for AWS, GCP and Azure

AWS rightsizing with Terraform: a practical 2026 guide

Azure rightsizing with Terraform: a practical 2026 guide