Hi {{ first_name | there }},

It has been a while since the last edition went out. The silence was not intentional, but it does deserve an explanation.

Over the past months, I made a significant career move. I transitioned from working as an Azure Cloud consultant at Xebia to stepping into the role of CTO at Freelance.nl. It is an exciting new chapter, with broader responsibilities and a different focus. We still use Azure. FinOps still matters. But I am no longer helping customers with their cloud cost challenges on a daily basis.

With that shift came a reality check. I simply do not have the time and energy to continue publishing this newsletter twice a month at the level it deserves. As much as I enjoyed writing about Azure FinOps, this will likely be the final edition of Azure FinOps Essentials in its current form.

Before closing this chapter, I want to share something I have been building. It combines the topics I care most about: cloud, FinOps, shift left, and GitHub. A platform designed to bring FinOps closer to developers.

And to make it interesting, the first 10 people who want to try it will receive a Pro account for free.

Let me show you what I mean.

Bringing FinOps where it belongs

If you’ve been reading this newsletter for a while, you know I’ve repeated one theme often.

Shift left.

The closer you bring an issue to the people who can act on it, the faster it gets resolved. That applies to performance, security, and just as much to cloud cost.

The problem with most FinOps tooling is not that it lacks insight. It is that the insight lives somewhere else. In dashboards. In reports. In finance meetings. Far from the engineers who can actually fix the issue.

That gap is what I wanted to close.

So I built LeftSize.

LeftSize runs from your own GitHub repository using GitHub Actions. You connect your Azure subscriptions or AWS accounts, and it scans them for cost optimizations, security risks, governance gaps, deprecated components, and best practice violations.

Instead of showing you a dashboard, it creates GitHub Issues.

Each finding becomes an actionable item inside your existing workflow. Engineers can assign it, discuss it, generate remediation scripts through ChatOps, snooze it, or fix it. No context switching. No separate portal.

It brings cost and cloud control directly into engineering.

This is not built for enterprises with a 10 million Azure annual spend and a dedicated FinOps team. There are strong platforms for that market.

LeftSize is for smaller and growing teams that want grip and control without implementing a heavy FinOps stack. It is easy to onboard, runs in your own pipeline, and turns cloud insights into actual work.

And to make it interesting, the first 10 people who want to try it will receive a Pro account for free.

If you believe cost awareness belongs closer to code, I would love for you to try it.

How it works in practice

LeftSize is intentionally simple to set up.

You install the GitHub App in your organization.

You add a workflow file to your repository.

That workflow runs as a GitHub Action and connects to your Azure subscriptions or AWS accounts using read-only credentials.

Nothing exotic. No long onboarding. No external credential storage. You stay in control because everything runs inside your own GitHub pipeline.

If you manage multiple subscriptions or accounts, you can use a matrix workflow. That allows you to scan several environments in parallel. Production and non-production can be separated and treated differently.

Once configured, the workflow runs on a schedule. Daily. Weekly. Or however often you prefer.

LeftSize scans your environments and looks for cost optimization opportunities, governance gaps, security risks, deprecated components, and configuration best practices. There are around 100+ rules it scans for; on AWS and Azure.

When it finds something, it does not send you to a dashboard.

It creates a GitHub Issue.

LeftSize understands environments. Production findings are treated differently from non-production ones. Findings are grouped to avoid noise. Snoozed items remain snoozed. Resolved issues stay resolved. The goal is not to spam you. The goal is to create manageable, actionable work.

From there, you are in control.

You triage the issue.
You look at the estimated impact.
You check the context.
You use ChatOps to ask for remediation scripts or deeper explanation.
You request an AI prompt to investigate further.

Or you decide to accept the risk and ignore it.

Labels help you prioritize based on impact and effort. High savings potential. Security critical. Governance improvement. Or low priority.

Everything happens inside the workflow your engineers already use.

No separate portal.

No new process to enforce.

Just actionable insights, delivered where work already happens.

Closing this chapter

For now, this is where I pause.

I will not continue sending regular Azure FinOps editions. At least not in this format. If I ever return to practicing FinOps on Azure in the same way as before, and have meaningful lessons to share, you will hear from me again. But I do not want to promise something I cannot consistently deliver.

What I do hope is that you stay curious about cloud cost. That you keep challenging defaults. That you keep bringing responsibility closer to engineering.

And I would genuinely appreciate it if you gave LeftSize a try.

If you are interested, send a short email to hi@leftsize.com or simply reply to this email.

The first 10 people who reach out will receive a Pro license, so you can explore the full platform without limitations.

Thank you for reading.
Thank you for the conversations.
Thank you for being part of this journey.

Michiel

Hi {{ first_name | there }},

Azure makes it incredibly easy to get something running. You click through a wizard, choose a tier that looks safe, accept a few defaults, and within minutes your application or service is live. It is one of the reasons teams move fast in the cloud.

But over time those early choices begin to matter.

The default App Service tier keeps running even when traffic is low.

Cosmos DB holds on to a minimum throughput that your workload never reaches.

Storage accounts remain in the Hot tier far longer than anyone expected.

And diagnostics collect far more data than anyone will ever look at.

None of this feels wrong in the moment. Azure is simply giving you a configuration that works reliably. The cost only becomes visible later, when you realize that convenience came with a price tag.

In this edition of Azure FinOps Essentials, I explore why default settings can quietly inflate your bill, where this happens most often, and how a few small adjustments can bring your costs back in line with what your workloads actually need.

Cheers, Michiel

Why this problem is more common than people admit

Almost every team I speak with has a moment where their cloud bill stops making sense. Nobody made a big change. Nobody shipped a new service. Nothing unusual happened. Yet the numbers keep creeping up.

When this happens, teams start digging. They revisit the architecture. They hunt for zombie resources. They check logs and scaling rules. And sometimes they find something clear, but often they do not.

The real reason sits somewhere else.

It sits in the default settings they accepted on day one.

Azure tries to make your life easier. Many services come with recommended SKUs, generous configurations, and safe minimums. These defaults work well for most workloads, especially when reliability matters more than cost accuracy.

But convenience has a price. If you deploy quickly and rarely go back to review the configuration, you end up paying for capacity you never needed in the first place.

This edition explores a simple truth.

The biggest source of waste in Azure often isn’t a mistake.

It’s the silent cost of choosing defaults without questioning them.

Let’s look at where this happens most often, and what you can do to stay in control.

App Service Plans: When convenience hides continuous cost

Azure App Service is one of those services that feels almost too easy. You create a plan, select a tier that looks reasonable, deploy your code, and it simply works. The portal encourages this flow because the goal is clear. Get you online with as little friction as possible.

The problem is that most teams never return to the choices they made during that first setup. The recommended tier often leans toward the Standard plan or something similar. It offers features that sound useful. Autoscaling. Deployment slots. More CPU. More memory. It feels safe, and because everything works, nobody questions it.

Yet App Service Plans bill for the capacity you allocate, not the traffic you receive. Microsoft is very explicit about this. You pay for the compute resources defined in your plan, and billing continues even when the app is idle.

This means a service that handles a few requests per hour can cost the same as one handling thousands. Idle time does not reduce your spend. A plan that is too large keeps draining money even when nothing is happening. And if you deploy each app into its own plan instead of consolidating them, you multiply the problem.

This is not a warning against App Service. It is a reminder that the defaults are designed for reliability, not cost efficiency. Once the application is running, it’s worth taking a moment to ask a few questions.

Do you really need the tier you picked on day one?

Are multiple apps running on separate plans that could be combined?

Is autoscaling configured carefully, or left on the safest option?

Could off-hours scaling or scheduled reductions help?

These small checks make the difference between a plan that quietly drains budget and one that reflects the real needs of your workload.

Cosmos DB: Minimum throughput that becomes an invisible floor

Cosmos DB is one of those services that feels almost magical when you first use it. It is fast, global, flexible, and designed for applications that need consistent performance. Because of that focus, it comes with certain guardrails, and one of the most important is the minimum throughput requirement.

When you create a container with provisioned throughput, you must allocate at least 400 RU per second. That requirement is documented clearly in Microsoft’s pricing guidance.

For some workloads, this is perfectly reasonable. High-traffic services, stable APIs, or predictable applications justify this baseline. But many teams use Cosmos DB for smaller experiments, internal tools, low-volume endpoints, or unpredictable workloads. In those cases, 400 RU can be far more than what the workload actually consumes.

What often happens is simple. Someone creates a container during development. They leave the default throughput in place. The application grows slowly, but the usage stays low. Months later, the bill reflects consistent throughput you never truly used. Nothing is technically wrong, but the cost floor sits much higher than necessary.

Cosmos DB offers alternatives, but they are easy to overlook if you never revisit your configuration. Serverless mode is ideal for sporadic or low-traffic workloads. Autoscale fits services with peaks but low average usage. And reducing RU after the initial launch can deliver immediate savings without changing code.

Defaults are not the enemy here. They are designed to keep your application responsive. The real issue is leaving them untouched when your workload does not fit the assumptions behind them.

A simple throughput review can turn an always-on cost floor into something far more aligned with real usage.

Storage Accounts: Hot tiers that stay hot far longer than needed

Azure Storage is one of the most flexible building blocks in the platform. It supports many scenarios, from hot application data to long-term archives and analytics workloads. Because it needs to be broadly useful, Azure gives every new storage account a safe default. It starts in the Hot access tier.

Hot storage is fast and convenient. It is also the most expensive tier per stored gigabyte. Microsoft’s pricing table shows a clear difference. Hot storage carries a higher monthly cost than Cool or Archive storage because it is optimized for frequent access and low latency.

This default makes sense when you are building an application that reads and writes data constantly. It is less ideal when the account is created for diagnostic logs, export files, backups, or data that nobody plans to access frequently. Yet this is exactly how many workloads start. A developer needs a place to store something. They create a storage account. They accept the default tier. The data grows. And the tier remains unchanged for months or years.

The difficulty is that nothing feels broken. Applications keep running. Export jobs succeed. Nobody receives an alert. But the bill quietly increases because the data sits in a tier that was never meant for long-term retention.

Azure provides simple tools to fix this. Lifecycle management policies can move older data to Cool or Archive without manual effort. You can also use application patterns where logs or historical data immediately land in cheaper tiers. And if you periodically audit your storage accounts, you will often find large buckets of data that no longer justify the Hot tier at all.

The point is not to avoid Hot storage. It plays an important role. The point is to recognize that Azure starts you there for safety, not for cost efficiency. Unless you actively move your data into a tier that matches its real value, you pay more than necessary for storage that rarely gets touched.

Logging and Monitoring: Generous defaults that slowly grow into noise

Azure Monitor and Log Analytics are essential parts of running applications in the cloud. They give teams the visibility they need to diagnose issues, understand performance, and maintain stability. Because visibility is so important, many services in Azure enable broad diagnostics by default. They capture metrics, logs, and traces without requiring much configuration.

This is useful on day one. You deploy something new. You want to see everything. You want to understand how it behaves. And Azure makes that easy.

The challenge appears over time.

Those logs continue to accumulate.

Retention settings often remain at the default, which is commonly set to 30 days for Log Analytics workspaces.

Diagnostic rules gather far more categories than the team actually needs.

And nobody revisits the setup once the system is running smoothly.

Azure Advisor even calls this out directly. It warns that collecting unnecessary logs increases cost and recommends adjusting diagnostic settings and retention to match real operational needs.

Log data is not expensive at first. A few gigabytes here and there feel manageable. But logs grow predictably. Data from busy applications, verbose tracing, and platform-level diagnostics accumulate over months. Eventually the workspace becomes one of the top contributors to the monthly bill, even though most of the data is never queried.

This is not a failure of the platform. It is a natural side effect of generous defaults combined with long-term growth. The fix is simple, yet often ignored. Reduce retention for environments that do not need a full month of history. Disable categories that produce high volumes but add little value. Move older logs to cheaper storage if you still want to keep them.

Good monitoring is not about collecting everything. It is about collecting what you can act on. Anything beyond that only adds cost without improving reliability.

Bringing it all together

Azure defaults are designed with a simple goal. Make it easy to get something running. Prioritize reliability. Keep you from breaking things on day one. These defaults are safe, and they genuinely help teams move fast.

The trouble is that default settings rarely match the long-term needs of a real workload. They create comfort, but they also create hidden cost. Idle compute in an app service plan. Minimum throughput that exceeds real demand. Hot storage that never cools. Log retention that grows quietly until it becomes one of your biggest contributors.

None of this happens because someone made a bad decision. It happens because teams stay focused on delivery, and the configuration they picked during a quick setup eventually turns into the configuration they keep forever.

Cost control in Azure is not about mastering every advanced feature. It is about paying attention to the points where convenience quietly becomes expensive. When you revisit your choices, even briefly, you take back control. You question assumptions. You reduce idle waste. You tune storage and logs to match how your systems really behave.

The good news is that you do not need a complex process to benefit from this. You only need the habit of reviewing the defaults that got you started. A few small adjustments often bring your environment much closer to the actual needs of your workloads.

By replacing convenience with intention, you turn your cloud bill into something predictable, understandable, and aligned with how your services create value.

Interested in sponsoring, then visit the sponsor page.

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!

Want more FinOps news, then have a look at FinOps Weekly by Victor Garcia

FinOps Weekly

Save on Your Cloud Costs with 5 Minutes every Sunday

Subscribe

Hi {{ first_name | there }},

FinOps advice is everywhere. You’re supposed to tag everything, track everything, forecast better, and set alerts for every possible threshold. But let’s be honest — most teams don’t fail because they ignored best practices. They fail because they fell into familiar, well-intentioned traps.

That’s why this edition takes a different route.

Instead of repeating the same advice, I’m sharing the anti-patterns I’ve seen most often in real-world Azure environments. These aren’t theoretical mistakes. They’re the habits that slowly turn your cloud bill into a mystery no one wants to solve.

The goal is simple.

Recognize what’s holding your cost visibility back.

Fix what’s in your control.

And avoid repeating what many teams silently regret.

Let’s get into it.

Michiel

What not to do when managing cloud costs

There’s no shortage of FinOps best practices. Tag everything. Set budgets. Review usage weekly. Shift left. Show back. Right size.

And yet, many teams still struggle to get a grip on cloud cost. Not because they don’t know what to do. But because they’re too busy doing everything else.

So this edition flips the script.

Instead of walking through best practices, I’m sharing this unofficial FinOps Anti-Playbook. The habits, shortcuts, and decision patterns that silently inflate your Azure bill while everyone’s looking the other way.

If any of these sound familiar, you’re not alone. The goal isn’t to shame. It’s to surface the real blockers so we can replace them with better habits.

Let’s start with the most common lie teams tell themselves.

