Azure FinOps Essentials

Hi there, and welcome to this week’s edition of Azure FinOps Essentials! 🎉

This week, I’m shifting the focus from tools and pricing models to something that often matters even more: culture.

No matter how good your cost dashboards or budgets are, they won’t help much if engineering teams don’t have the awareness, context, or ability to act on them. Over the past years, I’ve seen how the real breakthroughs in cloud cost optimization don’t come from a new service or discount plan — they come from teams that actually care about what things cost, and have the workflows to match.

In this edition, I’ll walk you through what it takes to build a cost-aware engineering culture. One where visibility is built into the daily flow, ownership is shared (not blamed), and developers are empowered to take action without slowing down.

Let’s look at how to make that happen — one team at a time.

Cheers, Michiel

Why teams don’t think about cost

Let’s be honest — most engineers don’t wake up thinking about cloud cost.

I didn’t either, for a long time.

You’re deep in feature work, fixing bugs, deploying changes. There’s always something more urgent than checking if your storage tier is still the right one or whether you’ve over-provisioned a test environment.

And if cost is being tracked at all, it’s usually somewhere far from the team. Maybe finance runs a report once a month. Maybe someone in ops sends out a spreadsheet when the bill spikes. But it’s not part of the daily feedback loop.

That’s where things go wrong. Not because people don’t care, but because they don’t see it. Cost becomes invisible. And anything invisible gets ignored — until someone escalates.

To build real FinOps maturity, we have to make cloud cost visible, relevant, and shared. It’s not about enforcing rules. It’s about making smarter decisions with better context.

Let’s look at what that can look like in practice.

Make cost visible in the developer workflow

If you want engineers to care about cost, the first step is making sure they can actually see it. Not in a monthly finance report or some abstract dashboard, but right where they do their work.

This is where most teams fall short. Cost data exists, but it’s not connected to daily decisions. And if something isn’t part of the feedback loop, it’s easy to ignore.

Here’s how to bring cost into focus.

1. Add cost signals to pull requests

Every time a change goes through a PR, we review functionality, naming, structure — but rarely do we ask: will this be expensive to run?

By using tools like Infracost, you can add a cost estimate to infrastructure pull requests. When someone increases the CPU on an App Service or changes the SKU for a database, the estimated price difference is shown inline. No extra effort required.

This doesn’t block the PR. It just makes the impact visible. And that’s usually enough to start a conversation.

2. Post cost updates where teams live

Most developers don’t check Azure Cost Management dashboards. But they do live in Slack or Teams.

Set up daily or weekly cost digests that post to team channels. These can include:

• Current spend vs budget

• Top 3 cost changes

• Suspicious spikes

• Spend per tag (e.g. team or environment)

You can use Azure automation, my Azure Cost CLI tool, or third-party bots for this. The goal isn’t precision — it’s presence. Once people see the data regularly, they’ll start to ask better questions.

3. Show cost in your dashboards

If you already have dashboards for system health, delivery metrics, or reliability, add a cost widget there. Make it part of the operational picture.

Start simple:

• Cost today vs this time last week

• Cost per environment

• Trending services

This helps shift the mental model. Cost is no longer just a financial concern. It becomes part of system health.

4. Bring cost into retros or demos

Don’t wait for a crisis to talk about cost. Make it part of regular engineering rhythm:

• “What change had the biggest impact on cost this sprint?”

• “Anything we can optimize based on last month’s data?”

• “Are we still using that large test cluster we spun up?”

Even five minutes in a retro can make a big difference.

By making cost visible — right where engineers work — we turn it from an abstract concern into a concrete part of the feedback loop.

And once it’s visible, people start to care.

Create ownership without blame

Once cost becomes visible, the natural next step is to ask: who is responsible for this?

This is where many teams get stuck. Either no one takes ownership because it’s not clearly defined, or someone gets called out after a spike and becomes defensive. Neither approach helps.

Cost ownership doesn’t mean assigning blame. It means giving teams the clarity and accountability they need to make smart decisions — just like they do for performance, quality, or uptime.

Here’s how to move in that direction.

1. Use tags to create team-level ownership

In Azure, tagging resources is one of the simplest and most effective ways to establish who owns what.

Start with a few consistent tags:

• Team

• Environment (dev, test, prod)

• Project or Application

• CostCenter (if needed for finance)

Once these tags are in place, cost data can be grouped and filtered per team. Suddenly, it’s not “Azure is expensive,” it’s “this project is trending 20% above expected.” That’s a very different conversation.

Make tagging part of your deployment pipelines, not a manual afterthought.

2. Enable team-level budgets and alerts

Budgets don’t just belong to central IT. Set up team-specific budgets and route alerts directly to the people building the systems.

Even better: show real-time budget burn next to the service dashboard. Let teams see how they’re tracking before it becomes a problem.

When engineers see the numbers and can influence them, they tend to respond quickly and creatively.

3. Make cost part of the ownership model

Many teams have an on-call rotation, an application owner, or a service champion. Why not add cost ownership to the same role?

This doesn’t mean they need to approve every SKU change. But they should:

• Know the current spend and why it looks like that

• Be the first to respond to unexpected changes

