One default setting — left untouched by the team that provisioned your Azure environment — is quietly costing you between €15,000 and €60,000 per month right now. I've seen this exact pattern at more than a dozen scaleups across insurance, energy, and SaaS. The engineering team is competent. The architecture is sound. The billing is quietly catastrophic.
The setting is no resource-level budgets with enforced tagging and automated rightsizing. Put more plainly: Azure's defaults encourage you to provision without constraint and pay without visibility. Most teams discover the damage when the CFO sees the invoice.
Why Azure's Defaults Set You Up to Overspend
Azure is an excellent cloud platform. But its sales motion is to get workloads running quickly, not to optimise your cost posture. The defaults reflect that:
- No budget alerts configured by default. You can spend €500,000 before a single automated warning fires — unless you configured one manually.
- No tagging policy enforced at subscription level. Resources accumulate without owner, environment, or cost-centre attribution. Within six months, 40–60% of spend in a typical environment is unattributable.
- VM SKUs are selected for peak load, not average load. Engineers provision for worst-case. The Standard_D16s_v3 that was justified for a load test sits at 12% CPU utilisation six days a week.
- Dev and staging environments are indistinguishable from production in billing. Without lifecycle policies, a developer's test environment from Q3 runs untouched into Q1 of the following year.
- Reserved Instances are purchased late or not at all. Azure's pay-as-you-go pricing carries a 40–60% premium over 1-year Reserved Instances for the same SKU. Almost every scaleup I audit is running 80–95% of their workload on pay-as-you-go.
None of this is Azure's fault. It's the consequence of provisioning under delivery pressure without a FinOps discipline to counterbalance it.
The Anatomy of a €40k/Month Problem
When I walk into an environment where this has been running unchecked for 12–18 months, the waste typically breaks down like this:
| Category | Typical share of overspend | Root cause |
|---|---|---|
| Oversized compute (VMs, AKS node pools) | 35–45% | Provisioned for peak, never reviewed |
| Orphaned resources (disks, NICs, public IPs) | 15–20% | Deleted VMs, leftover storage |
| Dev/test environments running 24/7 | 15–25% | No shutdown schedule, no lifecycle policy |
| Pay-as-you-go vs Reserved Instance delta | 20–30% | No commitment strategy in place |
| Redundant data transfer and egress | 5–10% | Cross-region data movement not accounted for |
The numbers compound. A team running 40 VMs at pay-as-you-go rates, with no Reserved Instances, 24/7 dev environments, and no rightsizing has a cost structure 2–3x what it needs to be.
The Default Settings That Do the Most Damage
No Enforced Tagging at Subscription Level
Azure Policy can enforce tagging at the resource group or subscription level — blocking deployment if required tags are absent. Most environments I see have no such policy. The result: six months in, you have resources scattered across subscriptions with no owner attribution. When the CFO asks which team is driving the spike in the Azure bill, the answer is "we don't know."
The minimum viable tag schema I apply on day one is environment, owner, project, and cost-centre. Enforced via Azure Policy with a deny effect, not audit. The difference matters — audit logs violations; deny stops them.
VM Sizes Chosen for Comfort, Not Evidence
The conversation I have most often: "We sized those VMs during the performance testing phase last year." When did you last look at CPU and memory utilisation? "We haven't really."
Azure Advisor surfaces rightsizing recommendations automatically, but most teams treat these as suggestions. They aren't — they're money on the table. A Standard_D8s_v4 running at 15% average CPU should be a Standard_D4s_v4. At pay-as-you-go rates in West Europe, that's a saving of roughly €180/month per VM. Multiply across a fleet of 40 VMs and you're looking at €7,200/month from one category alone.
The performance testing trap
VM sizes selected during initial load testing are almost always oversized for steady-state production load. Load tests simulate peak concurrency that occurs a fraction of the time. Unless you run continuous rightsizing reviews, you're paying for capacity that sits idle the other 90% of the time.
Reserved Instances Purchased Too Late — or Never
This is the single largest recoverable cost item in most Azure environments. The logic is straightforward:
- Pay-as-you-go, Standard_D8s_v4, West Europe: approximately €420/month
- 1-year Reserved Instance, same SKU: approximately €255/month — a 39% saving
- 3-year Reserved Instance, same SKU: approximately €175/month — a 58% saving
For a scaleup running 50 production VMs and 15 database instances that have been stable for more than six months, committing to 1-year Reserved Instances is not a risk decision — it's an accounting decision. The workload is not going away. The only question is whether you're paying 39% more than you need to.
Most teams delay this because Reserved Instance commitments feel like a risk. They're not, for established workloads. The risk is continuing to pay pay-as-you-go rates on infrastructure you know will run for the next 12 months.
Dev and Test Environments Without Shutdown Schedules
In every environment I audit, I find at least 10–20 non-production VMs running 24 hours a day, 7 days a week — including weekends when no one touches them. A developer's test environment costs the same whether it's being used or not.
Azure Automation runbooks and Azure DevTest Labs both provide automated shutdown scheduling. A simple policy — dev and test VMs shut down at 20:00 and restart at 07:30 Monday–Friday — reduces non-production compute costs by 60–65% overnight. If your engineers need their environment outside those hours, they opt in explicitly.
The FinOps Governance Model That Prevents This
Once you've recovered the immediate waste, you need a structure that prevents drift. The model I implement has three components:
Deploy Azure Policy assignments at the subscription level with deny effect for missing required tags. Configure budget alerts at 80% and 100% of monthly budget per resource group, with automated email to the engineering team and finance. No resource reaches production without a cost-centre and owner tag. No team discovers their Azure bill at month-end invoice — they get a notification before they breach.
Pull Azure Advisor recommendations on the first Monday of each month. Any VM or database running below 20% average CPU for 14 consecutive days is flagged for rightsizing. The engineering team reviews with a 5-business-day turnaround — not a backlog ticket that lives for a quarter. Rightsizing recommendations older than 30 days without action require sign-off from the engineering lead.
Every quarter, review which workloads have been stable for 6 or more months. Convert those to 1-year Reserved Instances. Do this with Azure's hybrid benefit if you hold Windows Server or SQL Server licences — it stacks on top of Reserved Instance savings for an additional 20–40% reduction. Treat the quarterly RI review as a finance-engineering meeting, not an engineering backlog item.
Deploy shutdown schedules for all non-production VMs. Implement a 90-day resource expiry tag on all dev and test resource groups — after 90 days, the resource group owner receives a deletion warning and must explicitly extend. Orphaned resources (unattached managed disks, unassociated public IPs, unused load balancer rules) are flagged in a weekly automated report and deleted within 7 days unless claimed.
The four steps form a continuous governance cycle rather than a one-time project:
What "Fixed" Actually Looks Like
When I run a focused FinOps sprint against an environment that has been running without governance for 12–18 months, the results across the first six weeks are consistent:
| Action | Typical saving (monthly) |
|---|---|
| Rightsize oversized VMs (20 VMs downsized) | €3,500–€6,000 |
| Reserved Instance conversion (50 VMs, 1-year) | €7,000–€12,000 |
| Dev/test shutdown schedules (15 environments) | €2,000–€4,500 |
| Delete orphaned resources (disks, NICs, IPs) | €800–€2,000 |
| Egress and data transfer optimisation | €1,000–€3,000 |
| Total monthly recovery | €14,000–€27,500 |
The range is wide because it depends on your environment's history and size. The median scaleup I work with recovers between €18,000 and €22,000 per month — without removing any running workload, reducing capacity during peak hours, or making changes that affect reliability.
FinOps is an engineering discipline, not a finance function
The teams that recover the most cost are those that treat FinOps as an engineering practice — owned by engineering leads, reviewed in engineering meetings, tracked with engineering metrics. When cost optimisation is delegated entirely to finance, engineers don't feel the feedback loop, and the same waste patterns regenerate within two quarters.
The Deeper Problem: FinOps Requires a Culture, Not a Tool
Azure Cost Management, Cloudability, and Apptio can surface waste. None of them fix it. Fixing it requires accountability structures: team-level cost visibility, budget ownership, and a review cadence with teeth.
The scaleups that eliminate the problem permanently are those where engineering leads see their team's Azure bill in the same weekly review where they look at reliability and velocity metrics. When cloud cost is invisible to the people making provisioning decisions, it will drift. Every time.
If your Azure bill has been growing faster than your business and you're not sure why — or you suspect there's significant recoverable waste but haven't had the bandwidth to find it — let's talk. I run a focused FinOps audit in the first two weeks and have a prioritised savings roadmap in your hands before the end of the month. Book a 30-minute discovery call.