“We’ll optimize it later.”

Anti-Pattern #1

“Just lift and shift. We’ll optimize later.”

This is how every expensive cloud story starts.

The team is under pressure. Deadlines are tight. The migration has to happen. So the goal shifts from building the right architecture to getting it running. Cost is something Future You will worry about.

Only Future You is too busy handling support issues from that same rushed migration.

The application is stable, but inefficient. It runs on oversized VMs. It pulls in PaaS services with default SKUs. Autoscaling is disabled because it caused one incident three months ago. And nobody dares touch it.

What started as a temporary lift-and-shift becomes the long-term setup.

Optimizing “later” turns into never. And the bill grows month by month.

This doesn’t mean you can’t move fast. But if you don’t stop to question default configurations, or review architecture within the first few sprints post-migration, you’re not doing FinOps. You’re just funding technical debt with cloud spend.

Anti-Pattern #2

“Tag nothing. Trust tribal knowledge.”

It always starts the same. A dev spins up a resource group to test something. A PaaS service gets deployed. Nobody tags it. The environment lives on.

Weeks later, someone notices a cost spike.

The dashboard shows a vague service name in a random region. No tags. No notes. No one knows who owns it. The only documentation is someone’s vague memory of a project from Q2.

Now the team spends hours tracing back the deployment pipeline, sifting through audit logs, or just deleting the resource and hoping nothing breaks.

Tagging isn’t just about showback reports or policy compliance.

It’s a survival tool.

It tells you who owns what. Why it exists. Whether it’s safe to delete. It’s how you separate production from test, shared from dedicated, and long-term from temporary.

When you skip tagging, you’re not saving time.

You’re borrowing confusion.

Anti-Pattern #3

“Our alerts are working. They went to someone once.”

You’ve set up cost alerts in Azure.

There’s a budget threshold on the subscription. The alert fires. Emails are sent. The system works.

Until no one sees it.

Or it lands in an inbox labeled “monitoring@” that nobody checks.

Or it gets routed to an engineer who left six months ago.

Alerts without ownership are noise.

They don’t create awareness. They create fatigue. After the second unexplained spike, teams stop paying attention. Everyone assumes someone else will handle it.

And even when the alert is seen, it’s often missing the one thing that matters: context.

What changed? Who deployed? Is it normal? Should we care?

Good alerting isn’t just about sending a signal.

It’s about getting the right signal to the right person, in the right place, with just enough context to act.

Otherwise, your cost monitoring setup is just automated guilt with no impact.

Anti-Pattern #4

“Buy a 3-year reservation right before budget resets.”

The quarter is ending. The budget isn’t fully spent. Someone suggests locking in savings by committing to Reserved Instances. It’s fast, it looks smart, and it gives finance a clean win.

Until the service gets deprecated next year.

Or the workload moves regions.

Or the project never scales the way it was forecasted to.

Commitment-based discounts like Reserved Instances and Savings Plans can absolutely save money. But only when they’re backed by real usage data, workload stability, and cross-team alignment.

Buying reservations in a rush is like buying a 3-year gym membership on December 31st.

It feels productive. But it often ends up unused.

Smart FinOps isn’t about spending the budget.

It’s about knowing when not to.

Time to burn the anti-playbook

None of these anti-patterns happen out of malice.

They happen because teams are busy. Processes are unclear. And cost often feels like someone else’s problem — until it isn’t.

But here’s the thing.

You don’t need a perfect FinOps setup. You just need to stop doing a few things that silently sabotage your visibility and control.

Skip the rushed commitments.

Tag your stuff.

Route alerts where teams actually live.

Don’t wait for “later” to optimize.

Good FinOps starts when you stop making cloud cost someone else’s cleanup job.

It becomes part of how you build. How you review. How you learn.

Burn the anti-playbook.

Write your own rules.

And make cost a decision, not a surprise.

Interested in sponsoring yourself, then visit the sponsor page.

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!

Want more FinOps news, then have a look at FinOps Weekly by Victor Garcia

FinOps Weekly

Save on Your Cloud Costs with 5 Minutes every Sunday

Subscribe

Hi {{ first_name | there }},

Cloud costs often feel like they arrive out of nowhere. You deploy a service on Monday and don’t realize it doubled your spend until the invoice lands weeks later. The data is delayed, the alert comes too late, and by then it’s just damage control.

But what if you could spot the warning signs earlier?

What if engineering teams could respond to cost shifts the same way they respond to performance regressions or outages?

In this edition of Azure FinOps Essentials, I explore how to bring cost signals closer to where decisions are made. You’ll learn which Azure tools can surface usage changes in near real-time, how to integrate them into team workflows, and how to shift from reacting to invoices toward preventing surprises altogether.

Because the best cost savings don’t come from catching problems.

They come from not creating them in the first place.

Cheers, Michiel

Why “real-time” is relative in Azure cost monitoring

If you’re hoping to get real-time cloud cost updates in Azure, prepare to be slightly disappointed. Azure does not offer instant cost telemetry, and most billing data arrives with a delay. In most environments, cost data updates every 8 to 24 hours. In some cases, like Marketplace items or third-party services, the delay can stretch beyond that.

This makes cost monitoring in Azure less of a real-time system and more of a “near real-time” or “next day” system. That might not seem like a big deal. But if your workloads scale rapidly or you have high-velocity deployments, that delay can mean the difference between catching a costly misconfiguration early or discovering it days too late.

Azure’s own documentation confirms this. Usage data used by Azure Cost Management is often delayed by several hours. While budget alerts can fire sooner, they still rely on periodically refreshed usage records. If you provision a new premium tier database or scale out your App Service Plan unexpectedly, you may not see the cost impact until the following day.

This creates a common FinOps challenge. Engineering teams want to act quickly when cost patterns shift. But the data they need arrives slowly. As a result, most cost conversations happen reactively, during monthly reviews or finance escalations. That’s too late.

To move cost awareness closer to daily operations, we need to shift our expectations. Instead of real-time cost monitoring, we should aim for actionable, near real-time signals that approximate cost or catch the early signs of waste. With the right architecture, it’s possible to catch 80 percent of the problems before they show up on the invoice.

Key mechanisms for cost visibility and alerts

While Azure doesn’t provide live billing telemetry, it does offer a mix of tools that can help you monitor cost changes, trigger alerts, and build awareness into engineering workflows. Each has tradeoffs in latency, scope, and control.

1. Azure Budgets and Alerts

Azure Budgets let you define a threshold on cost or usage over a defined scope, like a subscription, resource group, or management group. When the threshold is reached (e.g. 80% of budget), an alert is triggered via Azure Monitor.

These alerts are useful for spotting trends early, but they are not live. According to Microsoft, budget alerts are based on cost data that may be refreshed every 4 hours, and for some customers it may take 8–24 hours for usage to be fully processed. That means you might cross a threshold at noon and only be alerted the next morning.

Still, budget alerts are easy to configure and integrate. They can send email, trigger webhooks, or notify teams through action groups. They are most useful for catching broad anomalies like a runaway deployment or a sudden regional scale-out.

2. Cost Exports and APIs

If you want to build custom dashboards or automated checks, Azure Cost Management offers two primary data access methods:

• Cost Details API (aka UsageDetails): Lets you query granular cost data for specific scopes

• Cost Export: Automatically drops daily usage data into a Storage Account in CSV or Parquet format

These exports are useful for teams that want to visualize trends, join cost data with tags, or push it into reporting tools like Power BI or Azure Data Explorer. Keep in mind that the export frequency is daily, and the data often reflects activity from the previous day.

3. Resource-level monitoring as a proxy

While you can’t get real-time billing data, you can approximate cost impact using resource metrics and known pricing information. For example:

• If your App Service is scaling out aggressively, you can detect CPU or instance count changes

• If your storage account sees large ingestion spikes, you can trigger alerts based on GB written

• For Function Apps or Event Hubs, you can monitor execution or throughput units

By combining these metrics with pricing tables, you can estimate whether costs are likely to spike. This works especially well when your team already tracks performance and health through Azure Monitor.

These tools form the building blocks of cost awareness in Azure. None of them are perfect. But when combined, they allow you to catch 80% of cost issues before they become invoice problems.

Integrating cost signals into engineering workflow

Too often, cost data stays siloed. Finance reviews the monthly Azure invoice. Engineering is unaware of the cost impact until someone escalates. By then, the problem has grown.

If we want to shift cost awareness left, we need to treat cost signals like operational signals. That means integrating alerts, telemetry, and reporting into the tools and rhythms teams already use.

Here are practical ways to bring Azure cost visibility closer to where engineering happens.

1. Route alerts where teams actually work

Budget alerts and anomaly signals are only useful if someone sees them. Use Azure Action Groups to send budget notifications directly to Slack, Microsoft Teams, or email groups scoped to the owners of a workload.

You can also integrate webhook-based alerts with tools like:

• Azure DevOps Service Hooks

• GitHub Actions or Issues

• Jira tickets or incident management tools

An alert is not enough. There needs to be a clear owner, visible context, and a channel where the team is already active.

2. Make cost part of deployment awareness

If a change to infrastructure causes cost to spike, that signal should be tied to the change.

For example:

• A GitHub Action can compare a proposed change to a Terraform or Bicep file with a known SKU cost

• An Azure DevOps pipeline can log estimated cost deltas before applying the infrastructure

• A deployment workflow can check whether the change will exceed an environment-level budget and block or warn

This turns cost into a first-class deployment quality gate, just like security or performance.

3. Visualize cost per environment or team

Use the Azure Cost Management API to build simple dashboards that show daily cost by:

• Subscription

• Resource Group

• Tag (e.g. team, environment, service)

You can embed this into existing dashboards in Power BI, Grafana, or custom portals. This gives teams a near real-time pulse of their own cloud impact without needing access to global billing portals. Of course, you can also have a go with my own Azure Cost CLI to turn cost data into nice console dashboards.

4. Surface estimated costs through metrics

For high-velocity workloads like Functions, Event Hubs, or App Services with autoscaling, cost telemetry can be inferred from usage metrics. Teams can monitor:

• Execution count

• Throughput units

• CPU hours or vCore usage

  Then multiply by published pricing to estimate cost spikes.

You can even create custom metrics in Azure Monitor (or Application Insights) that estimate daily spend, and alert on those instead of waiting for billing data.

The goal is not to flood teams with alerts. It is to create a feedback loop. When cost becomes visible in daily operations, developers learn to spot problems early, question design tradeoffs, and take action before finance gets involved.

Wrapping up

Real-time cost monitoring in Azure doesn’t exist. At least not in the way most teams expect. Usage data is delayed. Budget alerts arrive hours or days later. And by the time the monthly invoice shows up, it’s often too late to do much.

But that doesn’t mean you’re stuck reacting after the fact.

Azure provides enough signals, from budget alerts to usage metrics to daily exports, to build a near real-time view of what’s happening. These signals may not be perfect, but they’re good enough to spot patterns, detect anomalies, and catch runaway resources before they spiral out of control.

The real question is where these signals go.

If they stay in billing portals, they’re invisible to the people who can act. If they flow into team channels, dashboards, and pipelines, they become part of the daily rhythm. That’s where the real change happens.

Still, even fast feedback is just a safety net. The best savings come from avoiding the cost entirely. If engineers understand the pricing impact of their design choices before they deploy, there’s nothing to catch later. No alert needed. No spike to explain.

That’s the heart of FinOps. Not just reacting faster, but building better. Cost-aware engineering starts with visibility, and ends with smarter decisions.

Interested in sponsoring, then visit the sponsor page.

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!

Want more FinOps news, then have a look at FinOps Weekly by Victor Garcia

FinOps Weekly

Save on Your Cloud Costs with 5 Minutes every Sunday

Subscribe

Hi {{ first_name | there }}, and welcome to this week’s edition of Azure FinOps Essentials.

This week, I am tackling a challenge many teams face but rarely discuss: how to design for failure without designing yourself into a bigger invoice.

High availability is important. But most cloud architectures quietly overdo it. Secondary regions run at full power. Zone redundancy is enabled by default. Premium SKUs are selected for peace of mind, not based on real risk.

The result? You get resilience, but you also get a bill that keeps growing.

In this edition, I will show you how to design fault-tolerant systems without paying for infrastructure you do not need. You will see common over-engineering patterns, better tradeoffs, and Azure tools that help you build smart without building twice.

Let’s dig into the cost side of reliability.

Cheers, Michiel

Find out why 100K+ engineers read The Code twice a week

Staying behind on tech trends can be a career killer.

But let’s face it, no one has hours to spare every week trying to stay updated.

That’s why over 100,000 engineers at companies like Google, Meta, and Apple read The Code twice a week.

Here’s why it works:

• No fluff, just signal – Learn the most important tech news delivered in just two short emails.

• Supercharge your skills – Get access to top research papers and resources that give you an edge in the industry.

• See the future first – Discover what’s next before it hits the mainstream, so you can lead, not follow.

Join 100,000+ engineers who read The Code to stay ahead of the curve.

Cost and resilience pull in opposite directions

We’re told to design for failure.

Use multiple zones.

Use premium storage.

Add a second region.

Scale out, not up.

It all makes sense — until the invoice arrives.

In many teams, availability architecture is driven by worst-case thinking. Outages are scary, and nobody wants to be blamed for downtime. So we duplicate services, pay for extra capacity, and layer in failover options “just in case.” The problem is that these decisions are rarely reviewed later.

Over time, what starts as a good-faith effort to build resilience turns into a quiet cost multiplier.

I’ve seen secondary regions that were never used, but fully provisioned.

Zone redundancy on services that don’t need it.

Premium SKUs running in environments with zero traffic.

It’s not that resilience is the problem.

It’s that we’ve stopped treating it like a tradeoff.

In this edition, I’ll break down how to design architectures that can handle failure and respect your cloud budget. We’ll explore over-engineering patterns, cost-aware design alternatives, and how to make reliability decisions that are both technical and financial.

Let’s start with where things often go too far.

Common over-engineering patterns

Most teams don’t set out to overspend on availability. These patterns often start with good intentions: protect against failure, reduce risk, improve uptime. But without clear boundaries, they quietly expand into over-engineering and unnecessary cost.

Here are some of the most common examples.

Always-on capacity in multiple regions

Setting up a secondary region is a solid high availability strategy. But if both regions are active and always-on, you’re paying double. Even worse, the secondary region often goes unused for months. If failover is rare, consider an active-passive setup with lower specs or a cold standby model.

Zone redundancy by default

Many services like Azure Storage, App Service, and SQL offer ZRS or zone-redundant options. These are useful, but not always required. I’ve seen dev and test environments use ZRS without any business requirement. That means you’re paying for durability where no one needs it.

Premium SKUs for the wrong reason