• Act as a point of contact when the business asks questions

Ownership doesn’t mean isolation. It means someone cares enough to track and improve.

4. Normalize cost discussions

Talk about cost without judgement. If something went wrong, treat it like a bug:

• What happened?

• What did it cost us?

• How do we prevent it next time?

Use the same tone you’d use for an uptime issue or a failed deployment. This makes people more willing to share, investigate, and learn.

Ownership works best when people feel they have both responsibility and support.

Not finger-pointing, not silence — just clear expectations and a shared goal.

Give teams the tools to take action

Visibility and ownership are only useful if people can follow through. Nothing kills motivation faster than showing someone a problem they can’t fix.

Too often, teams want to help — but the tools are missing, the process is unclear, or they’re locked out of making infrastructure changes. FinOps turns into passive reporting instead of active improvement.

To avoid that, we need to remove friction and enable teams to act when it matters

1. Make infrastructure-as-code the default

When infrastructure lives in code, it becomes part of the developer’s world. That means cost-related changes can be made:

• In pull requests

• With clear review processes

• Alongside functionality and security

It also makes cost changes trackable over time, and enables automation tools (like cost diff previews, security scanning, or tagging enforcement).

Bicep, Terraform, Pulumi — use what fits your stack. The important thing is: if a team owns the service, they should also own the definition of the infrastructure.

2. Give teams permission to clean up

It sounds obvious, but many teams don’t have the access they need to delete unused resources. Or they fear breaking something because the ownership isn’t clear.

If you want cost-conscious behavior, make sure developers can:

• Remove their own unused environments

• Resize test resources when they’re idle

• Shut down VMs or apps outside of working hours

Automation helps here. Scheduled cleanup jobs, “opt-in to auto-delete” flags, or approval flows with visibility into dependencies.

The point is to make cleanup safe and expected — not risky and rare.

3. Shift alerts from central ops to teams

A cost spike alert is only useful if the right people see it and can do something about it.

Instead of routing all alerts to a central mailbox or operations team, set up alerts that go directly to the owning team:

• Use tags to route alerts by team

• Post alerts into their Slack or Teams channels

• Include clear data and links to the affected resources

This reduces lag time, avoids escalation overhead, and reinforces the idea that cost is part of product ownership.

4. Offer guidance, not just raw data

Even when teams have access, they often don’t know what “good” looks like. Share internal benchmarks or rules of thumb:

• “A dev environment for this app typically costs X”

• “Storage above Y GB might mean data retention is too long”

• “This Function App’s spike suggests a cold start issue”

You don’t need a full internal FinOps academy. Just surface tips at the right time and place — ideally as part of dashboards, reports, or PR reviews.

Giving teams tools means removing excuses and reducing friction.

If people have context, ownership, and the ability to act, they will.

Make cost part of the team’s rhythm

You don’t need to launch a company-wide initiative to build cost awareness. Sometimes the best changes come from what happens in small, consistent moments — retrospectives, standups, demos, code reviews.

If cost is always something discussed after the fact, it becomes someone else’s problem. But if it shows up in the daily or weekly rhythm of the team, it becomes part of how decisions are made.

Here are a few simple ways to get there.

1. Add cost as a retro topic

Even just five minutes at the end of a sprint can help:

• Did anything surprise us in the cost reports?

• Did we forget to shut something down?

• Is this service still sized appropriately?

You don’t need a full analysis. A quick check-in helps surface early signals and builds habit.

Over time, teams start thinking about cost before the retro, which is the whole point.

2. Celebrate cost wins in demos

Shipping features is important. So is improving performance. Why not highlight cost improvements too?

• “We moved this storage to a lower tier and saved 30%”

• “We split out a Function App and saw reduced invocation costs”

• “We removed three unused environments after a cleanup”

This sends a strong signal that cost improvements are part of what success looks like.

3. Add a cost check to design reviews

When discussing architectural choices or major changes, ask:

• What will this cost in production?

• How does this scale under load?

• Are we using the right SKUs or tiers?

You don’t need a perfect estimate. Even asking the question creates space for better decisions.

4. Track cost-related tech debt

Not everything gets fixed in the same sprint. That’s fine — just make sure it’s tracked.

Examples:

• Overprovisioned VMs due to old sizing

• Storage accounts with full logging enabled

• Repetitive deployments of unused preview features

If it affects cost and could be improved later, make it visible and give it a backlog item. That way, it doesn’t get forgotten.

Final thoughts

Engineering teams already care about quality, performance, and reliability.

Cost belongs in that same list — not as a blocker, but as another signal of good engineering.

Creating a cost-aware culture isn’t about adding pressure. It’s about building the same feedback loops we use for everything else:

• Visibility in the workflow

• Ownership that feels fair

• Tools that enable action

• Rituals that reinforce the right behavior

You don’t need to change everything at once. Start small:

• Add a cost summary to your team Slack

• Bring up cost once in the next retro

• Tag your next deployment properly

From there, it becomes part of how teams think — and that’s where the real optimization starts.

Interested in sponsoring this newsletter? Do visit the sponsor page for more information.

Thanks for reading this week’s edition. Share with your colleagues and make sure to subscribe to receive more weekly tips. See you next time!