How WALT Labs Approaches FinOps: A Practitioner's Methodology

The WALT Labs FinOps methodology is not just a dashboard; it is a dedicated operating discipline where the dashboard is merely the byproduct.

For many organizations, cloud spend feels like a runaway train. The transition from legacy data centers to the cloud shifted purchasing power from procurement teams straight to the engineering floor. While this accelerated innovation, it also bypassed traditional financial controls.

At WALT Labs, we run FinOps as a continuous engineering practice — not a quarterly review, not a finance ticket queue, and not a vendor procurement exercise. This post lays out the methodology we apply on Google Cloud engagements, in the exact same language we use internally.

The cultural shift: Bridging finance and engineering

Before diving into the mechanics, we must address the human element. The core friction in cloud financial management is often a mistranslation.

Finance speaks in annual budgets, forecasts, and capitalization. Engineering speaks in deployments, latency, and scalability. A successful FinOps methodology acts as the universal translator between these two worlds.

It enables finance to understand the business value of a spike in compute costs, while empowering engineers to treat cost as a first-class metric alongside performance and reliability. Without this cultural alignment, any tooling you deploy will ultimately be ignored.

The three principles that govern everything

Before implementing any framework, three foundational principles set the bar:

1. Engineers own the spend they create. Finance reports it, platform teams instrument it, but the team that ships the workload owns the bill it produces.
2. Decisions need a unit cost. "Our bill went up" is not actionable. "Cost per processed event went up 12%" is. Tying dollars to business value changes the conversation.
3. Optimization is a habit, not a project. A one-time savings sprint depreciates within two quarters. A weekly cadence compounds and drives lasting efficiency.

The four phases of our FinOps engagements

1. Inform — make the invisible visible

Most cloud bills are unreadable because they describe infrastructure, not products. The first phase rebuilds visibility from the workload down:

• A strategic use of Google Cloud labels for billing attribution and Resource Manager Tags for governance, aligned to products, teams, and environments — not org charts that change every six months.
• Allocation rules for shared services (networking, observability, security) so no cost goes "homeless."
• Anomaly baselines per workload, not per project, so a 5x spike in a small service is not buried under noise from a large one.
• Showback before chargeback. This ensures teams can see their financial impact and build trust in the data before strict budget accountability kicks in.

Output: Every dollar on the bill maps to a product owner, a team, and an environment. If it does not, we do not move to phase two.

2. Optimize — pull the right levers in the right order

Optimization must be sequenced. We work top-down because architectural decisions completely dwarf rate-card decisions:

1. Architectural fit. Is this workload on the right service in the first place? A VM doing the job of a managed serverless function is the most expensive line item we ever see.
2. Right-sizing and autoscaling. We look at resource shape and elasticity policies before any commitment discussion. We frequently utilize Compute Engine custom machine types to match exact workload profiles.
3. Storage class and data lifecycle. Hot data belongs on hot storage, cold data on cold storage, and deleted data should be actually deleted. Implementing automated lifecycle policies ensures logs efficiently age out to Coldline or Archive storage.
4. Commitments and discounts. Committed Use Discounts (CUDs) and negotiated discounts come last — never first. A discount on the wrong architecture is a multi-year mistake.

3. Operate — build the cadence

This is where most FinOps programs quietly die. The fix is a rigorous, fixed cadence with named owners:

• Weekly: Anomaly triage. This is a 30-minute, engineering-led meeting with no slides. For example, quickly identifying an orphaned test cluster left running over the weekend and terminating it.
• Monthly: Unit-cost review per product. Did the cost-per-unit improve, hold, or regress? What caused the shift?
• Quarterly: Commitment ladder review and architectural debt assessment.

If the cadence cannot survive a busy quarter, the cadence is wrong. We design it to fit seamlessly inside existing engineering rituals, not on top of them.

4. Govern — make the right thing the easy thing

Modern governance is not a gatekeeper. It is about paving the road so developers can move fast safely:

• Cost-aware defaults baked into your infrastructure-as-code (IaC) templates.
• Integration of cost estimation tools directly into CI/CD pipelines. This "shift-left" approach catches expensive misconfigurations during the pull-request phase.
• Budget guardrails with automated alerts at thresholds that actually matter, not at the budget line itself (because by then it is too late).
• A properly documented exception path. In real engineering, exceptions exist, and pretending otherwise just trains teams to route around the system.

Where Cloud Companion fits

Cloud Companion serves as the system of record for this entire methodology. It is not a magical swap-in for the operating discipline — it is the layer that makes the discipline cheap and easy to run:

• Continuous Cloud Billing export to BigQuery ensures the Inform phase is always live, rather than reconstructed manually at month's end.
• Smart anomaly detection is automatically scoped to workloads and unit costs, cutting through the noise of raw line items.
• Security, access, and compliance posture sit in the exact same plane as cost. A misconfigured resource often shows up first as an unexplained bill.
• AI-assisted triage summarizes root causes instantly, turning a weekly anomaly review from an hour of detective work into ten minutes of decisive action.

The tool exists in service of the practice. We have never seen the inverse work.

What we do not do

We believe in subtraction just as much as addition. Here are a few anti-patterns we actively push back on:

• Single-number scorecards. Focusing on total cloud spend reduction as the only KPI rewards starvation, not efficiency. Unit cost is the only metric that wins.
• Finance-owned FinOps. Finance is a highly critical stakeholder, but they cannot be the operating owner. Engineering must drive.
• Tool-first programs. Buying a flashy dashboard before defining the cadence produces a beautifully visualized failure.
• Discount-first programs. Locking in commitments on an incorrectly shaped workload is an unforced error you will pay for over the next three years.

How to start

If you are starting from scratch, the first 30 days are not about saving money. They are about answering one distinct question with absolute confidence: can you, today, attribute every single dollar on last month's bill to a product, a team, and an environment?

If the answer is no, that is phase one. Everything else compounds effortlessly from there.

Want to apply this FinOps methodology directly against your environment? Get started with WALT Labs or explore Cloud Companion.