Premium tiers often include SLAs, scaling options, or extra features. But once selected, they rarely get reviewed. A team might choose Premium V3 for an App Service that only runs a staging app, or pick Premium Functions to avoid cold starts, even when cold starts aren’t a real issue.

Overprovisioning for hypothetical traffic

Failover planning often assumes peak usage during an outage. So teams provision the backup region or failover path for worst-case load, even if traffic would likely drop in a real-world incident. You don’t need to match full production scale unless business rules explicitly require it.

Identical infrastructure across all environments

Using the same architecture for dev, test, and prod improves consistency. But when that includes regional failover, zone redundancy, or premium services, you’re adding cost where risk is low. Resilience should be based on how critical the environment really is.

These patterns are not always wrong, but when left unchecked, they shift your cloud spend away from value and toward silent waste.

Designing for failure without paying twice

Resilience is important, but that does not mean every system needs the highest possible uptime. In practice, many workloads can tolerate short periods of downtime, degraded performance, or manual failover. Designing for failure does not mean duplicating everything. It means being deliberate about what you protect, how you recover, and what you are willing to pay for.

Here are practical strategies to reduce availability costs while still protecting against failure, along with Azure tools that can support those choices.

Use active-passive failover where possible

Not every workload needs full active-active deployments. For many internal tools, batch systems, or customer-facing portals with moderate usage, an active-passive setup is enough. Keep the passive region warm or cold, depending on your recovery time goals. Only scale when failover is triggered.

Azure tools that help:

• Azure Traffic Manager to route traffic based on endpoint health

• Azure DNS failover to switch over at the DNS level

• Azure Site Recovery to maintain a cold standby environment with lower SKUs

Choose lower tiers for standby

Your secondary region does not need to match production specs. Use lower SKUs, minimal autoscaling, or standard tiers for the backup path. If failover is rare and temporary, the user experience can degrade slightly without breaking the service.

Azure tools that help:

• App Service Standard tiers with autoscale rules scoped to regions

• Azure Monitor autoscale for predictable growth when failover is triggered

• ARM templates or Bicep to recreate or resize infrastructure quickly

Build for fast recovery, not just high uptime

If the cost of high availability is out of line with the business value of the system, invest in fast recovery instead. That means automation, snapshots, and clear recovery steps rather than duplicated infrastructure.

Azure tools that help:

• Azure Backup for storage, VM, and SQL snapshots

• Infrastructure-as-code for redeployment speed

• Deployment slots to speed up controlled swaps without impact

Match strategy to service criticality

Critical production systems may need premium uptime guarantees. Internal tools or non-critical APIs probably do not. Resilience should reflect the impact of failure, not a blanket rule applied across environments.

Azure tools that help:

• Azure Policy and Management Groups to enforce different standards per environment

• Tags to classify services by business impact

• Budgets and alerts scoped to environment and workload type

Watch your failover costs

If you have a standby region, monitor it. These environments often drift into production usage. Someone adds a Function App, enables logging, or forgets to turn it off, and suddenly your failover zone is costing as much as production.

Azure tools that help:

• Azure Cost Management to detect unexpected resource growth

• Scheduled shutdown scripts for dev, test, and backup infrastructure

• Alerts on specific SKUs, tags, or subscriptions tied to failover regions

The best failover strategy is not always the most redundant one. It is the one that meets business continuity needs at a cost the business is willing to pay. Azure gives you the building blocks to design resilient systems. FinOps helps you decide which ones to use, and when enough is enough.

Wrapping up

Resilience matters. But so does cost.

Many teams build for availability without asking what it is worth. They duplicate infrastructure, overprovision capacity, and pay for premium uptime guarantees, even when the business impact of failure is low.

FinOps is not about cutting these protections. It is about making the tradeoffs visible. It gives you the language and data to ask the right questions.

Do we really need this to be active-active?

Can we recover in minutes instead of staying always-on?

Does the cost align with the risk?

When cost becomes part of the design conversation, resilience becomes intentional.

And that is where the real savings begin.

The Free Newsletter Fintech Execs Actually Read

Most coverage tells you what happened. Fintech Takes is the free newsletter that tells you why it matters. Each week, I break down the trends, deals, and regulatory shifts shaping the industry — minus the spin. Clear analysis, smart context, and a little humor so you actually enjoy reading it.

Sign Up Free

Please help me by visiting my sponsor. And interested in sponsoring yourself, then visit the sponsor page.

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!

Want more FinOps news, then have a look at FinOps Weekly by Victor Garcia

FinOps Weekly

Save on Your Cloud Costs with 5 Minutes every Sunday

Subscribe

Hi {{ first_name | there }}, and welcome to this week’s edition of Azure FinOps Essentials!

This week, I’m exploring the cost side of Azure PaaS. Services like App Service, Functions, Logic Apps, and Cosmos DB promise simplicity and speed, but they often come with hidden costs if you’re not paying close attention.

PaaS can absolutely support a cost-efficient cloud strategy, but only if you understand how these services are billed, when to scale them, and what to avoid. I’ll walk through common traps, smart design choices, and when it still makes sense to pay for convenience.

If your team uses Azure PaaS or is considering it, this edition will help you make better-informed decisions and avoid unnecessary surprises.

Let’s get into it.

Cheers, Michiel

The hidden cost of PaaS convenience

When Azure PaaS first arrived on the scene, I loved it.

No more VM patching. No more fiddling with hosting. Just deploy and go. For developers, it felt like magic.

But over time, that magic started to fade.

I began seeing bills with strange patterns. Services that barely received any traffic were costing hundreds per month. Logic Apps were running like clockwork, even when they weren’t needed. App Services were deployed on premium plans, even for internal tools with three users.

And it wasn’t just me. In nearly every project I’ve joined in the past few years, I’ve seen the same pattern. Teams default to PaaS for speed, but never revisit their choices, and that’s when cost creeps in.

It’s not that Azure PaaS is bad. Quite the opposite. But if you don’t understand how these services are priced, or how to right-size them for your actual needs, you end up paying for a level of performance or convenience you don’t even use.

In this edition, I’ll walk through the most common PaaS cost traps I’ve seen, and how to get the most out of these services without blowing your budget.

Let’s start by looking at where things tend to go wrong.

Why PaaS isn’t always cheaper

Platform as a Service is often positioned as a cost-effective way to build and run applications. It takes infrastructure concerns off your plate and lets your team move faster. No patching, no VMs, no OS tuning, just deploy and go.

But underneath that simplicity lies a problem: you still pay for the platform, even when you don’t use it.

Most PaaS services in Azure are priced around provisioned capacity, execution volume, or tier-based bundles. These models are easy to misinterpret or misuse, especially when convenience takes priority over optimization. Here’s what I keep seeing in real-world Azure environments.

Azure App Service Plans

Every App Service is hosted in a plan, and that plan defines the resources you’re paying for. Even if the app is idle, the cost continues. What often happens: a team spins up a new App Service and selects a Premium V3 plan for better performance or custom domains.

Then nothing happens. The app receives almost no traffic, but the plan keeps running, billing €200 or more per month. In some environments, I’ve seen five or more small apps each on their own Premium plan, none of them breaking 10 percent CPU. Consolidation would have cut costs by half or more.

Azure Functions (Premium Plan)

Function Apps are often seen as the most cost-effective way to run backend workloads. That holds true on the Consumption Plan. But the moment you move to the Premium Plan to get features like VNET support, custom domains, or improved cold start, the pricing changes completely. Now you’re paying for pre-warmed instances, even if your functions are idle. One project had a single Function App on Premium with three always-on instances running 24/7. Monthly cost: around €150. Actual usage? Less than 10 minutes of compute per hour.

Logic Apps

Logic Apps are billed per execution step. Each action costs a fraction of a cent, until you run hundreds of them every few minutes. I’ve seen environments where Logic Apps were used for monitoring storage queues, checking Blob storage, and routing status updates. These flows ran every 5 minutes, 24 hours a day, even when there was nothing to process. The team never expected them to cost more than a few euros, but together they exceeded €400 per month.

Cosmos DB

Cosmos DB is powerful, but easily over-provisioned. Teams often set high RU/s throughput to handle potential spikes, then leave it unchanged for months. In one case, a team had provisioned 20,000 RU/s for a service that processed a few hundred items per hour. With no autoscale and no alerts, the cost kept accumulating quietly.

Event Hubs and friends

Some Azure services, like Event Hubs, promise elastic scaling but only in one direction. Event Hubs Standard tier does not scale down automatically. If your load spikes, it can add throughput units. But unless you manually remove them, you’re paying for that capacity even after traffic returns to normal. It’s easy to think you’re covered because the word autoscaling is mentioned in the docs. But in practice, many of these services scale up by default and leave scale-down as a manual step.

PaaS is still a great option for many workloads, especially when delivery speed or operational simplicity matters. But when it comes to cost, most services assume always-on usage and conservative provisioning. To keep things efficient, you have to look closer and adjust more often than you think.

Common PaaS cost traps and how to avoid them

You don’t need to stop using PaaS to control costs. But you do need to be more intentional about how you use it. Most cost issues with PaaS don’t come from extreme usage, but from defaults that were never reviewed or resources that were never revisited.

Here are some common traps and how to avoid them.

Overprovisioned plans

Many App Services or Functions run on plans that are far too large for what they need. The most common reason is fear of future load or simply copying what someone else did. Start with the lowest tier that supports your requirements and scale up only if real usage demands it. And if the workload is seasonal or irregular, consider scaling manually or consolidating with other apps on the same plan.

Always-on instances

Services like Azure Functions (Premium), Azure Container Apps, and Azure App Service Plans with autoscaling still reserve capacity even when nothing is running. That means you pay whether the workload is active or not. Review your scaling rules and instance minimums. For low-traffic or background jobs, serverless options might still be a better fit.

Forgotten test environments

Test and staging environments often get the same SKUs as production but are used only during working hours. Without scheduled scale-down or auto-stop policies, they quietly burn through budget outside office hours. Implement scheduled shutdowns, or better yet, let developers deploy to shared environments when needed and tear them down after.

Premium tiers by default

It’s easy to click on a higher tier when setting up a new service, especially if it promises better performance, private networking, or more features. But once those premium features are no longer needed, the plan usually stays. If you’re not using what you’re paying for, downgrade. Many workloads do not need Premium V3, Elastic Premium, or DTU-based SQL tiers.

Overactive workflows

Logic Apps and Functions with time-based triggers can rack up unexpected costs. If your workflow runs every 5 minutes, ask if it really needs to. Add early exit conditions when no work is needed. Review telemetry to see how many runs actually resulted in useful outcomes.

No tagging or grouping

If you can’t attribute costs to specific teams, projects, or environments, you can’t manage them effectively. Make sure all PaaS resources are tagged correctly. Use Azure Policy to enforce tag presence and alert when tags are missing. This helps identify unused or orphaned services.

Being proactive with these patterns can easily reduce your PaaS bill by 20 to 40 percent without changing your architecture. The trick is not to avoid PaaS, but to avoid running it on autopilot.

When PaaS is still worth it

Not every workload needs to be cost-optimized down to the cent. Sometimes, the speed, simplicity, or built-in features of Azure PaaS are exactly what a team needs — even if it costs more than a DIY setup.

Here are some scenarios where paying for convenience makes sense.

When platform features replace operational overhead

Running your own service with VMs or containers might be cheaper on paper, but you’ll need to manage updates, scaling, certificates, networking, backups, monitoring, and more. If a PaaS service handles all of that and lets your team focus on delivering value, the tradeoff can be worth it. I’ve seen teams regain multiple hours per week simply by not having to manage TLS, deployment scripts, or log plumbing.

When consistency across teams is more valuable than fine-tuned savings

In large organizations or fast-moving environments, having a consistent approach matters. If everyone uses the same deployment model, logging setup, and scaling rules, you save time in onboarding, maintenance, and troubleshooting. PaaS gives you those common patterns out of the box. The cost might be slightly higher, but the coordination overhead drops significantly.

When scaling requirements are hard to predict

For unpredictable workloads, for example, bursty APIs, marketing campaigns, or mobile traffic spikes, PaaS can give you a buffer. Services like Azure Functions, Event Grid, and Cosmos DB (with autoscale) handle sudden spikes better than a self-hosted service. In these situations, paying a bit more for elasticity can prevent outages or slowdowns that impact your users.

When your team prioritizes speed over infrastructure control

Startups, internal tool teams, or early-phase projects often don’t have the time or skillset to build scalable infrastructure from scratch. If PaaS allows a team to ship features faster and validate ideas, it’s doing its job. The real cost would be delaying delivery to save a few euros on infra.

When the cost is understood and accepted

In mature teams, spending more isn’t the problem. Lack of visibility is. If a team understands the cost of a PaaS service, tracks its usage, and can justify it, there’s no issue. It only becomes waste when the bill shows up and nobody knows where it came from.

PaaS doesn’t need to be the cheapest option. It needs to be the right one, with eyes open and tradeoffs made consciously.

Wrapping up

Azure PaaS is not the problem. Running it without insight is.

If you understand how a service is billed, what you actually need, and where the waste lives, PaaS becomes a powerful tool. But without that awareness, it’s easy to pay for speed while losing control over cost.

FinOps is not about avoiding spend. It is about making informed decisions that balance performance, velocity, and business value.

PaaS can absolutely support that goal, as long as you are intentional about how you use it.

You can (easily) launch a newsletter too

This newsletter you couldn’t wait to open? It runs on beehiiv — the absolute best platform for email newsletters.

Our editor makes your content look like Picasso in the inbox. Your website? Beautiful and ready to capture subscribers on day one.

And when it’s time to monetize, you don’t need to duct-tape a dozen tools together. Paid subscriptions, referrals, and a (super easy-to-use) global ad network — it’s all built in.

beehiiv isn’t just the best choice. It’s the only choice that makes sense.

Start free today. No credit card required.

Please help me by visiting my sponsor. And interested in sponsoring yourself, then visit the sponsor page.

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!

Want more FinOps news, then have a look at FinOps Weekly by Victor Garcia

FinOps Weekly

Save on Your Cloud Costs with 5 Minutes every Sunday

Subscribe

