Azure Cost Optimisation: Where Organisations Consistently Overspend (And How to Fix It)

The average mid-market organisation on Azure wastes between £80,000 and £400,000 per year on cloud spend that delivers zero business value. This is not speculation — it is the consistent finding from Techseria's Azure cost review engagements across UK, UAE, and European organisations over the past four years.

The waste is not dramatic. There is no single decision that created it. It accumulated through a hundred small provisioning choices — a VM spec set at peak capacity and never reduced, a database tier bumped up to handle a load spike and never downscaled, a storage account that outlived the project it served. Each decision was reasonable in isolation. Together, they compound into a structurally expensive cloud environment.

This article identifies the 8 most consistent overspend patterns, with actual cost figures, the specific Azure tooling to find them, and the steps to fix them. At the end: a 60-day timeline to execute a full optimisation cycle.

Why Azure Bills Drift Upward

Before the patterns: the root cause.

Azure billing is opt-out by default on cost. You provision resources; they run indefinitely until you act. There is no automatic rightsizing, no idle detection that terminates resources, no workflow that forces you to justify continued spend. Azure Advisor and Cost Management provide recommendations — but acting on those recommendations requires someone to have the responsibility, the access, and the time to do so.

In most organisations, no single person owns cloud cost optimisation. Engineering owns infrastructure performance. Finance owns the budget. The gap between them is where waste accumulates.

Pattern 1: Idle and Underutilised Virtual Machines

Average waste: 23% of compute spend

The most consistent overspend pattern across every Azure environment Techseria has reviewed: virtual machines running at 5–15% average CPU utilisation, provisioned at a size designed to handle peak load that may occur a few times per month.

Azure Advisor's right-sizing recommendations use 14-day CPU utilisation history. In our experience, this is too short a window. Peak loads in many organisations are monthly (month-end processing, payroll, reporting runs). A 14-day window may capture a peak period and recommend no action on a VM that is genuinely idle 80% of the time.

Finding idle VMs:

In Azure Cost Management + Billing:

1. Navigate to Cost Management → Insights → Idle and underutilised resources
2. Filter to Virtual Machines
3. Set the look-back period to 30 days (not the default 7)
4. Export the list to CSV — you want more than the portal's 25-row display

Cross-reference with Azure Monitor metrics:

// Azure Monitor Logs query for low-CPU VMs Perf | where ObjectName == "Processor" and CounterName == "% Processor Time"

The fix:

• VMs with under 10% average CPU over 30 days: downsize by 2 SKU tiers or convert to burstable (B-series)
• VMs with under 5% average CPU: evaluate whether the workload can be containerised (AKS) or serverless (Azure Functions/Container Apps)
• Development VMs: schedule auto-shutdown for evenings and weekends. A D4s_v3 running 24/7 costs ~£220/month. Running 8 hours/day on weekdays only costs ~£73/month. Saving: £147/month per VM.
• VMs confirmed as idle (no connections, no CPU activity): stop immediately. Note that stopped (deallocated) VMs incur no compute charges; stopped (not deallocated) VMs do.

Typical impact: On an Azure environment with £200k annual compute spend, addressing idle and oversized VMs typically yields £30k–£55k in annual savings.

Pattern 2: Over-Provisioned Azure SQL Database Tiers

Average waste: 18–30% of database spend

Azure SQL Database offers multiple purchasing models — DTU-based and vCore-based — and within each model, a range of service tiers. The consistent finding: organisations provision for the highest tier they have ever needed and never scale down.

The specific failure pattern: a business application experienced slow queries during a data migration project 18 months ago. The DBA bumped the SQL tier from S3 (100 DTUs, ~£73/month) to P1 Premium (125 DTUs with in-memory OLTP, ~£415/month) to resolve it. The migration completed. The tier was never reduced. The database now runs at 12% DTU utilisation on a Premium tier.

Finding over-provisioned SQL databases:

Azure SQL Intelligent Insights provides DTU consumption history. But for a systematic audit:

