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
Roughly EUR 180,000 a year. That was the waste one structured cost optimization review surfaced in a single mid-market Azure environment: orphaned resources, over-provisioned SKUs, misconfigured retention. The team running the environment couldn’t see any of it. They were running it, not auditing it.
The number isn’t unusual. It’s what accrues when an Azure estate grows under delivery pressure for two or three years and nobody holds a budget against the architecture. Nothing dramatic happens. A hundred small defaults, each reasonable in isolation, 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 the design principles actually ask for
Every euro of spend should map to a workload requirement, and the mapping should be reviewed rather than assumed. The Microsoft Azure Well-Architected Framework frames this as a continuous discipline, not a one-time cleanup. In practice the first review is where the large numbers surface, because nobody has done the cleanup yet.
The principles are not complicated. Create a cost model so you know what each workload should cost. Implement governance so spend can’t grow unobserved, mostly through tagging and budgets. Monitor continuously. Right-size to actual demand. Every finding comes from the gap between those principles and an estate that grew without one of them enforced.
Governance is the root cause of most of the rest. Create resources without mandatory tags (cost centre, owner, environment, workload) and 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.
Resources that outlive the thing they belonged to
You delete what you meant to delete, and Azure leaves everything that was attached to it behind. There’s no cascade. The pattern repeats across resource types, and every one of them keeps billing for nothing.
Managed disks are the classic case. Delete a virtual machine through the portal and, depending on how it was created, the OS and data disks often stay. A Premium SSD you’re no longer using bills at its full provisioned rate anyway. An assessment enumerates every managed disk where diskState is Unattached and sums the monthly cost. In a three-year-old estate that’s routinely dozens of disks.
Public IPs do the same thing. A static public IP not associated with any network interface, load balancer, or gateway still incurs an hourly charge. They pile up as load balancers and VMs get decommissioned and the IP reservation outlives them. The finding lists every public IP with no associated resource.
Then there are App Service plans. The 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 zero apps is pure waste, and the assessment finds every plan with no associated sites.
It doesn’t stop there. Orphaned NAT gateways. Unused Application Gateways. Disk snapshots taken for a migration two years ago and never deleted. A Bastion host left running in a subscription nobody touches anymore. Each one is small. Together they’re a line item.
The largest line in most bills is oversizing
At provisioning time the safe choice is to size up. Nobody ever sizes back down once the real load is known. That’s the whole mechanism, and it produces the single largest category of waste in most assessments. It’s the inverse of the performance efficiency pillar, where the finding is under-provisioning and no autoscale.
The cause is human, not technical. A workload gets deployed on a Standard_D8s_v5 (eight vCPUs) because the team didn’t yet know the load and over-sizing felt prudent. The load turned out modest. Eighteen months later the VM is still running at 8% average CPU utilisation. 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 gets rewarded for taking it.
Databases tell the same story. 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 |
Retention is a per-gigabyte rate times a number nobody chose
Multiply a per-gigabyte rate by a duration nobody set 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’re 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. And to be clear, this is not the “retention is too short” finding — that one is a security finding from the WAF security pillar. Here it’s 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 well past the actual recovery requirement. Each retained recovery point is storage you pay for. Set the retention to a default, never align it to a documented RPO, and the cost compounds against data nobody would ever restore.
Where Azure Advisor stops
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. It’s a genuinely useful starting point, and any cost review should read it. But there are three things it can’t see that a structured assessment can.
Architectural waste is the first. Advisor will tell you a VM is under-utilised. It won’t tell you the workload belongs on a different service entirely — that a set of always-on VMs should be a serverless or containerised design costing a fraction at this load. That’s an architecture judgment, not a resource recommendation.
Your policy is the second. Advisor doesn’t know your retention requirement or your reservation strategy. It surfaces a generic recommendation. It can’t tell you this specific workspace violates your 180-day retention standard.
And it can’t connect cost to compliance. The same misconfigured retention that wastes money may also breach an evidence requirement. Advisor sees the cost. It doesn’t see the governance posture the cost sits inside.
What the fixed state looks like as evidence
The evidence isn’t a spreadsheet of savings. It’s 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. Tagging-complete, reservation-applied, right-sized. Every resource maps to an owner and a workload.
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. 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’s 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’s job is to make the waste visible so those decisions run against numbers instead of 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.