Hi {{ first_name | 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!

Hi {{ first_name | there }}, and welcome to this week’s edition of Azure FinOps Essentials.

When we think of cloud cost controls, budget alerts are often the first thing that comes to mind. But there is another, often overlooked, signal you should not ignore: quota alerts.

Azure quotas define the maximum number of resources you can deploy, from vCPUs to storage accounts. Hitting those limits can stop deployments in their tracks and disrupt scaling. With quota alerts, you can monitor usage and act before a limit becomes a blocker.

In this edition, I’ll explore why quota alerts matter, how they complement budget alerts, and how they fit into a FinOps practice focused on avoiding risk and maximizing business value.

Cheers, Michiel

When Infinite Scale Meets Hard Limits

The cloud is often sold as an endless pool of compute, storage, and services. But under the hood, Azure is still backed by hardware in real data centers, with physical capacity and logical boundaries. That reality shows up in quotas: limits on how many resources you can provision within a subscription.

Most of the time, these limits are invisible. Until they are not. I once worked on a large event where we provisioned resources for all participants. Within hours, we hit a limit we never expected: only 20 SQL servers per subscription. Suddenly, what felt limitless had a very real ceiling.

Quotas exist for good reasons. They protect customers from runaway deployments, mistakes in automation, or malicious consumption. They also help Microsoft manage demand. But for teams trying to scale quickly, running into these limits can be painful. Deployments fail, scaling stops, and engineers scramble to file support tickets.

Usage + quotas page

Some quotas are adjustable and can be increased with a simple request. Others are hard caps that require a support case or even an architectural change. Either way, hitting them at the wrong time is disruptive. From a FinOps perspective, quotas are not just an operational nuisance. They are part of cost control and risk management, ensuring that scaling is done predictably and safely.

This is where Azure Quota Alerts come into play.

Quota Alerts: Awareness Before It Hurts

Azure introduced Quota Alerts in late 2024, yet many teams still overlook them. The idea is simple: you get notified when usage approaches a quota limit, before deployments start failing.

Instead of building custom scripts or dashboards, quota alerts are now native in the portal. You choose the subscription, the quota to track (for example, regional vCPUs), and a threshold such as 80 percent usage. From there, Azure monitors the quota and triggers an alert through the channels you already use, like email, Teams, or an Action Group.

Create a new alert rule from the Quotas overview

The value is not just technical. From a FinOps perspective, quota alerts give you predictability. They allow you to plan capacity increases in advance, avoid firefighting during critical launches, and integrate quota considerations into cost and risk management. For startups and digital natives scaling quickly, that visibility can be the difference between a smooth rollout and a very public failure.

Quota alerts do not remove the limits, but they turn them into manageable signals rather than unexpected roadblocks.

Bringing It Back to FinOps

In FinOps, we often talk about budgets, forecasts, and alerts to keep spending under control. Budget alerts are a familiar tool for many teams, helping you stay within financial guardrails. Quota alerts serve a similar purpose, but instead of money, they protect against resource limits. Both are signals that keep you aware and in control before problems turn into outages or surprise costs.

Cloud resources may feel unlimited, yet they run on physical infrastructure with constraints. By combining budget alerts and quota alerts, you cover both dimensions of risk: overspending and under-provisioning. Together, they provide a more complete safety net, giving engineering and finance teams confidence that growth will not outpace either the budget or the platform.

FinOps is not only about cutting costs. It is about maximizing business value through smart decisions. Quota alerts help you avoid disruption, plan ahead, and ensure that money invested in the cloud translates into real outcomes for your business.

Interested in sponsoring these editions? Then visit the sponsor page.

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!

Want more FinOps news? Then have a look at FinOps Weekly by Victor Garcia

FinOps Weekly

Save on Your Cloud Costs with 5 Minutes every Sunday

Subscribe

Hi {{ first_name | there }}, and welcome to this week’s edition of Azure FinOps Essentials.

This time, we are looking at a cost factor that is often overlooked in cloud discussions: software licensing. When moving workloads to Azure, many teams focus on compute and storage optimization, while ignoring the licenses that run on top. The result is that organizations may end up paying twice, once through existing agreements and again on the cloud bill.

In this edition, I will explain how Azure handles licensing, what Software Assurance and Hybrid Benefit mean in practice, and why paying attention to licensing can unlock hidden savings. More importantly, I will highlight why FinOps practitioners should not treat licensing as a technical afterthought but as an integral part of driving business value in the cloud.

Let’s dive in.

Cheers, Michiel

The Hidden Cost of Cloud: Licensing

When we talk about cloud costs, most people think about compute, storage, or network traffic. Yet licensing is one of the most overlooked factors in Azure.

Take SQL Server or Windows Server as examples. By default, Azure charges you through a pay-as-you-go model that includes the license cost in the hourly rate. If you already own licenses with Software Assurance and do not enable Azure Hybrid Benefit, you are effectively paying twice for the same product.

This is more common than you might expect. Teams migrate quickly, scale up workloads, and focus on performance, but they forget to check the licensing details. The result is thousands of euros wasted each month.

Licensing is tricky because it requires alignment between procurement, finance, and engineering. It is not automatically optimized by Azure. You need to configure it, monitor it, and make sure benefits are applied where they should be.

This is why licensing deserves more attention in FinOps. Getting it right can mean the difference between waste and efficiency.

How Azure Hybrid Benefit Works and How Much You Can Save

Azure Hybrid Benefit (AHB) lets you bring your own Windows Server or SQL Server licenses to Azure if you have active Software Assurance (SA). This means you only pay for the underlying compute infrastructure instead of paying again for the Microsoft license.

What is Software Assurance?

Software Assurance is Microsoft’s licensing program that gives you more than just the right to use a license. It provides benefits like upgrade rights, support, training, and most importantly for FinOps, license mobility. This license mobility allows you to reuse your existing Windows Server or SQL Server licenses in Azure instead of buying new ones. More details can be found here: Microsoft Software Assurance overview.

Windows Server Savings Example

According to Microsoft, Azure Hybrid Benefit for Windows Server can save you up to 40 percent on virtual machines, and even more when combined with Reserved Instances. (Microsoft AHB overview)

Example:

A D8_v3 Windows Server VM costs around $548/month at pay-as-you-go rates. If you apply Azure Hybrid Benefit, the license portion is removed and you only pay for compute. This brings the cost closer to a Linux VM, about $280/month, which is nearly a 50 percent saving.

SQL Server Works Even Better

Azure Hybrid Benefit also applies to SQL workloads:

• SQL Server on Azure Virtual Machines

• Azure SQL Database (vCore-based, provisioned tiers)

• Azure SQL Managed Instance

Microsoft states that customers can save up to 55 percent on SQL workloads with Azure Hybrid Benefit (source). Enterprise Edition customers can also exchange 1 on-premises core license for up to 4 vCores in the cloud, making the discount even more attractive.

Managing Licenses at Scale

For larger organizations, you can centrally manage Hybrid Benefit at subscription or billing scope. This makes it easier to assign licenses where needed, track utilization, and avoid over or under use. Documentation on how to manage this at scale can be found here: Tutorial: Apply Azure Hybrid Benefit for SQL.

Why Licenses Matter in Cloud FinOps

Nothing in IT comes for free. The hardware has a cost, the platform services have a cost, and the software licenses that run on top of those resources also have a cost. In traditional on-premises setups, software licenses were often purchased as part of a larger enterprise agreement and then “forgotten” because they were already paid for upfront. In the cloud, this cost becomes much more visible, since it is directly tied to your monthly invoice.

The benefit of the cloud is its flexibility and scalability, but that also introduces new ways of paying for licenses. If you are not aware of what you already own, you may end up paying twice. This is especially common with lift-and-shift migrations where organizations move workloads into Azure without adjusting their licensing strategy. In such cases, Azure Hybrid Benefit can help you reuse existing licenses and unlock substantial savings.

From a FinOps perspective, the key point is awareness. Just as you would optimize compute or storage usage, you also need to optimize your licensing. Reviewing what you already paid for through Software Assurance, and aligning that with your Azure deployment, can ensure you maximize value from your cloud spend.

Cloud FinOps is not only about technical optimization. It is also about bringing financial accountability and making sure that business decisions reflect the full picture, including the software that powers your workloads.

Fact-based news without bias awaits. Make 1440 your choice today.

Overwhelmed by biased news? Cut through the clutter and get straight facts with your daily 1440 digest. From politics to sports, join millions who start their day informed.

Sign up now!

Please help me by visiting my sponsor. And interested in sponsoring yourself, then visit the sponsor page.

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!

Want more FinOps news? Then have a look at FinOps Weekly by Victor Garcia

FinOps Weekly

Save on Your Cloud Costs with 5 Minutes every Sunday

Subscribe

Hi {{ first_name | there }},

and welcome to this week’s edition of Azure FinOps Essentials.

This time, I’m diving into one of the most foundational (but often overlooked) pillars of cloud cost management: cost allocation.

Whether you’re trying to enable showback to teams, compare costs across projects, or figure out why your bill suddenly spiked, you need more than just a global number. You need visibility. Cost allocation gives you the ability to track, explain, and improve your cloud spending at the right level of granularity.

In this edition, I’ll show how Azure’s billing scopes and tagging can help (or hinder) cost transparency. And I’ll share practical steps to turn chaotic cost data into actionable insights, with real-world patterns I’ve seen work.

Let’s make those Azure bills useful, not just big.

Cheers,

Michiel

Why Cost Allocation Matters (and Fails)

Imagine opening your Azure bill and seeing one giant number. It might be broken down by subscription or service, but you have no idea which team caused what. Which app is driving most of the cost? Which product line? Are you still paying for test environments someone forgot?

This is the default state for many Azure environments.

Cost allocation solves that. It lets you slice your spend by what matters to your business: teams, environments, customers, applications, or projects. It enables:

• Accurate forecasting and budgeting

• Real accountability and chargeback or showback models

• Cost per unit analysis (like cost per user, customer, or API call)

• Detection of anomalies and sudden cost changes at the source

But it only works if you do the groundwork. And in Azure, that groundwork isn’t automatic.

In real environments I’ve reviewed, I often see:

• Subscriptions with zero tagging

• Disks, NICs, and other resources detached from any ownership

• Shared resources that nobody feels responsible for

• Different teams using different tagging standards (or none)

The result? Everyone assumes the cost is “somewhere else” and nobody takes ownership.

How Azure Handles Cost Allocation

Azure supports allocation in two main ways:

1. Billing Scopes

2. Resource Tags

Billing Scopes

Azure lets you organize costs based on hierarchy:

• Subscription

• Resource Group

• Management Group

• Billing account, profile, or invoice section (for MCA)

This structure is helpful, but limited. A single team might span multiple subscriptions. A shared platform might support dozens of apps. You need something more flexible.

Tags

Tags are where real cost allocation happens in Azure.

You can assign metadata like:

project = webshop
team = platform
env = prod
owner = jane.doe
costcenter = 4152

Then you can break down costs by tag in Cost Analysis, Budgets, and Exports. But the power of tagging only works when:

• All resources are tagged

• Tags are consistent

• Tags match your actual cost model

And here’s where most teams struggle.

Common Issues

• Tags not applied to all resources

  Many services like disks, public IPs, or managed identities don’t inherit tags. A Bicep or Terraform template may tag the App Service but forget the plan or VNet.

• Tag key mismatch

  One team uses project, another uses ProjectName, and a third uses Application. Azure treats them as unrelated.

• Tags added too late

  By default, Azure only applies cost allocation tags to future costs. But with MCA, you can enable retrospective allocation to apply tags to historical data.

• Shared services can’t be fairly split

  If your platform team runs a central API gateway or CI/CD runner, you’ll need to split costs based on usage, traffic, or headcount.

Azure won’t solve this for you. But it does give you the tools, if you use them intentionally.

What You Can Do (Developers + FinOps Teams)

If you are a developer or engineer:

• Use IaC (like Bicep or Terraform) to apply tags to every resource. Use modules to enforce consistency.

• Don’t forget to tag supporting resources like disks, IPs, and app service plans.

• Use a standardized tag schema across environments: env, team, project, and owner are great starters.

• Discuss tagging responsibilities with your team. Don’t assume “the platform team will tag it later.”

If you are in FinOps or cloud governance:

• Enable retrospective tagging if you’re using MCA. This ensures that tags can apply to past billing periods.

• Use Azure Cost Analysis to report by tag and educate teams on their own consumption.

• Create budgets by tag so teams get alerts based on their logical ownership.

• Build Azure Workbooks to visualize spend per tag across subscriptions.

• Document and enforce your tagging taxonomy with Azure Policy. It can block or audit deployments that don’t include required tags.

• For shared services, define a showback model using data like API calls, storage usage, or number of users per team.

For example:

A shared Azure Container Registry costs €800 per month. Team A pushed 400 images, Team B pushed 600. You can charge them 40 and 60 percent of the cost respectively.

This is not something Azure does automatically, but with consistent logs and a bit of data modeling, it becomes feasible and transparent.

Cost Transparency Starts With Intent

In FinOps, the goal is not to reduce cost at all costs. It is to align spend with value and make cloud usage measurable, understandable, and actionable.

Cost allocation is where this starts. When teams can see their impact, they can make smarter decisions — and own them.

Azure gives you the mechanisms, but not the model. You have to define what “cost ownership” looks like for your organization. You need collaboration between engineering and finance. You need to make tagging part of your development lifecycle, not a last-minute afterthought.

When done right, cost allocation becomes an enabler. It helps spot waste, fund high-impact projects, and build a culture of shared responsibility. That’s the FinOps mindset in action.

If you're thinking about sponsoring this newsletter, check out the sponsor page for more details!

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!

Want more FinOps news? Then have a look at FinOps Weekly by Victor Garcia

FinOps Weekly

Save on Your Cloud Costs with 5 Minutes every Sunday

Subscribe

Hi {{ first_name | there }}, and welcome to this week’s edition of Azure FinOps Essentials.

This time, we’re diving into a subtle but expensive topic: high availability.

In cloud architecture, it’s easy to default to zone redundancy, failovers, and active-active deployments for every workload. After all, who doesn’t want resilience?

But as you’ll see in this edition, always-on availability comes at a cost, and not all services actually need it. I’ll explore how to make smarter availability choices in Azure, when to scale down complexity, and how this ties directly to your FinOps mindset.

Let’s move from “available by default” to “available with purpose.”

Cheers,

Michiel

The True Cost of Always-On Availability

When teams move to the cloud, there’s an assumption that everything should be highly available by default. Azure makes it easy to deploy across availability zones, add traffic failover, or run active-active workloads in multiple regions. So we do.

But high availability is never free.

Every extra nine in uptime usually comes with extra architecture. You pay for:

• Redundant virtual machines running in multiple zones

• Load balancers that sit idle most of the time

• Replication and failover systems that rarely get tested

• Premium SKUs required for zone redundancy

• Storage replication across regions that may never be used

This leads to a situation where you’re often doubling infrastructure cost for a theoretical failure. And worse, you may be applying the same HA strategy to every workload without considering what actually needs that level of resilience.

I’ve seen environments where low-priority internal tools were given the same zone-redundant, load-balanced footprint as customer-facing APIs. Nobody questioned it. It was just “how we do things in Azure.”

But if you’re treating everything as critical, then nothing really is.

Rethinking Availability as a Business Metric

FinOps encourages us to align technical decisions with business value. Uptime is no different.

Rather than assuming maximum availability, the question should be: how much is enough?

A few prompts to consider:

• What happens if this service is down for 15 minutes? For an hour?

• Is there a financial penalty tied to downtime?

• Would users even notice a short disruption, or can they retry later?

• How frequently has this service actually failed in production?

Your answers will vary per workload. A B2B API with SLA requirements has different needs than a staging environment for internal testing. A marketing campaign site does not need the same architecture as an order processing system.

Once you start thinking in impact rather than principles, your cloud architecture becomes more cost-aware and aligned with user needs.

Availability should never be a checkbox. It should be a conscious tradeoff.

Availability Patterns in Azure that Scale with Purpose

Azure provides plenty of architectural options to right-size availability. The trick is knowing when to use them.

Here are a few examples:

• Zone Redundancy: Many services, such as Azure App Service or Azure SQL, allow for zone redundancy, but it can significantly increase cost. For internal tools or non-critical APIs, it may be better to stick with single-zone deployments.

• Platform-based Resilience: Use Azure Functions on the consumption plan for workloads that don’t need persistent infrastructure. Let the platform worry about reliability.

• Active-Passive Failover: Instead of duplicating workloads across regions, consider queuing mechanisms like Azure Service Bus or Storage Queues. Incoming events are buffered and can be processed when the consumer comes back online.

• Autoscaling and Scale-to-Zero: Azure Container Apps or Kubernetes-based setups can help you avoid idle resource costs. You only pay when something is running.

• Front Door and Traffic Manager: These give you global failover capabilities. Useful for critical external services, but not needed for everything.

• Backup Strategies: Make sure your data is protected, but don’t treat every app as mission critical. Sometimes, restoring from backup is good enough.

Ultimately, high availability should be applied with intent. Not every outage is catastrophic, and not every app needs a 99.99 percent SLA.

Smart Availability Starts with Better Questions

Cloud cost is still usage times rate. With always-on architecture, the usage part silently multiplies in the name of resilience.

From a FinOps perspective, the challenge is not to avoid availability. It is to make it meaningful.

If a system needs five-nines, build for it. But don’t give every service a platinum-grade setup just because you can. That is where cost overruns hide and where simplicity dies.

This is the essence of FinOps. You want to spend money where it creates value. That means:

• Rethinking blanket HA strategies

• Designing for graceful degradation

• Aligning engineering patterns with the actual needs of the business

Availability is not free. But thoughtful availability is worth every cent.

Find out why 1M+ professionals read Superhuman AI daily.

AI won't take over the world. People who know how to use AI will.

Here's how to stay ahead with AI:

1. Sign up for Superhuman AI. The AI newsletter read by 1M+ pros.

2. Master AI tools, tutorials, and news in just 3 minutes a day.

3. Become 10X more productive using AI.

Join 1 million pros and start learning AI

Interested in sponsoring this newsletter, then visit the sponsor page.

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!

Want more FinOps news? have a look at FinOps Weekly by Victor Garcia

FinOps Weekly

Save on Your Cloud Costs with 5 Minutes every Sunday

Subscribe

Hi {{ first_name | there }}, and welcome to this week’s edition of Azure FinOps Essentials.

Before diving in: I’m proud to share that I’ve been re-awarded the Microsoft MVP award in the categories of DevOps and Azure Cost Management. Sharing what I learn, including through this newsletter, plays a big part in that, so thank you for reading and supporting it.

Now, onto this week’s topic.

If you’ve ever opened your Azure bill and been surprised by how much came from Application Insights or Log Analytics, you’re not alone. I’ve seen it across many projects, detailed telemetry piling up without a clear purpose or owner.

This edition is all about reducing monitoring costs without losing insight. I’ll walk through how developers and FinOps teams can work together to make logging more intentional, useful, and cost-effective.

Let’s jump in.

Cheers,

Michiel

Logging Everything, Understanding Nothing

Over the years, I’ve looked into dozens of Azure subscriptions where something odd kept happening.

The most expensive resource wasn’t compute.
Not storage.
Not even a PaaS service like Cosmos DB or App Service.

No — it was Log Analytics.

Month after month, quietly topping the cost charts.

In many cases, diagnostic logs were just enabled by default. They streamed detailed traces from every App Service, Function, Front Door, or SQL database into a central workspace. Nobody really knew why.

Developers set Application Insights to Verbose “just in case.”
Diagnostic settings sent logs to every destination: Log Analytics, Storage, Event Hub. Someone once said it was best practice.

No one ever checked the ingestion volume or looked at the retention policies.

And here’s the kicker:

When I asked the teams whether they were even using those logs, the answer was often no.

They weren’t building alerts.
They weren’t querying data.
They didn’t even have dashboards wired up.

It was observability by habit, not by design.

And it came with a price.

This edition is about exactly that. How observability costs can spiral out of control, and what you can do to make telemetry useful without setting your budget on fire.

Where Logging Costs Lurk in Azure

When we talk about “logging costs” in Azure, we’re usually referring to Log Analytics. This is the engine behind Application Insights and Azure Monitor. It’s powerful, but also easy to misuse.

Here’s where the cost tends to come from:

• Ingestion volume: The more data you send, the more you pay. Every metric, trace, dependency, or custom event has a size. If you’re sending 10,000 requests per second with full trace context, the bill adds up quickly.

• Retention: By default, Log Analytics workspaces store data for 30 days. Extending that to 90 or 180 days multiplies the cost. Often, no one questions why the data needs to be stored that long.

• Duplicate logging: Many teams send the same logs to multiple destinations like Log Analytics, Event Hub, and Blob Storage “just in case.” Each of those adds its own cost.

• No sampling or filtering: Using verbose-level logging in production creates a flood of trace data. Combined with retry logic or bursty traffic, it can lead to massive spikes in data volume.

• Same settings in all environments: Development, test, and production often share the same telemetry configuration. This means verbose logging and long retention are applied everywhere, even where it is not needed.

• Querying patterns: While queries do not incur direct charges, heavy dashboards with inefficient queries can slow down systems and increase backend resource consumption.

Once you know where the cost comes from, you can start applying FinOps principles.

Logging should be a strategic decision, not a default behavior. It should serve the people who actually use the data — developers, site reliability engineers, security analysts — and it should evolve as your system grows.

Next, I’ll walk through how to take back control.

Practical Ways to Reduce Azure Logging Costs

Once you become aware of how much logging contributes to your Azure bill, the good news is this: there is plenty you can do. And it includes both what you log and how you are charged for it.

Start with usage. Developers have direct control over what gets logged and where. A few targeted changes can already make a significant impact:

• Lower log levels in non-critical environments. Do you really need verbose logs in test?

• Tailor retention per environment. Production may need 90 days, but dev might be fine with 3.

• Remove unused diagnostic settings. If no one reads the data, it should not exist.

• Log with intent. Structure logs to be queryable and actionable, not just noise.

• Use sampling or aggregation. Especially for high-volume telemetry like requests or traces.

• Match log level and retention between production and non-production where it actually makes sense. Many teams keep verbose logs and long retention in dev by default.

But usage alone is not the full story. Even well-structured logs can be expensive if you are using the wrong pricing tier.

This is where rate optimization comes in.

Azure Monitor offers three ingestion plans:

Assigning the correct plan to each table is one of the easiest ways to save. Debug or low-importance logs can go to Basic Logs, while alerting tables stay in Analytics Logs for full query and rule support.

If you ingest large volumes, committing to a daily ingestion tier brings real benefits. For example:

• 100 GB per day drops your cost to $1.96 per GB.

• 1 TB per day brings it down to $1.70 per GB.

• At 10 TB per day, you pay $1.57 per GB.

Retention is another cost lever. Analytics Logs include 31 or 90 days by default. For longer retention, switch to long-term storage at just $0.02 per GB per month.

Also keep an eye on indirect charges:

• Queries on Basic and Auxiliary logs cost $0.005 per GB scanned.

• Exporting logs is billed at $0.10 per GB.

• Data transformations that discard more than 50 percent of logs trigger ingestion charges.

None of these are surprising once you know how the pricing works. And all of them are manageable with the right collaboration between engineering and FinOps.

Logging is not just a technical detail. It is an ongoing decision about where to spend your budget and where to get value. Once you take back control, you can make sure that your telemetry adds insight, not just invoice lines.

Conclusion

Usage × Rate = Cost.

That formula still holds true, and logging is no exception.

As a developer, you have direct control over what you log, how long you retain it, and which ingestion plan you choose. As a FinOps practitioner, your role is to surface the costs, highlight opportunities for savings, and guide teams toward smarter defaults.

This is exactly where FinOps and engineering meet. Not by enforcing restrictions, but by enabling better decisions. Together, you can balance the value of observability with the cost of data, ensuring that your telemetry provides clarity instead of cost surprises.

It is not about logging less. It is about logging with purpose.

Interested in sponsoring this newsletter, then visit the sponsor page.

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!

Want more FinOps news, then have a look at FinOps Weekly by Victor Garcia

FinOps Weekly

Save on Your Cloud Costs with 5 Minutes every Sunday

Subscribe

Hi {{ first_name | there }}, and welcome to this week’s edition of Azure FinOps Essentials.

This time, I’m exploring something every cloud architect and developer faces eventually: how to choose the right Azure service when there are multiple ways to solve the same problem.

Should you pick a fully managed platform service or a flexible VM setup? Is Azure Functions the right choice or is an App Service a better fit? These decisions go far beyond technical capabilities. They also shape your cost, scalability, and operational complexity.

In this edition, I’ll walk through some common trade-offs, how they relate to FinOps principles, and why the cheapest option is not always the most cost-effective in the long run.

Let’s take a step back and make smarter choices that align with both engineering needs and business value.

Cheers, Michiel

Optimize global IT operations with our World at Work Guide

Explore this ready-to-go guide to support your IT operations in 130+ countries. Discover how:

• Standardizing global IT operations enhances efficiency and reduces overhead

• Ensuring compliance with local IT legislation to safeguard your operations

• Integrating Deel IT with EOR, global payroll, and contractor management optimizes your tech stack

Leverage Deel IT to manage your global operations with ease.

Download free guide

Too Many Ways to Do the Same Thing

One of the greatest strengths of Azure, and its greatest risks, is the sheer number of services you can choose from to solve a single problem.

Need to host a web application? You could use App Service, Azure Container Apps, AKS, or run it on a VM.

Want to expose it to the internet? Front Door, Application Gateway, Azure CDN, and maybe even Traffic Manager.

Want to store structured data? SQL Database, SQL Managed Instance, Cosmos DB, PostgreSQL, MySQL, or just a file in blob storage.

Technically, all of them work. But cost, operational complexity, and maintainability vary wildly.

And here’s the problem: the more powerful or general-purpose a service is, the more likely it is to be overkill for your actual needs. The moment you choose the wrong building block, you start paying for capabilities you don’t use, and probably won’t.

I’ve seen many teams reach for AKS when Container Apps would have sufficed. Or default to SQL Managed Instance “just in case” they need more control, while barely using any features beyond basic CRUD. And the result? Overhead. Lock-in. Burned budget.

In this edition, I’ll show how to compare similar Azure services through a FinOps lens. Not just to save money, but to pick the right foundation that scales with your real needs, without overengineering your cloud estate.

Which Azure Service? It Depends…

Picking the right Azure service isn’t always easy. Azure gives you ten ways to do the same thing, each with very different cost profiles. If you’ve ever wondered “Should I use App Service, Container Apps, or AKS?”, you’re not alone.

Here’s a FinOps-friendly way to approach it:

• Start simple.

  If you’re deploying a web app and App Service fits your needs, use it. It’s affordable, scales well, and doesn’t need a full operations team. Container Apps are a great next step if you need containers and scale-to-zero behavior. AKS makes sense only when you truly need Kubernetes.

• Recognize when flexibility adds cost.

  SQL Managed Instance gives you full SQL Server compatibility. But if you’re not using all those features, a serverless Azure SQL Database might cut your bill in half. The same goes for Cosmos DB. It’s powerful, but expensive when overprovisioned.

• Be cautious when combining services.

  Stacking Azure Front Door with Application Gateway sounds appealing. But do you really need global routing and per-path logic? Often, just one of the two will do the job.

• Replace always-on with event-driven when possible.

  Azure Data Factory is great for ETL, but if your job only runs hourly, Durable Functions or Logic Apps may offer the same result at a much lower cost.

The point isn’t to pick the “best” service. It’s to choose the one that fits your actual workload and revisit that decision as your application evolves.

FinOps Is About Fit, Not Flash

In a cloud environment full of options, it’s easy to default to the most flexible or powerful service. But FinOps reminds us that the best choice is the one that fits the need.

That does not always mean the lowest cost. It means making trade-offs deliberately. Do you need global reach or just regional presence? Does your app require constant compute or can it sleep between events? Is high availability essential or just a nice-to-have?

These are not just technical questions. They are financial ones too. Each decision affects your cost profile, your scalability, and how much operational effort is needed.

So when choosing a service, consider more than the features. Ask what your workload actually needs, what your team can support, and what brings the most business value.

Because in the end, FinOps is not about spending less. It is about spending where it counts.

Unbiased Business Insights, Every Week

Get a weekly knowledge digest of business insights from 1440’s Business & Finance newsletter. Expect concise rundowns, context-rich visuals, and curated links to keep you ahead of the finance curve. Join 1440 for crisp explanations of business trends —no MBA required.

Sign Up Here

Please help me by visiting my sponsor. And interested in sponsoring yourself, then visit the sponsor page.

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!

P.S. I have another newsletter about GitHub, Azure, and .NET news. Subscribe as well to keep informed:

MindByte Weekly Pulse: Quick GitHub, Azure, & .NET Updates

Get to the heart of GitHub, Azure, and .NET with MindByte Weekly Pulse. Every week, find concise, expert-curated insights and trends straight in your inbox. Designed for IT professionals, it's your...

Subscribe

Want more FinOps news, then have a look at FinOps Weekly by Victor Garcia

FinOps Weekly

Save on Your Cloud Costs with 5 Minutes every Sunday

Subscribe

Hi {{ first_name | there }}, and welcome to this week's edition of Azure FinOps Essentials! 🎉

This week’s topic comes straight from the trenches. I was recently faced with a simple request: accept mutation events from an external company whenever their data changed. A classic integration scenario, right?

The obvious answer would have been to spin up a web application, expose an HTTP endpoint, and process the incoming payloads in real time. But I didn’t want to manage uptime. I didn’t want to scale for bursts. And I definitely didn’t want to pay for an idle service sitting around waiting for requests.

So I took a different path. And that decision turned into a perfect example of how event-driven architecture isn’t just elegant, but cost efficient too.

Cheers,
Michiel

Global payroll complexity? Here’s the playbook.

Managing global payroll shouldn’t mean juggling vendors and compliance risks. Deel, recognized in the Gartner® Market Guide for Multicountry Payroll Solutions, helps finance teams automate payments, standardize reporting, and stay compliant in 100+ countries. Get key insights from industry experts to future-proof your payroll strategy.

Download the Report

When Always-On Doesn’t Make Sense

In many cloud projects, especially integrations between systems, the default approach is to build something that’s always available. A classic pattern: spin up a web app, expose an HTTP endpoint, and wire it into your deployment pipeline.

It works, but it comes at a cost. Literally.

Services that sit idle for most of the day still generate compute and hosting costs. They require uptime guarantees. Monitoring. Maintenance. And if they happen to be offline during a deployment or a failure, they cause backpressure on the sender — or worse, dropped data.

I recently ran into exactly this scenario.

Another company needed to notify us whenever data was mutated on their end. The obvious route would have been to create a web service that listens for their payloads and processes them directly. But that came with all the usual problems:

• What if the service is redeploying?

• What if they send hundreds of requests at once?

• What if we need to throttle or delay processing?

This wasn’t a high-throughput integration. The events were important, but not urgent. And we didn’t need instant processing — just eventual consistency. Yet the default solutions felt like overkill.

I needed a design that wouldn’t tie cost to uptime. That wouldn’t penalize me for being temporarily unavailable. And that wouldn’t require a fleet of always-on services.

Idle by Design: Turning the Pattern Inside Out

The integration I mentioned didn’t require low-latency processing. It needed reliability, simplicity, and resilience to bursts or downtime.

Instead of building a web app and keeping it warm 24/7, I inverted the model.

Here’s what I did:

• API Management acted as the front door. It exposed a stable HTTP endpoint to the other party.

• That endpoint didn’t route to a backend service. Instead, it pushed the incoming payload straight into a queue.

• From there, a queue-triggered Azure Function picked up the message and processed it — on its own terms, whenever resources were available.

The result?

• Zero idle compute cost. The Azure Function only runs when needed.

• No coupling between sender and receiver. If I’m redeploying or down, nothing breaks — messages accumulate safely.

• No need to overprovision. A sudden spike in requests doesn’t overwhelm anything. Azure Functions scale with demand (within defined bounds).

And since API Management was already in place and shared across services, there was no additional hosting cost. The queue is nearly free. The function execution is charged by invocation.

This is what Idle by Design means to me: intentionally building systems that don’t need to run unless there’s something to do.

It’s an architectural decision — but it’s also a FinOps one.

Applying Idle-by-Design in Azure: Patterns That Scale Down to Zero

When we think about modern systems, we often focus on scalability under load. But FinOps-minded teams should also ask: “How does my system behave when there’s no traffic?”

That’s the core of Idle by Design — building systems that cost nothing (or close to it) when idle, without compromising on responsiveness or reliability.

Azure offers several services and patterns to help you achieve that:

1. Event-Driven Ingestion with Minimal Overhead

Instead of building and hosting always-on APIs, use Azure API Management to receive data and route it immediately to:

• Azure Service Bus – reliable queuing with dead-lettering and retries.

• Event Grid – for high-fanout scenarios or integrations across services.

• Storage Queues – for simple, ultra-low-cost message delivery.

These services absorb bursts and decouple systems, eliminating the need for persistent frontend infrastructure.

2. On-Demand Processing with Azure Functions

Once your data is queued or published, process it with Azure Functions. Key benefits:

• Triggered only when work arrives.

• Scales automatically, down to zero.

• Integrates directly with queues, blobs, HTTP, Event Grid, and more.

Combine with Durable Functions for orchestration or long-running workflows without background compute.

3. Zero-Idle Hosting

If you do need to host an API or background worker, choose services that scale to zero:

• Azure Container Apps: Handles HTTP or background jobs, scales to zero by default.

• Azure App Service with Pre-warmed Instances: Optional if you need predictable startup, but idle cost is higher.

• Azure Kubernetes Service (AKS) with KEDA: For advanced use cases, scale pods based on queue length, HTTP traffic, or even custom metrics.

4. Storage That Sleeps

Data at rest shouldn’t break the bank:

• Use Azure Blob Storage with lifecycle policies to transition unused data to Cool or Archive tiers.

• Choose serverless Cosmos DB for event-based, rarely accessed documents.

By combining serverless, event-driven, and elastic Azure services, you create systems that:

• Handle scale without overprovisioning.

• Pause compute when not needed.

• Minimize waste while maximizing responsiveness.

This pattern isn’t limited to one niche case. It’s an architectural mindset that can be applied across APIs, data ingestion, background jobs, and even databases.

Cost-Efficient by Design, Not by Accident

FinOps isn’t just about slashing cloud bills. It’s about making conscious, data-informed decisions that align engineering with business value.

You may decide that cost isn’t your top priority — maybe performance, resilience, or speed-to-market matter more. That’s valid. But the key is to know the trade-offs.

What’s powerful about Idle-by-Design patterns is that they often deliver benefits beyond cost:

• Greater reliability through decoupled services and retry mechanisms.

• Improved scalability by reacting to demand instead of provisioning for peak.

• Smoother operations thanks to minimal infrastructure to maintain.

In my own project, I didn’t choose this pattern just to save a few euros. I wanted to avoid running a full web app, reduce operational complexity, and stay responsive even when my system wasn’t available. The fact that it’s nearly free to run when idle? A welcome bonus.

So whether you’re driven by budget constraints or engineering elegance, embracing event-driven, idle-aware architectures can move you closer to both.

And that’s the essence of FinOps: maximizing business value, not minimizing spend.

Smarter Investing Starts with Smarter News

The Daily Upside helps 1M+ investors cut through the noise with expert insights. Get clear, concise, actually useful financial news. Smarter investing starts in your inbox—subscribe free.

Join 1M+ readers today.

Please help me by visiting my sponsor. And interested in sponsoring yourself, then visit the sponsor page.

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!

P.S. I have another newsletter about GitHub, Azure, and .NET news. Subscribe as well to keep informed:

MindByte Weekly Pulse: Quick GitHub, Azure, & .NET Updates

Get to the heart of GitHub, Azure, and .NET with MindByte Weekly Pulse. Every week, find concise, expert-curated insights and trends straight in your inbox. Designed for IT professionals, it's your...

Subscribe

Want more FinOps news, then have a look at FinOps Weekly by Victor Garcia

FinOps Weekly

Save on Your Cloud Costs with 5 Minutes every Sunday

Subscribe

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

You’ve cleaned up your unused resources. You’ve optimized SKUs. You’ve tagged everything with military precision. Yet… your cloud bill still spikes in ways you can’t explain.

This week, we’re exploring a more subtle source of cloud spend: architectural patterns that are operationally sound but financially expensive. They’re not misconfigurations or forgotten VMs, but design choices that unintentionally drive up costs.

Cheers,
Michiel

Get Your Free ChatGPT Productivity Bundle

Mindstream brings you 5 essential resources to master ChatGPT at work. This free bundle includes decision flowcharts, prompt templates, and our 2025 guide to AI productivity.

Our team of AI experts has packaged the most actionable ChatGPT hacks that are actually working for top marketers and founders. Save hours each week with these proven workflows.

It's completely free when you subscribe to our daily AI newsletter.

Subscribe to get instant access

When Sound Cloud Patterns Quietly Inflate Spend

Not every cost spike stems from waste or bad practice. Often, it’s the result of architectural patterns working exactly as intended, just not from a financial perspective.

These are patterns built for resilience, scale, observability, or developer experience. The issue is not that they fail, but that they succeed in ways that quietly increase consumption.

Consider a few examples:

• Retry storms

  One request fails. The client retries. So does the proxy. So does every downstream microservice. What began as one request ends as ten. Each one billed.

• Aggressive health probes

  Load balancers and gateways check backend health every few seconds. With enough instances and components, this generates a constant stream of synthetic traffic that produces logs, metrics, and downstream invocations.

• Chatty microservices

  A single user action calls ten different services. Each call generates diagnostic traces, logs, and often additional internal calls. Billing models based on execution count or message volume quickly add up.

• Over-instrumentation

  Every component logs everything, all the time. Sampling is off. Retention is long. Logs are sent to multiple destinations. Your observability stack becomes one of your biggest cloud consumers.

• Cold-start mitigation

  To avoid delays in serverless workloads, you send fake traffic to keep instances warm. It works operationally, but each ping still consumes resources and may trigger downstream effects.

These aren’t anti-patterns. They’re mature, often recommended practices. But without cost-awareness, they can behave like silent cost multipliers.

If you’ve already optimized usage and right-sized infrastructure but still see unexplained cost trends, it’s time to examine how your architecture might be working against your budget.

Designing for Resilience and Efficiency

You don’t have to choose between reliability and cost control. The goal is not to strip down your architecture, but to make deliberate, cost-aware decisions about how it behaves. That starts with visibility.

1. Make the invisible visible

Start by quantifying architectural behaviors. How many requests are internal versus external? Which logs are written the most? What triggers downstream calls?

Use tools like Azure Monitor, Application Insights, or third-party observability platforms to trace patterns, not just performance. Correlate telemetry with cost data to find patterns that align with spend spikes.

Key metrics to look for:

• Request fan-out ratios

• Retry frequency and duration

• Internal service-to-service traffic volume

• Log and metric ingestion rates

2. Introduce guardrails

Once you identify the patterns, introduce controls:

• Add retry budgets: Cap the number of retries per call chain. Use exponential backoff and circuit breakers to avoid amplification.

• Throttle health probes: Lower the frequency of synthetic checks, especially in off-hours or for low-impact services. Or make them conditional based on recent activity.

• Tune observability: Apply log sampling, reduce retention, exclude known-noise patterns, and consolidate destinations. You can also delay ingestion to batch processing windows if real-time is not needed.

• Debounce internal events: Use message queues or event aggregation to avoid storms of duplicate work triggered by the same upstream event.

3. Review architectural intent

If a feature or component requires constant synthetic traffic to work reliably, consider whether the architectural pattern still fits your current usage model.

For example:

• Could cold-starts be tolerated in certain paths?

• Are there serverless components that would be cheaper on a dedicated SKU?

• Is the retry logic spread across multiple layers with inconsistent behavior?

These are architectural questions. And they’re best solved through collaboration between architects, engineers, and business roles.

Awareness Beats Assumption

FinOps is not about racing to the lowest possible bill. It’s about maximizing business value. Sometimes, high availability, redundancy, or aggressive retry logic are worth the cost, because the business demands it. Other times, they’re artifacts of old assumptions that no longer hold true.

What matters is that those decisions are made intentionally.

Too often, cost becomes an afterthought in architecture discussions. But the truth is, architecture drives usage, and usage defines cost. If you design without cost in mind, you may be optimizing for a system that delivers technical elegance at an unsustainable price.

This is where FinOps shines: bringing cost awareness into architectural decisions without slowing them down. When architects, engineers, and FinOps practitioners collaborate, patterns like excessive retries, noisy health checks, and overzealous observability become design considerations, not surprises on the invoice.

So no, you don’t have to gut your design. But you do need to understand what it’s doing. And what it’s costing you.

FinOps helps you do exactly that.

Turn Anonymous Website Visitors Into Customers With Our AI BDR

Stop letting anonymous site traffic slip away. Our AI BDR Ava identifies individuals on your website without them providing any contact information and autonomously enrolls them into multi-channel sequences.

She operates within the Artisan platform, which consolidates every tool you need for outbound:

• 300M+ High-Quality B2B Prospects, including E-Commerce and Local Business Leads

• Automated Lead Enrichment With 10+ Data Sources

• Full Email Deliverability Management

• Multi-Channel Outreach Across Email & LinkedIn

• Human-Level Personalization

• Convert warm leads into your next customers.

Hire Ava to slash costs & boost productivity.

Please help me by visiting my sponsor. And interested in sponsoring yourself, then visit the sponsor page.

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!

P.S. I have another newsletter about GitHub, Azure, and .NET news. Subscribe as well to keep informed:

MindByte Weekly Pulse: Quick GitHub, Azure, & .NET Updates

Get to the heart of GitHub, Azure, and .NET with MindByte Weekly Pulse. Every week, find concise, expert-curated insights and trends straight in your inbox. Designed for IT professionals, it's your...

Subscribe

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

This week’s edition is a bit different — it’s sponsored by a product I think deserves your attention.

We often focus on usage optimization in FinOps: cleaning up waste, autoscaling, right-sizing, and choosing the right services. But cloud cost is always a simple formula: usage × rate. And while usage gets a lot of love, optimizing the rate, through commitments like reservations and savings plans, is where major savings hide.

But committing to multi-year plans can be risky, especially when your cloud usage shifts. What if you could get better rates without locking yourself in?

That’s exactly where Archera comes in. They offer 30-day, insured commitment plans that give you flexibility, guaranteed savings, and protection against forecast errors — all wrapped in a FinOps-first platform.

Let’s take a look at how Archera simplifies rate optimization and helps you save with confidence.

Cheers, Michiel

From DevOps to FinOps: A Personal Shift

I’ve been a software developer for over 20 years, building and deploying applications across industries, teams, and tech stacks. When the shift from traditional data centers to cloud infrastructure started, my focus was squarely on DevOps — automating deployments, improving reliability, and shortening feedback loops. Cost wasn’t part of the conversation. We cared about uptime and throughput, not euros per vCPU.

That changed a few years ago when I worked on a project as a consultant at Xebia. A customer asked the deceptively simple question: “Are we cost-effective in the cloud?” The answer, of course, was no, not because they were careless, but because trade-offs had been made along the way. Like many, they had optimized for speed and scale, or developer productivity, but not always cost.

That question sparked my interest in FinOps, especially in the areas where engineering teams can directly influence usage: reducing waste, resizing resources, and improving scaling logic. These are impactful levers, and developers should absolutely use them.

But there’s another side to cloud cost: the rate you pay. And that’s where commitments, discounts, and pricing models come in. Even with optimized usage, you’re leaving money on the table if you ignore the pricing layer.

This edition dives into that side of FinOps and looks at how Archera helps you approach it with confidence, flexibility, and automation.

Beyond usage: why rate optimization matters

At its core, cloud cost is just a simple equation: usage × rate.

I’ve written extensively about usage optimization: cutting cloud waste, resizing resources, and scaling intelligently. But there’s another lever that often gets less attention: the rate you’re paying.

Rate optimization is all about reducing your price per unit. Instead of sticking with the default pay-as-you-go model, you commit to using resources or spending a certain amount, and in return, you get a discount. In Azure, this comes in two forms:

• Reservations: Commit to specific compute SKUs, sizes, and regions, and save up to 72%.

• Savings Plans: Commit to a spend amount (not tied to specific SKUs) and save up to 65%.

Reservations give you deeper discounts, but they’re more rigid. Savings plans are more flexible, but offer slightly smaller savings. Either way, you’re trading commitment for lower prices.

Sounds like a no-brainer, right? Not always.

Deciding how much to commit and for how long can be risky. The moment you overcommit, you start paying for unused capacity. And when these decisions are made centrally by a FinOps team, it gets even harder to match commitments to real, fluctuating usage.

Microsoft helps with Cost Advisor recommendations, but those still lock you into 1- or 3-year terms. What if you want to commit for just 30 days instead?

That’s exactly the flexibility Archera brings to the table, helping you unlock discounted rates without long-term lock-in or guesswork.

How Archera helps you optimize rates with flexibility and confidence

Archera approaches the rate optimization challenge in a refreshing way. The platform has been operating for years, first on AWS and now fully supporting Azure, with a focus on simplifying commitments while giving teams the confidence to act.

Getting started is simple: you create an account for free, connect your billing account or subscriptions, and let Archera ingest usage data. From there, it provides immediate visibility into your current reservations, usage patterns, and missed opportunities, all without charging anything for scanning, forecasting, or recommendations.

What makes Archera stand out is its flexible commitment model. Traditional Azure commitments lock you into 1- or 3-year plans. Archera, on the other hand, lets you opt into as short as 30-day commitments with their Guaranteed Reserved Instances (GRIs) and Guaranteed Savings Plans (GSPs).

The Archera Commitment planner screen listing different plans

These insured commitments come with a premium, which is only charged if you actually save money, applied directly through the Azure Marketplace, so the cost appears on your cloud bill. If, after the minimum term, the commitment didn’t result in savings, Archera automatically reimburses the net difference. That’s their MoneyBack Guarantee in action. You can also automate reapplying these 30-day commitments, ensuring you continuously benefit from potential savings without manual effort.

If you prefer to stick to Microsoft’s native discounts, Archera also allows you to buy Azure Savings Plans directly through the platform, again, without charging any markup or fee.

The platform supports a wide range of Azure services: from common workloads like Virtual Machines, App Services, SQL Databases, and Container Apps, to more specialized services such as Azure Databricks, Cognitive Services, and Storage Accounts. Commitments made through Archera are yours; they appear directly on your Azure invoice.

Archera also brings long-term forecasting and scenario modeling into your FinOps workflow. You can simulate growth patterns, evaluate the financial impact of upcoming changes, and model commitment strategies to align with future plans. Their automation tools let you define policies (e.g., “automate low-risk 30-day plans on staging environments”) while still maintaining oversight. And if you need help? Dedicated FinOps and Customer Success support is included at no cost.

In short, Archera gives you confidence, flexibility, and control. You choose what to commit to, how long to commit, and when to automate with the assurance that if something doesn’t save you money, you’re protected.

Final thoughts

Archera is a focused FinOps SaaS platform with one clear mission: to help you reduce your cloud spend through short-term, insured savings plans and reservations. It doesn’t try to be everything. Instead, it goes deep on one of the most impactful levers in FinOps: rate optimization.

If you expect your setup to remain relatively stable over time, Archera’s 30-day commitment plans are hard to ignore. Once you pass the break-even point (typically around 22–24 days), the savings start adding up, even after the small insurance premium.

And if things unexpectedly change and you don’t fully utilize the commitment? The MoneyBack guarantee kicks in automatically, no forms or follow-ups required.

Explore more or sign up for a free account here:

👉 https://www.archera.ai/azure-cost-management

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!

P.S. I have another newsletter about GitHub, Azure, and .NET news. Subscribe as well to keep informed:

MindByte Weekly Pulse: Quick GitHub, Azure, & .NET Updates

Get to the heart of GitHub, Azure, and .NET with MindByte Weekly Pulse. Every week, find concise, expert-curated insights and trends straight in your inbox. Designed for IT professionals, it's your...

Subscribe

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

This time, I’m taking a closer look at cost anomaly detection in Azure.

While budgeting and forecasting are important, unexpected spikes in cloud spending can still happen — and early detection is crucial to avoid nasty surprises on your invoice.

We’ll explore why anomaly detection matters, what types of anomalies are common in Azure environments, which tools (both native and third-party) you can use, and most importantly — how you should respond when an anomaly is found.

Proactive cost management isn’t just about optimization; it’s about being ready to act before small issues become expensive problems.

Cheers, Michiel

The easiest way to stay business-savvy

There’s a reason over 4 million professionals start their day with Morning Brew. It’s business news made simple—fast, engaging, and actually enjoyable to read.

From business and tech to finance and global affairs, Morning Brew covers the headlines shaping your work and your world. No jargon. No fluff. Just the need-to-know information, delivered with personality.

It takes less than 5 minutes to read, it’s completely free, and it might just become your favorite part of the morning. Sign up now and see why millions of professionals are hooked.

Check it out

Please help me by visiting my sponsor. And interested in sponsoring yourself, then visit the sponsor page.

Why Finding Anomalies Matters

Imagine this:

Your team deploys a small feature late Friday afternoon. Everything looks good.
You head into the weekend feeling productive. ☀️

Monday morning, your Azure billing dashboard has a surprise for you:
A 5x cost increase.
A forgotten autoscale setting spun up 50 extra instances overnight.

This isn’t rare.
In the cloud, cost anomalies don’t gently knock on the door.
They kick it in—fast and unexpected.

That’s why anomaly detection is essential.

Anomalies aren’t just about unexpected costs.
They signal:

• Architectural mistakes you didn’t catch during review.

• Misbehaving apps eating resources.

• Security issues like unintended usage patterns.

• Broken processes where no one noticed a config error.

Every euro you lose to an undetected anomaly is one you can’t invest in innovation, growth, or customer value.

Good anomaly detection flips the game:

• From reacting to bills, to proactively controlling spend.

• From finding problems months later, to fixing them in hours.

• From frustration to operational excellence.

In short:

Cloud cost anomalies are inevitable. How fast you spot and act on them defines your maturity.

Exploring Different Types of Anomalies in Azure

When it comes to cloud cost management, not all anomalies are created equal. In Azure, several types of unexpected cost patterns can arise — and spotting them early is key to minimizing impact.

Here are the most common categories to keep an eye on:

1. Usage Spikes

Sudden increases in consumption are among the most visible anomalies. Examples include a burst of compute hours, sudden data egress traffic, or a rapid increase in storage transactions. A newly deployed service, a runaway script, or even an accidental configuration change can cause these.

2. Unexpected Resource Creation

New virtual machines, databases, storage accounts, or other services that suddenly appear in your environment can be major red flags. Sometimes they’re intentional but forgotten about. Other times, they are the result of automation gone rogue or human error.

3. SKU or Tier Changes

Switching from a lower-cost SKU to a premium version — whether for VMs, databases, or storage accounts — can dramatically increase costs. This often happens during scaling, reconfigurations, or by mistakenly selecting the wrong option during deployment.

4. Forgotten Resources

Idle but still running services, non-prod environments left active over weekends, unattached disks, and unused IP addresses can slowly bleed your budget dry. They don’t always cause a sudden spike, but their cumulative impact is significant over time.

5. Anomalies in Reservations and Savings Plans

If a reservation is suddenly not applied as expected, or if a Savings Plan commitment is missed, costs can surge back to pay-as-you-go rates without warning.

6. Data Egress and Networking Costs

Networking costs, particularly inter-region data transfer or traffic leaving Azure, can spike without clear visibility. Moving large datasets or misconfigured services can generate surprising egress fees.

7. Logging and Monitoring Surprises

Diagnostic logs, Application Insights telemetry, and other monitoring data are critical — but they can explode in volume if left unchecked. A misconfigured service that logs every heartbeat instead of every minute can triple your monitoring bill overnight.

How to Detect Anomalies in Azure

Once you know what types of anomalies to expect, the next step is setting up ways to actually catch them early. Azure offers native capabilities, and there’s a growing ecosystem of FinOps-focused tools to help.

Here’s how you can stay ahead:

1. Azure Cost Management + Billing Alerts

Azure’s standard budgets and alerting capabilities let you trigger notifications when costs cross thresholds.

🔹 Tip: Don’t just set one big budget alert — create granular alerts per subscription, resource group, or even per tag category like Environment=NonProd.

2. Azure Advisor

Azure Advisor reviews your resource configurations and identifies savings opportunities. Think about oversized VMs, unattached disks, or unoptimized networking setups.

🔹 Tip: Tie Advisor recommendations into your regular operational reviews — many anomalies first show up as inefficiencies.

3. Azure Monitor and Log Analytics

Sometimes cost anomalies are preceded by metric anomalies. Sudden increases in CPU, storage consumption, or egress traffic can signal a future billing spike. Azure Monitor and Log Analytics let you track these technical metrics and set alerts based on abnormal behavior.

🔹 Tip: Build simple KQL queries to monitor unexpected surges in key services.

4. Azure Cost Anomaly Detection

Azure also provides Cost Anomaly Detection — a service where machine learning algorithms proactively detect unusual spending patterns across subscriptions, resource groups, and services. You define the scope and get notified when something looks suspicious.

🔹 Tip: Start small. Enable detection on high-cost subscriptions or critical resource groups first, then expand coverage.

5. Third-Party and Open-Source Tools

If you want more flexibility, deeper integrations, or better dashboards, the FinOps ecosystem offers great options:

• Turbo360: Azure-native monitoring, deep cost analysis, and anomaly detection — including visual correlation across services.

• FinOps Toolkit by Microsoft: An open-source collection of templates, scripts, and dashboards — includes anomaly detection templates, FinOps KPIs, and pre-built Power BI connectors.

• CloudHealth (VMware): Aggregates billing, cost, and operational data across multi-cloud environments.

• Apptio Cloudability: Enterprise-grade FinOps platform with anomaly detection, showback/chargeback, and forecasting capabilities.

• Harness Cloud Cost Management: Focuses on integrating cost detection into CI/CD pipelines and DevOps workflows.

🔹 Tip: A hybrid approach works best. Use Azure-native tools for real-time detection and combine them with specialized FinOps platforms for broader optimization and reporting.

What to Do When an Anomaly is Detected

Finding an anomaly is only step one. The real value comes from how you respond. Here’s a practical flow to handle anomalies effectively:

1. Investigate Quickly

An anomaly doesn’t always mean a problem. It could be legitimate growth, a project launch, or a one-off event.

🔹 Start by checking:

• Which service/resource caused the spike?

• When exactly did it start?

• Was there a known deployment, migration, or usage increase around that time?

2. Engage the Right People

Bring in the teams who own the impacted resources. Use tagging to quickly find the owner or responsible team.

🔹 Tip: Strong tag hygiene (e.g., Owner, Environment, CostCenter) makes root cause analysis 10x faster.

3. Confirm and Contain

If the anomaly is a misconfiguration (e.g., an oversized database or unrestricted scaling rules), fix it immediately:

• Scale down resources

• Update scaling rules

• Pause non-critical services

• Review autoscaling settings

4. Communicate

Even if it’s a false alarm, communicate clearly to stakeholders. Share what happened, why, and what actions (if any) were taken.

🔹 Tip: Build trust by showing transparency — anomalies are opportunities to learn and improve.

5. Implement Preventive Measures

After the incident:

• Adjust budget alerts, anomaly sensitivity settings, or monitoring thresholds.

• Add policy controls (like Azure Policy) to enforce tagging, cost limits, or configuration standards.

• Update your knowledge base so the same issue doesn’t happen again.

Conclusion: Catching Costs Before They Catch You

Cost anomalies are often an early warning sign — like smoke before fire.

By investing in detection, investigation, and rapid response, you build a resilient and responsible cloud practice.

Anomalies will happen. That’s normal.

But when you build awareness, automate detection, and foster collaboration across teams, you turn anomalies from potential disasters into valuable moments for optimization.

Start learning AI in 2025

Keeping up with AI is hard – we get it!

That’s why over 1M professionals read Superhuman AI to stay ahead.

• Get daily AI news, tools, and tutorials

• Learn new AI skills you can use at work in 3 mins a day

• Become 10X more productive

Sign up and start mastering AI

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!

P.S. I have another newsletter about GitHub, Azure, and .NET news. Subscribe as well to keep informed:

MindByte Weekly Pulse: Quick GitHub, Azure, & .NET Updates

Get to the heart of GitHub, Azure, and .NET with MindByte Weekly Pulse. Every week, find concise, expert-curated insights and trends straight in your inbox. Designed for IT professionals, it's your...

Subscribe

Hi {{ first_name | there }}, and welcome to this week’s edition of Azure FinOps Essentials! 👋

This week, I’m diving into a question I hear often: what’s the difference between DevOps and FinOps—and do they even belong together?

We already expect developers to think about security. But what about cost? In this edition, I’ll unpack how these two disciplines actually complement each other, and why bringing them closer together—what I like to call DevFinOps—makes a lot of sense.

We’ll explore where the practices overlap, how they can support each other, and how to start embedding cost awareness into development workflows—without slowing things down.

Let’s connect the dots between speed, ownership, and cloud value.

Cheers, Michiel

Wait… Another “Ops”?

Just when you got DevOps running smoothly—along comes FinOps.

Yet another discipline. Another acronym. Another framework.

You might ask:

• Are these two things competing?

• Is FinOps just finance telling engineers to spend less?

• Or is this just DevOps with a budget report tacked on?

It’s a common reaction. And it makes sense.

At a glance, DevOps and FinOps seem to live in different worlds. One focuses on velocity and uptime, while the other focuses on cost awareness and financial accountability.

But here’s the thing: both are born out of the same pain—cloud complexity.

Cloud gives you flexibility, speed, and scale. But it also introduces new challenges: spiraling costs, opaque pricing, infrastructure sprawl, and hard-to-answer questions like “what are we actually paying for?”

That’s where FinOps steps in.

Let’s look at the formal definition, straight from the FinOps Foundation:

Key ideas here:

• It’s a cultural practice, not a tool or dashboard.

• It’s about collaboration, not control.

• It’s focused on value, not just cost reduction.

• It empowers teams with data and context—so they can make smart decisions early.

In other words, FinOps isn’t about locking down infrastructure or auditing cloud bills after the fact. It’s about shifting cost awareness left—into the development cycle—and helping engineers see the impact of their choices before they hit production.

Sound familiar?

Let’s now look at how DevOps fits in.

According to AWS:

Like FinOps, it’s cultural.

It’s about autonomy, collaboration, and measuring outcomes. It values fast feedback loops, automation, and clear ownership. The famous DevOps mantra—you build it, you run it—is about pushing decisions and responsibility closer to the people who actually write the code.

And much like FinOps, it’s not just a new title or a new team—it’s a new way of thinking.

So no, FinOps isn’t replacing DevOps. And DevOps isn’t complete without cost in the picture.

They’re not rivals. They’re more like siblings.

Why FinOps and DevOps Actually Belong Together

Once you move past the buzzwords, you start to see the overlap between DevOps and FinOps. They may look like different practices—but under the surface, they share the same DNA.

1. They both focus on delivering business value

DevOps aims to ship software faster and safer. FinOps focuses on doing that in a financially responsible way. The end goal is the same: delivering value to the business.

DevOps asks: Can we move quickly and deliver reliably?

FinOps adds: Are we making smart, sustainable choices while doing it?

Speed without awareness can lead to inefficiency. Control without agility becomes friction. Both are needed to create impact.

2. They both thrive on fast feedback loops

DevOps emphasizes fast cycles: write code, test, deploy, learn, improve. FinOps pushes to make cloud cost feedback part of that loop.

Instead of learning about budget overruns weeks later in a spreadsheet, engineers can see cost implications directly in their workflow—whether that’s a cost diff in a pull request or an alert during a build pipeline.

Bringing cost awareness into the development lifecycle helps teams make better decisions earlier.

3. They both depend on strong collaboration

DevOps broke the silos between development and operations. FinOps goes a step further—connecting engineers with finance, procurement, and business leadership.

In this model, engineers might review cost changes the same way they review performance or security impacts. Finance teams, in turn, become better informed about technical decisions.

That said, collaboration doesn’t mean everyone owns everything.

There is still a place for dedicated FinOps teams, just like many organizations have platform teams within a DevOps culture. These teams support others by creating tooling, enforcing policies, and building shared services.

FinOps teams can:

• Drive rate optimization efforts (e.g., commitment management)

• Set tagging and budgeting standards

• Educate teams about cloud cost patterns

• Maintain dashboards and reporting pipelines

Platform teams do the same for infrastructure and developer experience. They don’t remove responsibility from other teams—they enable it.

4. They both rely on automation

DevOps automates deployment, testing, infrastructure, and more. FinOps rides along that automation layer, integrating cost checks, tagging validations, and policy enforcement directly into those same pipelines.

Manual processes won’t scale when you have dozens of teams and services. Automation is what brings cost governance to scale without slowing teams down.

5. They both require a mindset shift

You don’t “implement” DevOps or FinOps. They aren’t projects. They are cultures that grow inside your organization.

They require a shared sense of ownership, leadership support, education, and above all—patience.

Both succeed only when people are empowered to make decisions and are equipped with the right information and tools to do so.

Getting Started with DevFinOps

It’s easy to get overwhelmed by all the “Ops” disciplines—DevOps, FinOps, SecOps. But the pattern is clear: these are not siloed functions. They’re shared responsibilities that need to be embedded into how teams work day-to-day.

Just as security has evolved into SecOps—a cross-cutting concern that touches every part of software delivery—cost awareness should be no different. Enter DevFinOps: an emerging mindset where engineering and finance collaborate early and often to make cost-informed decisions.

So where do you begin?

1. Start with awareness

Most engineers don’t ignore cost because they don’t care—it’s because they’ve never been shown how cloud costs work.

Talk about costs in sprint reviews. Include cost impact in architecture discussions. Bring cloud economics into onboarding for new engineers. Make cost visible, and people will naturally start making better decisions.

2. Educate teams

Make sure engineers understand the basics:

• What are SKUs, regions, and tiers in Azure?

• How do services like storage or networking actually incur cost?

• What’s the difference between actual and amortized cost?

You don’t need finance training to make better cloud decisions—just context.

A great entry point: walk through a real bill together. See what’s driving cost and what you can optimize.

3. Provide insights

Dashboards help, but only if they’re tailored and accessible. A weekly report in someone’s inbox rarely moves the needle.

Instead:

• Surface cost diffs in pull requests.

• Show trending usage by resource group.

• Build alerts for anomalies, like sudden spikes in daily cost.

The goal: cost insights that are timely, scoped, and actionable.

4. Embed tools and automation

Use tools that make FinOps part of the developer experience:

• Infra-as-code cost scanners like Infracost

• Tag validation in CI pipelines

• ARM/Bicep/Terraform best practices for cost efficiency

• Budget thresholds in Azure with automated alerts

It’s not about stopping work—it’s about supporting developers with the right signals at the right time.

5. Build a culture

DevFinOps isn’t just a checklist. Like DevOps and SecOps, it needs leadership support and cultural reinforcement.

Celebrate wins like:

• Avoiding an expensive misconfiguration before deployment

• Consolidating environments to reduce waste

• Improving tagging coverage

Encourage teams to share what they’ve learned—what cost them money, and what saved them money.

DevOps, FinOps, and SecOps are not competing ideologies. They are perspectives that, when brought together, enable resilient, scalable, and sustainable cloud-native organizations.

DevFinOps is about putting cost right where it belongs: in the heart of the development process, without slowing teams down.

Want help starting? Ask yourself:

• Where does cost show up in your development lifecycle?

• Who is accountable?

• And what would change if developers had real-time cost visibility?

It’s time to build bridges, not barriers.

Start learning AI in 2025

Keeping up with AI is hard – we get it!

That’s why over 1M professionals read Superhuman AI to stay ahead.

• Get daily AI news, tools, and tutorials

• Learn new AI skills you can use at work in 3 mins a day

• Become 10X more productive

Sign up and start mastering AI

Please help me by visiting my sponsor. If you are interested in sponsoring yourself, then visit the sponsor page.

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!

P.S. I have another newsletter about GitHub, Azure, and .NET news. Subscribe as well to keep informed:

MindByte Weekly Pulse: Quick GitHub, Azure, & .NET Updates

Get to the heart of GitHub, Azure, and .NET with MindByte Weekly Pulse. Every week, find concise, expert-curated insights and trends straight in your inbox. Designed for IT professionals, it's your...

Subscribe

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

In this edition, I’m taking a closer look at FOCUS, the open cost and usage specification that aims to simplify and standardize cloud billing data across vendors. If you’ve ever dealt with inconsistent billing formats, confusing terminology, or multi-cloud reporting challenges—this one’s for you.

I’ll cover what FOCUS is, why it matters, and how Microsoft is embracing the standard by integrating FOCUS support directly into Azure Cost Management. Plus, I’ll walk through how you can start exporting Azure cost data in FOCUS format today.

Let’s explore how standardization is reshaping FinOps—and what that means for your Azure cost strategy.

Cheers, Michiel

Why Billing Data Needs a Common Language

One of the biggest challenges in FinOps isn’t just understanding costs—it’s making sense of the data that describes them. Every cloud provider, SaaS vendor, and platform service delivers billing data in their own format. Different column names, different definitions, and different structures. Even simple concepts like “billed cost” or “resource name” vary wildly between vendors.

That complexity turns cost analysis into a data engineering problem. Teams spend a huge amount of time building and maintaining ETL pipelines to normalize billing files before they can even begin actual analysis. Add a new vendor, and you need to build a whole new schema.

FOCUS (FinOps Open Cost and Usage Specification) aims to fix this.

It’s an open-source, vendor-neutral specification designed to define a common schema for cost and usage data—regardless of where it comes from. With FOCUS, all vendors speak the same billing language. That makes billing data easier to ingest, easier to compare, and far quicker to analyze.

Instead of creating custom logic to interpret each new invoice format, FinOps practitioners can rely on a consistent structure with shared definitions. That means less time wrangling data and more time delivering insights that drive value.

By adopting FOCUS, organizations aren’t just simplifying technical pipelines—they’re enabling cross-cloud financial visibility, better reporting, and faster decision-making.

What Microsoft Brings to FOCUS

While FOCUS is built to benefit every cloud practitioner—regardless of vendor—its impact is highly relevant for anyone working in Azure. Microsoft is not just a supporter of the specification; it’s a founding member of the FOCUS initiative and actively contributes to shaping the future of the format.

That’s no surprise. Azure users know how flexible and broad the platform is—offering everything from IaaS and PaaS to SaaS. But with that flexibility comes complexity. Services are billed in different ways. Terms differ depending on whether you’re in EA or MCA. Even within Microsoft’s own ecosystem, it’s easy to end up stitching together multiple datasets just to understand your monthly spend.

Microsoft sees this and wants to reduce that friction. By adopting FOCUS, Azure aligns its billing exports with a standardized schema, designed from the ground up for FinOps use cases like allocation, cost analysis, budgeting, and forecasting. It’s a step toward clarity over complexity.

With native support for FOCUS now rolling out across Cost Management exports and APIs, this means Azure customers can:

• Work with a billing dataset built for analysis, not just accounting.

• Spend less time transforming data and more time acting on it.

• Use standardized fields like BilledCost, AmortizedCost, ResourceId, ServiceCategory, and ChargeType—consistent across all supported vendors.

• Take advantage of prebuilt Power BI dashboards and tooling within the FinOps Toolkit.

And because Microsoft helps steer the specification, you can expect a deep alignment between FinOps best practices and what Azure exposes in its billing data moving forward.

This isn’t just another export format. It’s a shared language—one that makes billing data more transparent, portable, and usable across organizations and clouds. For Azure users, it’s a major improvement in how cloud costs can be analyzed and communicated.

How to Export Azure Billing Data in FOCUS Format

If you want to start working with your Azure billing data in the FOCUS format, Azure makes this possible through Cost Management Exports. These exports can be configured directly from the Azure Portal and allow you to automate daily or monthly exports of your cost and usage data into a storage account.

To get started:

• Go to Cost Management > Exports in the Azure portal.

• Choose the appropriate scope (subscription, billing profile, resource group, etc.).

• Select + Create, and from the list of export types, choose Cost and usage details (FOCUS).

• Define the export frequency (daily or monthly) and choose your output format (CSV or Parquet).

• Provide a destination storage account and directory.

• Azure will handle partitioning large files automatically and provide a manifest file to help you ingest them reliably.

The FOCUS export combines actual and amortized cost data into a single, clean format—ideal for analysis or integration with FinOps tooling. It supports most account types (EA, MCA, MPA) and provides backward-compatible schema versions so existing pipelines remain functional.

Once configured, your export will run on schedule and generate files that match the FOCUS specification, ready to use for dashboards, Power BI reports, or further processing in tools like Microsoft Fabric or your FinOps platform.

This automation eliminates manual downloads and transforms Azure billing into something predictable, repeatable, and aligned with the broader FinOps ecosystem.

Wrapping Up: Why FOCUS Matters—And Microsoft’s Role

FOCUS is more than just another data format—it’s a major step forward for FinOps maturity. By aligning billing data across vendors, it brings consistency, clarity, and structure to a part of cloud management that has long been messy and fragmented.

Instead of reverse-engineering what “Billed Cost” means across multiple clouds, FinOps practitioners can now speak a common language and use standardized datasets to allocate, analyze, and optimize with confidence.

Microsoft’s early and ongoing involvement in the FOCUS initiative demonstrates a strong commitment to this open approach. Azure Cost Management already supports exporting data in FOCUS format, and that’s just the start. With native integration into tools like Power BI and Microsoft Fabric, Microsoft is helping make cost data easier to work with—at scale and in real time.

For FinOps teams working in or around the Azure ecosystem, adopting FOCUS can cut down on operational overhead, boost reporting accuracy, and simplify onboarding across teams, tools, and vendors.

Standardized cost data means more time delivering value—and less time wrestling with spreadsheets.

Start learning AI in 2025

Keeping up with AI is hard – we get it!

That’s why over 1M professionals read Superhuman AI to stay ahead.

• Get daily AI news, tools, and tutorials

• Learn new AI skills you can use at work in 3 mins a day

• Become 10X more productive

Sign up and start mastering AI

Please help me by visiting my sponsor. If you are interested in sponsoring yourself, then visit the sponsor page.

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!

P.S. I have another newsletter about GitHub, Azure, and .NET news. Subscribe as well to keep informed:

MindByte Weekly Pulse: Quick GitHub, Azure, & .NET Updates

Get to the heart of GitHub, Azure, and .NET with MindByte Weekly Pulse. Every week, find concise, expert-curated insights and trends straight in your inbox. Designed for IT professionals, it's your...

Subscribe

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

This week, I’m at the Microsoft MVP Summit in Redmond, so instead of a deep dive into a specific topic, I’m sharing a collection of useful Azure cost-related articles. These cover billing structures, cost management updates, FinOps tooling, and monitoring strategies—all aimed at helping you keep cloud spending under control.

I’ll be back with a regular deep dive in the next edition. Until then, enjoy the reading!

Cheers, Michiel

What’s new in FinOps toolkit 0.8 – February 2025

Whether you consider yourself a FinOps practitioner, someone who's enthusiastic about driving cloud efficiency and maximizing the value you get from the cloud or were just asked to look at ways to reduce cost, the FinOps toolkit has something for you. This month, you'll find a complete refresh of Power BI with a new design, greatly improved performance, and the ability to calculate reservation savings for both EA and MCA; FinOps hubs have a new Data Explorer dashboard and simpler public networking architecture; and many more small updates and improvements across the board. Read on for details!

techcommunity.microsoft.com/blog/finopsblog/what’s-new-in-finops-toolkit-0-8-–-february-2025/4391573

Monitoring canceled Azure Subscriptions

The text explains the process of managing Azure subscriptions, particularly how to cancel a subscription and track its status using Azure Monitor and Log Analytics. It includes steps to configure a…

cloudadministrator.net/2025/03/12/monitoring-canceled-azure-subscriptions

Microsoft BYOL Options and Cost Savings

Microsoft Bring-Your-Own-License options and programs. Azure Hybrid Benefit. License Mobility. Flexible Virtualisation. How to use. Rules and requirements.

samexpert.com/microsoft-byol-explained

Learn how to make AI work for you

AI won’t take your job, but a person using AI might. That’s why 1,000,000+ professionals read The Rundown AI – the free newsletter that keeps you updated on the latest AI news and teaches you how to use it in just 5 minutes a day.

Sign up to start learning.

Please help me by visiting my sponsor. If you are interested in sponsoring yourself, then visit the sponsor page.

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!

P.S. I have another newsletter about GitHub, Azure, and .NET news. Subscribe as well to keep informed:

MindByte Weekly Pulse: Quick GitHub, Azure, & .NET Updates

Get to the heart of GitHub, Azure, and .NET with MindByte Weekly Pulse. Every week, find concise, expert-curated insights and trends straight in your inbox. Designed for IT professionals, it's your...

Subscribe