1. Azure Portal → SQL Databases → select database → Metrics
2. Add metric: DTU percentage (or CPU percentage for vCore)
3. Set time range: last 30 days, 1-hour granularity
4. Look for databases with max DTU under 60% and average under 30%

For multiple databases, use Azure Resource Graph:

Resources | where type == "microsoft.sql/servers/databases" | project name, resourceGroup, sku = properties.currentSku

Then cross-reference SKU costs against actual utilisation from Azure Monitor.

The fix:

• Databases with average DTU < 30% and max DTU < 60%: downsize by one service tier
• Multiple underutilised databases on the same server: consider elastic pools — a shared DTU pool that can be significantly cheaper than individual databases at the same combined tier
• Databases used only for reporting/analytics: consider migrating to Azure Synapse serverless SQL (pay-per-query, no reserved capacity) — can reduce costs by 70–90% for low-frequency analytical workloads

Pattern 3: Unattached Storage Disks and Orphaned Snapshots

Average waste: £800–£4,000/month depending on environment size

When a virtual machine is deleted, its managed disks and snapshots are not automatically deleted unless specifically configured. Most organisations delete VMs — to decomission old environments, after project completion, when migrating to containers — without deleting the associated storage.

Premium SSD managed disks cost £0.12–£0.28 per GB per month. A 512GB P20 disk costs approximately £54/month. Unattached, it provides zero value while continuing to bill.

Finding orphaned disks:

// Azure Resource Graph query Resources | where type == "microsoft.compute/disks"

For snapshots:

Resources | where type == "microsoft.compute/snapshots" | project name, resourceGroup,

Snapshots older than 90 days with no corresponding active disk should be reviewed for deletion. Snapshots older than 180 days in non-production environments should almost certainly be deleted.

The fix:

• Unattached managed disks: confirm with the team that created them that they are genuinely obsolete, then delete. Do not immediately delete without confirmation — some teams detach disks temporarily during maintenance.
• Old snapshots: implement a retention policy. In most cases, 30-day snapshot retention for production, 7-day for non-production, is sufficient and a significant cost reduction.
• Prevention: use Azure Policy to automatically tag resources at creation with the creating team and a review date. Configure budget alerts when unattached disk counts exceed a threshold.

Pattern 4: Egress Charges (The Bill Nobody Plans For)

Average waste: £500–£8,000/month for data-intensive workloads

Azure charges for data leaving the Azure network — to the public internet, to other Azure regions, and (at lower rates) to other Azure availability zones. Incoming data (ingress) is free. This asymmetry creates a billing pattern that surprises almost every organisation that has not specifically planned for it.

The most common sources of unexpected egress charges:

• Cross-region replication: Replicating data from UK South to West Europe for disaster recovery generates inter-region egress charges at £0.014–£0.052 per GB depending on regions
• Reporting workloads pulling data: Analytics tools querying Azure SQL or Blob Storage from outside Azure generate internet egress charges (£0.06–£0.08/GB)
• Application logging to external SIEM: Streaming logs from Azure Monitor to an on-premises or third-party SIEM can generate significant egress
• Media streaming: Video or large file downloads from Azure CDN are billed separately from standard egress but still accumulate

Finding egress spend:

Azure Cost Management → Cost Analysis → filter by Meter Category: "Bandwidth". Group by Resource Group and Meter Sub-Category to identify the specific egress types.

The fix:

• Move analytics workloads inside Azure (use Azure Analysis Services or Synapse instead of pulling data out)
• Use Azure CDN for media delivery — CDN egress is cheaper than direct Storage egress and significantly better for end users
• Evaluate Private Endpoints for internal services to eliminate cross-region data charges
• For DR replication, calculate whether Azure Site Recovery's bundled egress costs less than manual replication

Pattern 5: Non-Production Environments Running 24/7

Average waste: £15,000–£60,000/year

Development, staging, and QA environments are provisioned to match production and then left running continuously. In most organisations, these environments are actively used 8–10 hours per day on weekdays — and idle the remaining 128 hours of the week.

