The invoice itself is rarely wrong. What is usually missing is a way to connect each line to a workload, an owner and a business reason. This article walks through the areas that account for most consumption, and what to look at in each.
Compute
Virtual machines are typically the largest single line, and the one with the most recoverable waste. The questions worth asking in order:
- Is it running when nobody is using it? Development, test and training environments rarely need to run outside business hours, and scheduled shutdown is one of the few changes with no downside.
- Is it sized for what it does, or for what somebody guessed during migration? Machines lifted from on-premises are often sized for a five-year peak that never arrived.
- Is it still needed at all? Decommissioned projects leave running machines behind more often than anyone expects.
- Is the commitment model right? For workloads that genuinely run continuously, reservations and savings plans reduce the rate substantially in exchange for a term commitment. They are worth modelling once usage is stable — committing to the wrong size is its own kind of waste.
Right-sizing has a caveat worth stating: performance data should come from a representative period, including month-end and any seasonal peak. Resizing on a quiet fortnight's data is how a cost exercise turns into a performance incident.
Storage
Storage looks cheap per gigabyte, which is exactly why it accumulates. The cost drivers are less obvious than the capacity number:
- Tier. Frequently accessed, infrequently accessed and archive tiers differ substantially in price, and in what it costs to read the data back.
- Disk type. Premium SSD attached to a machine that does light file serving is a common inheritance from a default choice during migration.
- Snapshots, which are easy to create, easy to forget, and continue to consume capacity indefinitely.
- Retained data that no longer has a business reason to exist. Retention is a policy question before it is a storage one — and under POPIA, keeping personal information longer than necessary is a compliance matter as well as a cost.
- Transaction costs. Some workloads generate very high operation counts against storage, and on cool or archive tiers those operations, not the capacity, become the dominant charge.
Networking
Networking charges surprise people because the expensive direction is not the intuitive one. Moving data into Azure is generally free; moving it out, and moving it between regions or availability zones, is not.
- Outbound data transfer, particularly from backup replication, data platform queries, or a chatty application whose tiers sit in different regions.
- VPN and ExpressRoute gateways, which bill for existence rather than usage.
- Load balancers and application gateways, where the tier chosen determines a standing hourly rate.
- Public IP addresses, individually trivial and collectively noticeable when an estate has accumulated dozens.
Architecture decisions drive this more than usage does. Keeping components that talk to each other in the same region is a design choice with a recurring monthly consequence.
Backup and disaster recovery
Protection is a genuine cost, not waste — but it is frequently sized by habit rather than by requirement. Retention inherited from a tape rotation designed two decades ago can multiply stored capacity several times over without anybody having decided to.
- Backup storage consumed, and the retention policy actually driving it.
- Replication for disaster recovery, which duplicates both storage and, during a test or failover, compute.
- Standby infrastructure — how much needs to exist continuously versus what can be provisioned at the point of failover.
The right conversation is about recovery objectives. Once the business has agreed how much data it can lose and how long it can be down, the design follows, and so does the cost. Working the other way round produces either overspend or an unpleasant surprise during an incident.
Licensing
Microsoft licensing and Azure consumption interact, and the interaction is not always visible on the invoice. Existing Windows Server and SQL Server licences with active Software Assurance may be applicable to Azure workloads under Microsoft's terms, which changes what the compute line should look like.
We deliberately avoid quoting percentages here, because entitlement depends on the specific agreement, the version, and how the licences were acquired. It is worth having somebody read the actual agreement rather than assuming either that the benefit applies or that it does not. The same applies to development and test subscriptions, which carry different rates under specific conditions.
Monitoring and security
Log ingestion is the line that grows quietly. Monitoring and security platforms generally charge by data ingested and data retained, and both numbers rise as the estate grows and as more sources are connected.
- Which log sources are connected, and whether each one is being used for something — an alert, a dashboard, or a compliance requirement.
- Retention periods, which often exceed what any policy actually requires.
- Verbose diagnostic settings left enabled after a troubleshooting exercise.
The trap is treating this purely as a cost to cut. Reducing ingestion by disconnecting a security-relevant source saves money and reduces your ability to investigate an incident. The judgement is about which data earns its retention, not about minimising the number.
The real problem is visibility, not price
Nearly every unexpected Azure bill we are asked to look at has the same underlying cause. Not an expensive service, but an inability to answer simple questions about it.
- No consistent tagging, so consumption cannot be attributed to a department, project or environment.
- No named owner for a resource, so nobody has the standing to switch it off.
- Resources left running after the work that needed them finished.
- Workloads sized during migration and never revisited.
- No budget, threshold or alert, so the first signal is the invoice.
- No governance about who can create resources and under what conditions.
Fixing these is unglamorous and durable. A tagging standard applied at creation, budgets with alerts per subscription or resource group, a monthly review with the people who own the workloads, and a policy about what can be provisioned by whom. None of it is technically difficult. It is organisational work that happens to be expressed in a cloud platform.
Azure optimisation is not simply about making the bill smaller. It is about making cloud consumption visible, accountable and aligned to actual business requirements.
Key takeaways
- Start with compute: shut down non-production outside business hours, right-size on representative data, and remove what is no longer used.
- Check storage tier and disk type against what the workload actually needs, and treat retention as a policy decision.
- Expect networking cost from outbound transfer and standing gateway charges — these are architecture decisions with monthly consequences.
- Have somebody read the actual licensing agreement rather than assuming existing entitlements do or do not apply to Azure.
- Most overspend is a visibility problem: tagging, ownership, budgets and governance solve more than any single technical change.
