The Azure Well-Architected Cost Optimization Pillar: Finding the Waste in Your Azure Bill
A single Azure Well-Architected cost optimization assessment surfaced ~EUR 180,000 in annual waste — orphaned resources, over-provisioned SKUs, misconfigured retention. For CTOs and FinOps leads.
Marc Dekeyser |
The Azure Well-Architected Cost Optimization Pillar: Finding the Waste in Your Azure Bill
The Azure Well-Architected cost optimization pillar is the only assessment that pays for itself before you have remediated anything. In one mid-market environment, a single structured cost optimization review surfaced roughly EUR 180,000 in annual Azure waste — orphaned resources, over-provisioned SKUs, and misconfigured retention — none of which the team running the environment could see, because they were running it, not auditing it.
That number is not unusual. It is what accrues when an Azure estate grows under delivery pressure for two or three years without anyone holding a budget against the architecture. The waste is not dramatic. It is a hundred small defaults that each looked reasonable in isolation and compound into a bill nobody can fully explain. The cost optimization pillar is the discipline of explaining it.
Key takeaways
- Orphaned resources — unattached managed disks, idle public IP addresses, empty App Service plans — accrue silently because deleting the parent resource does not delete them.
- Over-provisioned SKUs are the largest single category of waste: virtual machines and databases sized for a peak that never arrived, running 24/7 at the wrong tier.
- Misconfigured log and backup retention quietly multiplies storage cost — a Log Analytics workspace retaining data for years, or backup retention set far beyond any recovery requirement.
- Missing reserved instances and savings plans leave 30-60% on the table for steady-state workloads that will run regardless.
- Azure Advisor surfaces some of this, but it stops at the resource level and cannot see architectural waste or apply your retention policy.
What do the cost optimization design principles require?
The Azure Well-Architected cost optimization pillar requires that every euro of spend maps to a workload requirement, and that the mapping is reviewed rather than assumed. The Microsoft Azure Well-Architected Framework frames this as a continuous discipline, not a one-time cleanup, but in practice the first review is where the large numbers surface because nobody has done the cleanup yet.
The principles are straightforward. Create a cost model so you know what each workload should cost. Implement governance so spend cannot grow unobserved — primarily through tagging and budgets. Monitor and optimise continuously. Right-size to actual demand. The findings come from the gap between these principles and an estate that grew without any of them enforced.
The governance principle is the root cause of most of the rest. When resources are created without mandatory tags — cost centre, owner, environment, workload — you lose the ability to attribute spend. Untagged spend is unaccountable spend. And unaccountable spend is where waste hides, because no one owns it enough to question it.
Where do orphaned resources come from?
Orphaned resources come from deleting the thing you wanted to delete while leaving behind the resources that were attached to it, because Azure does not cascade those deletions. The pattern repeats across resource types, and each type bills you for nothing.
Unattached managed disks. Delete a virtual machine through the portal and, depending on how it was created, the OS and data disks frequently remain. A Premium SSD disk you are no longer using still bills at its full provisioned rate. An assessment enumerates every managed disk where the diskState is Unattached and sums the monthly cost. In a three-year-old estate, this is routinely dozens of disks.
Idle public IP addresses. A static public IP address that is not associated with any network interface, load balancer, or gateway still incurs an hourly charge. They accumulate as load balancers and VMs are decommissioned and the IP reservation outlives them. The finding lists every public IP with no associated resource.
Empty App Service plans. An App Service plan is the compute you pay for; the apps run on it. Delete the last app and the plan keeps billing at its tier — a Standard or Premium plan running with zero apps is pure waste. The assessment finds plans with no associated sites.
Orphaned NAT gateways, unused Application Gateways, stale snapshots. The same logic extends across the estate. Disk snapshots taken for a migration two years ago and never deleted. A Bastion host left running in a subscription nobody uses anymore. Each is small. Together they are a line item.
How do over-provisioned SKUs accumulate?
Over-provisioned SKUs accumulate because the safe choice at provisioning time is to size up, and nobody ever sizes back down once the real load is known. This is the single largest category of waste in most assessments, and it is the inverse of the performance efficiency pillar — where the finding is under-provisioning and no autoscale.
The mechanism is human, not technical. A workload is deployed on a Standard_D8s_v5 — eight vCPUs — because the team did not yet know the load and over-sizing felt prudent. The load turned out modest. The VM has run at 8% average CPU utilisation for eighteen months. The right size was a Standard_D2s_v5, at a quarter of the cost. Nobody downsized it because downsizing carries a small risk and no one was rewarded for taking it.
Databases show the same pattern: an Azure SQL Database at a vCore count chosen for a launch-day peak that never materialised, an Azure Cache for Redis on Premium where Standard would serve the throughput. The assessment correlates the provisioned SKU against actual utilisation metrics from Azure Monitor and produces a right-sizing list with the euro delta per resource.
| Waste category | How it accrues | Where the assessment finds it |
|---|---|---|
| Orphaned disks | VM deleted, disk left behind | Managed disks with diskState: Unattached |
| Idle public IPs | Parent resource decommissioned | Public IPs with no associated resource |
| Empty App Service plans | Last app deleted, plan remains | Plans with zero associated sites |
| Over-provisioned VMs | Sized for a peak that never came | Sustained CPU well below SKU capacity |
| Misconfigured retention | Default or excessive retention set once | Log Analytics / backup retention vs requirement |
| Missing reservations | Steady-state workloads billed at pay-as-you-go | Consistent usage with no reservation applied |
Why does retention configuration cost so much?
Retention configuration costs so much because it multiplies a per-gigabyte rate by a duration nobody chose deliberately, and the bill grows every day the data sits there. Two settings drive it: Log Analytics workspace retention and backup retention.
A Log Analytics workspace ingesting diagnostic and platform logs has a retention period. Set it to two years across a high-volume workspace and you are paying to store telemetry long past any operational or compliance need. The compliance baseline for DORA and NIS2 is far shorter than the multi-year retention some workspaces drift into. The finding is not “retention is too short” — that is a security finding from the WAF security pillar. Here it is the opposite: retention far exceeding any requirement, billed monthly.
Backup retention has the same shape. Azure Backup policies with daily, weekly, monthly, and yearly recovery points retained for durations that exceed the actual recovery requirement. Each retained recovery point is storage you pay for. When the retention was set to a default and never aligned to a documented RPO, the cost compounds against data nobody would ever restore.
Where does Azure Advisor stop?
Azure Advisor surfaces individual resource-level cost recommendations — idle resources, right-sizing candidates, reservation opportunities — and then it stops at the boundary of a single resource. Advisor is a genuinely useful starting point, and any cost review should read it. But it cannot see three things that a structured assessment can.
It cannot see architectural waste. Advisor will tell you a VM is under-utilised. It will not tell you that the workload should be on a different service entirely — that a set of always-on VMs should be a serverless or containerised design that costs a fraction at this load. That is an architecture judgment, not a resource recommendation.
It cannot apply your policy. Advisor does not know your retention requirement or your reservation strategy. It surfaces a generic recommendation; it cannot tell you that this specific workspace violates your 180-day retention standard.
And it cannot connect cost to compliance. The same misconfigured retention that wastes money may also breach an evidence requirement. Advisor sees the cost. It does not see the governance posture the cost sits inside.
What does a cost-optimised configuration look like in evidence?
A cost-optimised configuration produces evidence as a tagging-complete, reservation-applied, right-sized estate where every resource maps to an owner and a workload. The evidence is not a spreadsheet of savings. It is an Azure Resource Graph query that returns zero orphaned disks, zero idle public IPs, mandatory tags present on every resource, and reservation coverage on steady-state workloads.
That state is also a governance artifact. An estate where spend is fully attributed is one where Azure Policy enforces tagging at creation, budgets alert at thresholds, and reservations reflect a deliberate commitment strategy. The EUR 180,000 finding was not a one-time recovery. It was the symptom of governance that had never been enforced — and the durable fix is the enforcement, not the cleanup.
Platform Architecture Authority reads the estate through Azure Resource Graph and Azure Monitor utilisation, surfaces each waste category with the euro figure attached, and generates the remediation — the tagging policy, the right-sizing changes, the resources safe to delete — as infrastructure-as-code you review before applying. It is read-only; it proposes, you dispose. A FinOps lead still decides which reservations to commit to and which workloads genuinely need their headroom; the platform makes the waste visible so those decisions are made against numbers rather than assumptions.
FAQ
How does a single assessment find EUR 180,000 in annual waste? It accrues across categories: over-provisioned VMs and databases running 24/7 at the wrong tier, orphaned disks and IPs billing for nothing, retention set far beyond requirement, and steady-state workloads with no reserved instances. No single item is dramatic. The total is what three years of unaudited defaults produce in a mid-market estate.
Will deleting orphaned resources break anything? Genuinely orphaned resources — an unattached disk, a public IP with no associated resource, an App Service plan with no apps — have no dependents by definition, so deleting them is low risk. The discipline is confirming the orphaned state in Azure Resource Graph before deletion and snapshotting anything where data recovery is conceivable.
Does cost optimization conflict with reliability? It can. Geo-redundant storage and zone redundancy cost more, and aggressive cost cutting can strip necessary resilience. The resolution is the documented RTO and RPO from the reliability pillar: redundancy is justified where the recovery objective requires it and is waste where it does not.
The Azure bill is not a fixed cost of doing business. It is an accumulation of decisions, most of which were never decisions at all — and a structured cost optimization review is how you turn the defaults back into choices.
