There is a moment that almost every team running in the cloud goes through: this month's bill is 30% higher than last month's, the traffic is identical, no one deployed anything major. And no one knows exactly why.
It's not a bug. It's the natural consequence of a billing model where resources are created in three seconds and forgotten forever — and the financial feedback comes with a 30-day delay, on a screen the developer never opens.
This is the first article in a series of five about cost optimization in Azure. Before we talk about Functions plans, auto-scaling rules, or three-year reservations, we need the right mental model. Otherwise, we optimize noise.
The three types of cost in a cloud architecture
Every line on your bill falls into one of three categories. The difference between them is not accounting — it's architectural, because each is fixed differently.
1. Fixed cost (reserved capacity)
You pay for allocated capacity, whether you use it or not. An App Service Plan in the P1v3 tier, a Dedicated workload profile in Container Apps, a virtual machine, a Premium Functions plan. The clock runs even at 3 AM, when no one visits you.
Fixed cost is not bad in itself — it's predictable, eliminates cold starts, and gives you control. It becomes problematic only when the reserved capacity does not match actual usage.
2. Variable cost (actual consumption)
You pay per execution, per GB-second, per Request Unit, per gigabyte transferred. Azure Functions on Consumption, Cosmos DB serverless, Container Apps on Consumption profile. At zero traffic, you pay almost zero.
The trap here is the opposite: the cost is invisible until it becomes large. A function running 200 times per minute instead of 2 does not trigger any alert — it only appears on the bill.
3. Idle cost (the most expensive zero in the world)
This is the category everyone misses. Idle cost is what you pay for resources that are running but not doing anything useful.
The canonical example is in Azure Container Apps. The service can scale to zero replicas, in which case you don't pay for compute. But the moment you set minReplicas: 1 — usually to avoid cold start — each replica runs 24/7 and is billed at an idle rate, separate from the active rate applied while actually processing a request.
The difference between the two rates is about a factor of eight. Sounds small. Multiplied by 730 hours per month, for three microservices, in three environments (dev, staging, prod), it's no longer small.
Most surprise bills in Azure do not come from traffic. They come from idle time on resources that someone decided, six months ago, is safer not to scale to zero.
Why the developer doesn't see the cost
In a classic on-premise application, the resource is physical and finite. If the server runs out of RAM, you find out immediately — the application crashes. The feedback is brutal but instantaneous.
In the cloud, the resource is elastic. If you need more RAM, the platform gives it to you. The application doesn't crash. Nothing breaks. The additional cost appears three weeks later, in a report read by someone else, aggregated with 400 other lines.
The feedback loop is broken in three places:
- Temporal — the effect of the decision appears 30 days after the decision.
- Organizational — the person making the technical decision is not the one who sees the bill.
- Granular — the bill is per subscription, the decision is per resource.
Everything that follows in this series is essentially about fixing these three breaks. Tagging solves granularity. Budgets and anomaly alerts solve temporality. The rest is architecture.
The five sources of waste you will almost certainly find
If you open Cost Analysis now on a subscription running for over a year, the probability of finding at least three of these is very high.
1. Orphaned resources
Unattached disks left after deleting a VM. Reserved and unused public IP addresses. Snapshots from 2023. NAT Gateways for an empty VNet. Load balancers without backends. None of these do anything, all are billed.
2. Non-production environments running 24/7
Dev and staging are realistically used 40 hours per week. They are billed for 168. This means that 76% of the cost of non-prod environments is spent while no one is looking at them. A simple start/stop schedule is, percentage-wise, the most profitable hour of work you can invest in infrastructure.
3. Over-provisioning "for safety"
Someone chose P2v3 instead of P1v3 at launch, to be safe. They never measured. The application has been running at 12% CPU for two years. Azure Advisor signals this, but no one reads it.
4. Uncalibrated observability
Application Insights and Log Analytics are billed per gigabyte ingested. A LogLevel.Information left in production on a high-traffic endpoint can reach, in bill lines, comparable cost to the compute of the application generating the logs. It's a particularly ironic way to spend money.
5. Egress and chattiness between regions
Data transfer into Azure is free. Out of Azure, it is not. And cross-region traffic is billed the same. An architecture where the API is in West Europe and the database in North Europe "for redundancy" pays for every query, infinitely.
The mental model that changes the discussion
The most useful thing I have adopted is to stop measuring cost in dollars per month, and instead in cost per business unit.
"Infrastructure costs us 800 dollars per month" is a statement that cannot be acted upon. You don't know if it's a lot or a little. You don't know if it's healthy growth or drifting.
"It costs us 1.40 dollars per active tenant per month" is something else entirely. It's a metric you can track over time, compare with the subscription price, and based on which you can answer the question that really matters: is the margin improving or eroding as we grow?
For a SaaS, the unit is the tenant. For a public API, it's a thousand requests. For a processing pipeline, it's the processed document. Once you have the denominator, optimization stops being a chore and becomes a product metric.
What follows in the series
With this model in mind, the next four articles become concrete decisions, not price tables:
- Azure Functions: Consumption, Flex, or Premium — where is the real threshold at which pay-per-execution becomes more expensive than reserved capacity and how much it costs, in money, to eliminate cold start.
- Auto-scaling that doesn't cost you — KEDA and scale-to-zero in Container Apps, autoscale rules in App Service, and why
minReplicasis the most expensive default-valued parameter in Azure. - Azure Cost Management — tagging, Cost Analysis, budgets, anomaly detection, and how to build a monthly audit process that takes 20 minutes.
- Reserved Instances vs. Savings Plans vs. pay-as-you-go — what you commit to, for how long, and why you almost never choose a single instrument.
Conclusion
Cost optimization in the cloud is not an emergency operation done when the bill is high. It is a property of architecture, like security or observability — and, like them, it is much cheaper to build it from the start than to add it later.
Until the next article, a ten-minute exercise that almost always pays off: open Cost Analysis, group by Resource, sort descending, and look at the top five lines. Then ask yourself, for each, if you know why it is there. If you don’t have an answer for at least one, you have already found your first target.
