The Azure Cost Optimization Playbook: A FinOps Starting Point

Most cost optimization advice fails for the same reason most diets fail: it treats the symptom instead of the system. Someone sees a scary number on the bill, turns something off, feels good for a month, and then the spend creeps right back because nothing about how decisions get made actually changed.

This post is the starting point for a short series that takes a different angle. Instead of a list of switches to flip, it's a way of thinking — the FinOps cycle of Inform, Optimize, Operate — applied to the three Azure workloads I get asked about most: Microsoft Fabric, Azure AI Foundry, and Azure Storage at scale. The goal isn't the lowest possible bill. It's the right bill: the one where you're hitting your performance targets and not paying for anything you don't need to.

Current as of July 2026. Azure pricing, SKUs, and reservation terms change constantly. Every specific number in this series comes from Microsoft's own documentation and is used the way the docs use it — as an illustration of the mechanics, not a quote of today's price. Always confirm current rates in the Azure Pricing Calculator before you commit money.

The mental model: performance and cost are the same conversation

The single most common mistake I see is treating cost optimization as a cleanup task that happens after the architecture is built. By then most of your spend is already locked in. The blob is in the wrong tier, the capacity is oversized, the model deployment is provisioned when it should be pay-as-you-go — and now you're refactoring instead of designing.

Here's the model in simplified terms. Every Azure service gives you a set of dials. Some dials trade cost for performance (bigger SKU, dedicated capacity, hotter storage tier). Some trade cost for convenience (managed tiering, autoscale, reservations you don't have to think about). FinOps isn't about turning every dial to "cheap." It's about knowing which dial does what, and setting each one deliberately for the workload in front of you.

That's why this series is organized around a cycle rather than a checklist. You don't optimize once. You inform yourself, you make changes, you operationalize the good habits, and then you come back around as the workload evolves.

The FinOps cycle, in one table

If you've read the Azure FinOps framework post, this will be familiar. If not, here's the whole idea in one place. Microsoft maps its Cloud Adoption Framework FinOps guidance onto the same three phases the FinOps Foundation defines:

Phase	The question it answers	What it looks like on Azure
Inform	Where is the money going, and why?	Tagging, Microsoft Cost Management, budgets and alerts, cost allocation, showback/chargeback, anomaly detection
Optimize	What should we change?	Right-sizing, tier and SKU selection, commitment discounts, pausing idle resources, architectural changes
Operate	How do we keep it that way?	Governance policies, automation, recurring reviews, Azure Advisor recommendations, embedding cost into engineering decisions

Every recommendation in the deep-dive posts slots into one of these three phases. That's deliberate. When you can name which phase a change belongs to, you stop making one-off fixes and start building a practice.

Inform: you can't optimize what you can't see

This is the phase everyone wants to skip, and it's the one that pays off the most. Before you touch a single SKU:

Tag everything. Environment, team, workload, cost center. Tags are how a raw invoice becomes a story about who is spending on what. Enforce them with Azure Policy so they can't be skipped. I go deeper on this in the governance and tagging fundamentals post.
Set budgets with alerts in Cost Management — not because the budget stops spend (it doesn't), but because the alert changes behavior the moment a workload drifts.
Turn on cost anomaly detection. It's free, it's built in, and it catches the accidental left-a-thing-running spend that reservations and tiering can't.
Give engineers the dashboard. The team building on a service should see what it costs in near-real-time. Visibility changes behavior faster than any policy.

If you do nothing else from this post, do this. Everything downstream depends on it.

Optimize: the levers, from most to least obvious

The deep-dive posts are almost entirely about this phase. But the levers rhyme across every service, so here's the shared vocabulary:

Right-size before you discount. A reservation on an oversized resource just locks in waste for one to three years. Get the size right first, then buy the commitment. This order matters more than any single setting.
Pause or delete what's idle. Fabric capacities pause. AI Foundry deployments bill by the minute. Dev and test resources rarely need to run overnight. Idle time is the easiest money you'll ever save.
Match the pricing model to the traffic pattern. Steady, predictable load wants committed/provisioned pricing. Spiky, unpredictable load wants pay-as-you-go. The expensive mistake is using one where you need the other.
Commit to what you know you'll use. Reservations, savings plans, and Azure Hybrid Benefit deliver the biggest single discounts on Azure — often 30–60% — but only on the baseline you're confident about.
Chase the little charges. Transactions, data retrieval, egress, geo-replication, early-deletion fees. Individually tiny, collectively a huge line item at scale. The Storage post is largely about these.

The deep dives

This is where it gets specific. Each post below is a standalone starting point for a new user of that service — how to configure it to hit your performance goals while balancing cost — but they all share the Inform/Optimize/Operate spine.

🟦 Cost-Optimizing Microsoft Fabric

Fabric bills on capacity units, and the levers are unlike anything else on Azure: smoothing, bursting, throttling, surge protection, pause/resume, and capacity reservations. If you're standing up your first F SKU, start here to avoid the two classic mistakes — oversizing "to be safe" and leaving dev capacities running 24/7.

🟩 Cost-Optimizing Azure AI Foundry

Foundry's cost model is a fork in the road: pay-as-you-go tokens versus provisioned throughput units (PTUs). Pick wrong and you either throttle in production or pay for idle capacity. This post covers deployment types, PTU reservations, batch, prompt caching, and the model router — and it pairs with Why AI Cost Optimization Is Different from Traditional FinOps, which explains why the AI terrain breaks the usual rules.

🟨 Cost-Optimizing Azure Storage: Reservations, Tiers, and the Charges That Add Up

Storage looks cheap per gigabyte, which is exactly why it quietly becomes one of your biggest bills. This one goes deep on access tiers, lifecycle management, the reserved-capacity break-even math for the TB-to-PB range, and every one of the "little charges" — transactions, retrieval, geo-replication, egress, early-deletion penalties — that never show up in a per-GB estimate.

Operate: making it stick

Optimization that isn't operationalized decays. The spend creeps back the moment attention moves on. To keep the gains:

Automate the recurring stuff. Scheduled Fabric resizes, storage lifecycle policies, and reservation-coverage reports should run on their own. Manual optimization is a task you'll eventually forget.
Review reservation and savings-plan coverage monthly. Under-coverage leaves discounts on the table; over-coverage locks in waste. It moves as your baseline moves.
Act on Azure Advisor. Its cost recommendations surface idle and underused resources automatically. It's the closest thing to a free FinOps analyst you have.
Put cost in the definition of done. The biggest wins come from influencing the architecture before it ships — the right tier, the right capacity, the right pricing model chosen up front. That's a culture change, not a config change, and it's the whole point of the Operate phase.

To Sum it up

Cost optimization on Azure isn't a spreadsheet exercise you do once a quarter when the bill spikes. It's a loop: Inform yourself with tags and dashboards, Optimize by matching every dial to the workload, and Operate by automating and reviewing so the gains hold. Performance and cost aren't opposing forces — they're the same set of decisions, made deliberately instead of by default.

Start with whichever deep dive matches what you're building. If you're standing up analytics, go to Fabric. If you're deploying models, go to Foundry. If your data estate is heading from terabytes toward petabytes, go to Storage. Wherever you start, the framework is the same — and that's what makes it stick.

References

Related posts in this series: Microsoft Fabric · Azure AI Foundry · Azure Storage · Foundation reading: Azure FinOps Framework · Cost Commitments · FinOps for AI