Your AI Experiments on Azure Are Burning Money — Here's How to Fix That

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

If you’re building AI-powered apps on Azure right now, you’ve probably noticed something: your cloud bill looks different than it used to. Not just higher — weirder. Spiky. Hard to predict.

Microsoft just published a great piece on cloud cost optimization principles that still matter, and honestly, the timing couldn’t be better. Because AI workloads have changed the game when it comes to costs.

Why AI workloads hit different

Here’s the thing. Traditional .NET workloads are relatively predictable. You know your App Service tier, you know your SQL DTUs, you can estimate monthly spend pretty accurately. AI workloads? Not so much.

You’re testing multiple models to see which one fits. You’re spinning up GPU-backed infrastructure for fine-tuning. You’re making API calls to Azure OpenAI where token consumption varies wildly depending on prompt length and user behavior. Every experiment costs real money, and you might run dozens before you land on the right approach.

That unpredictability is what makes cost optimization critical — not as an afterthought, but from day one.

Management vs. optimization — know the difference

One distinction from the article that I think developers overlook: there’s a difference between cost management and cost optimization.

Management is tracking and reporting. You set up budgets in Azure Cost Management, you get alerts, you see dashboards. That’s table stakes.

Optimization is where you actually make decisions. Do you really need that S3 tier, or would S1 handle your load? Is that always-on compute instance sitting idle on weekends? Could you use spot instances for your training jobs?

As .NET developers, we tend to focus on the code and leave the infrastructure decisions to “the ops team.” But if you’re deploying to Azure, those decisions are your decisions too.

What actually works

Based on the article and my own experience, here’s what moves the needle:

Know what you’re spending and where. Tag your resources. Seriously. If you can’t tell which project or experiment is eating your budget, you can’t optimize anything. Azure Cost Management with proper tagging is your best friend.

Set guardrails before you experiment. Use Azure Policy to restrict expensive SKUs in dev/test environments. Set spending limits on your Azure OpenAI deployments. Don’t wait until the bill arrives to realize someone left a GPU cluster running over the weekend.

Rightsize continuously. That VM you picked during prototyping? It’s probably wrong for production. Azure Advisor gives you recommendations — actually look at them. Review monthly, not yearly.

Think about lifecycle. Dev resources should spin down. Test environments don’t need to run 24/7. Use auto-shutdown policies. For AI workloads specifically, consider serverless options where you pay per execution instead of keeping compute warm.

Measure value, not just cost. This one’s easy to forget. A model that costs more but delivers significantly better results might be the right call. The goal isn’t to spend the least — it’s to spend smart.

The takeaway

Cloud cost optimization isn’t a one-time cleanup. It’s a habit. And with AI workloads making spend less predictable than ever, building that habit early saves you from painful surprises later.

If you’re a .NET developer building on Azure, start treating your cloud bill like you treat your code — review it regularly, refactor when it gets messy, and never deploy without understanding what it’s going to cost you.

Azure Smart Tier Is GA — Automatic Blob Storage Cost Optimization Without Lifecycle Rules

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

If you’ve ever spent time tuning Azure Blob Storage lifecycle policies and then watched them fall apart when access patterns shifted, this one’s for you. Microsoft just announced the general availability of smart tier for Azure Blob and Data Lake Storage — a fully managed tiering capability that automatically moves objects between hot, cool, and cold tiers based on real usage.

What smart tier actually does

The concept is straightforward: smart tier continuously evaluates the last access time of each object in your storage account. Frequently accessed data stays in hot, inactive data moves to cool after 30 days, and then to cold after another 60 days. When data is accessed again, it’s promoted back to hot immediately. The cycle restarts.

No lifecycle rules to configure. No access pattern predictions. No manual tuning.

During the preview, Microsoft reported that over 50% of smart-tier-managed capacity automatically shifted to cooler tiers based on actual access patterns. That’s a meaningful cost reduction for large storage accounts.

Why this matters for .NET developers

If you’re building applications that generate logs, telemetry, analytics data, or any kind of growing data estate — and honestly, who isn’t — storage costs add up fast. The traditional approach was writing lifecycle management policies, testing them, and then re-tuning when your app’s access patterns changed. Smart tier removes that entire workflow.

Some practical scenarios where this helps:

Application telemetry and logs — hot when debugging, rarely accessed after a few weeks
Data pipelines and ETL outputs — accessed heavily during processing, then mostly cold
User-generated content — recent uploads are hot, older content gradually cools
Backup and archival data — accessed occasionally for compliance, mostly idle

Setting it up

Enabling smart tier is a one-time configuration:

New accounts: Select smart tier as the default access tier during storage account creation (zonal redundancy required)
Existing accounts: Switch the blob access tier from your current default to smart tier

Objects smaller than 128 KiB stay in hot and don’t incur the monitoring fee. For everything else, you pay standard hot/cool/cold capacity rates with no tier transition charges, no early deletion fees, and no data retrieval costs. A monthly monitoring fee per object covers the orchestration.

The tradeoff to know about

Smart tier’s tiering rules are static (30 days → cool, 90 days → cold). If you need custom thresholds — say, moving to cool after 7 days for a specific workload — lifecycle rules are still the way to go. And don’t mix both: avoid using lifecycle rules on smart-tier-managed objects, as they can conflict.

Wrapping up

This isn’t revolutionary, but it solves a real operational headache. If you manage growing blob storage accounts and you’re tired of maintaining lifecycle policies, enable smart tier and let Azure handle it. It’s available today in nearly all zonal public cloud regions.

Cost-Optimization | The .NET Blog