A staging environment that mirrors a £15,000/month production environment costs the same amount whether it is being used or not. Running it only during business hours (50 hours/week vs. 168 hours/week) reduces that cost by 70%: £10,500/month savings.

The fix:

• Azure Automation runbooks to start/stop non-production resource groups on a schedule
• Azure DevTest Labs for developer environments with built-in auto-shutdown policies
• B-series burstable VMs for non-production workloads that do not need consistent CPU performance
• Azure Dev/Test subscription pricing (available via Visual Studio subscriptions) for qualifying workloads — up to 55% discount on specific VM series

Pattern 6: Redundant Data Copies Across Storage Tiers

Pattern 7: Unused App Service Plans Keeping Slots Warm

Pattern 8: Azure Monitor Log Retention Beyond Compliance Requirements

These three patterns each typically contribute £500–£5,000/month in waste for mid-market organisations. The common thread: resources provisioned once and never revisited. Log Analytics workspaces defaulting to 90-day retention when 30 days meets compliance requirements. App Service Plans retained after their applications were containerised. Storage accounts duplicating data already backed up by Azure Backup.

Each requires the same process: inventory, utilisation review, deletion or rightsizing confirmation from the resource owner, and implementation of a tagging/review policy to prevent recurrence.

Real Client Outcome: £340k Savings on a £890k Annual Bill

A UK professional services firm with 400 employees came to Techseria with a straightforward problem: their Azure bill had grown from £420k/year in 2022 to £890k/year in 2024, while headcount and revenue had grown by only 15%. They could not explain where the additional £470k was going.

Techseria's 30-day Azure cost review found:

Overspend Pattern Annual Waste Identified

Idle and oversized VMs (47 VMs reviewed) £94,000

Over-provisioned SQL tiers (12 databases) £67,000

Non-production environments running 24/7 £82,000

Orphaned disks and snapshots £38,000

Egress from on-premises analytics tools £31,000

Unused App Service Plans £18,000

Log retention over-configuration £10,000

Total identifiable waste £340,000

Implementation of the optimisation roadmap over 60 days brought the annual bill from £890k to £550k — a 38% reduction. The 30-day review and 60-day implementation cost £28,000 in consulting fees. The payback period was 30 days.

The 60-Day Optimisation Timeline

Days 1–15: Discovery and Analysis

• Export complete Azure inventory via Resource Graph
• Pull 90-day cost history from Cost Management, grouped by resource
• Run idle VM queries across all subscriptions
• Audit all SQL database tiers against utilisation data
• Identify orphaned storage (unattached disks, old snapshots)
• Categorise all non-production environments

Days 16–30: Recommendations and Approvals

• Present findings to relevant technical owners for confirmation
• Obtain sign-off on deletions (critical: do not delete without confirmation)
• Design auto-shutdown schedules for non-production environments
• Identify Reserved Instance opportunities (see blog 11 for RI strategy)

Days 31–45: Implementation — Quick Wins

• Delete confirmed orphaned resources
• Implement auto-shutdown for non-production environments
• Downsize confirmed over-provisioned VMs and SQL databases
• Consolidate underutilised databases into elastic pools

Days 46–60: Implementation — Structural Changes

• Purchase Reserved Instances for stable production workloads
• Implement Azure Policy for tagging and resource lifecycle
• Configure budget alerts with appropriate thresholds
• Establish monthly cost review process with ownership assigned

Start With a Baseline

The first step in any Azure cost optimisation engagement is understanding your current baseline: what you spend, what you spend it on, and how that has changed over time.

Techseria's Azure Cost Review — fixed fee, 30 days — produces a complete waste analysis with prioritised recommendations, saving estimates with confidence levels, and a 60-day implementation roadmap. The engagement pays for itself before implementation begins.

[Book a Strategy Session](https://techseria.com/contact) to discuss your Azure environment and get a quote for your cost review. Or if you already have Azure Cost Management access and want to start the analysis yourself, ask us for our free Azure cost audit query pack — a set of Resource Graph and Log Analytics queries that surface the most common waste patterns in under an hour.