FinOps in Practice: How to Cut Your Azure Bill by 40% Without Reducing Performance

The average organisation wastes 32% of its cloud spend, according to Flexera's State of the Cloud report. In most Azure environments I review, that figure is conservative — it's common to find 40–50% savings opportunities in the first month of a proper cost review.

The problem isn't that cloud is expensive. Cloud can be remarkably cost-efficient. The problem is that cloud costs are a direct output of engineering decisions, and most engineering decisions are made without cost as a first-class constraint.

This article gives you a systematic, category-by-category framework for identifying and capturing cloud savings — without touching a single business feature or reducing performance.

The FinOps Mindset

FinOps (Financial Operations) is a discipline, not a tool. The core principle: cloud costs are engineering decisions, and engineers should understand and own the cost implications of those decisions.

This requires a cultural shift. In most organisations, cloud costs are owned by finance, monitored by DevOps, and invisible to the developers who create them. FinOps closes that loop: engineers see the cost impact of their work, understand why it matters, and make design decisions with cost as a first-class consideration alongside performance and reliability.

The FinOps Foundation's maturity model has three stages: Inform (visibility), Optimise (action), and Operate (continuous practice). Most organisations are stuck at Inform — they have cost dashboards but no action loop.

Category 1: Compute Right-Sizing (Typically 20–35% Savings)

Over-provisioned compute is the largest single source of cloud waste in most environments. The root cause: teams provision VMs for peak theoretical load, never revisit the sizing, and watch utilisation hover at 10–15%.

The action:

1. Pull 30 days of CPU and memory utilisation from Azure Monitor for all VMs
2. Identify any VM where average CPU utilisation is below 20% and maximum is below 50%
3. Check Azure Advisor's "Right-size or shut down underutilized virtual machines" recommendations — it does this automatically
4. Right-size to the recommended SKU, testing in staging first

For AKS clusters: Use the Vertical Pod Autoscaler (VPA) in recommendation mode to see suggested CPU/memory request changes. Right-size pod requests to match actual consumption, not "just to be safe" values.

Category 2: Reserved Instances and Savings Plans (30–60% Savings)

Pay-as-you-go pricing is the most expensive way to run predictable workloads. For anything you know you'll run for 12+ months, reservations deliver substantial savings.

Azure Reserved VM Instances — Commit to a VM family and region for 1 or 3 years in exchange for up to 60% discount. The reservation is applied automatically against any matching running VMs.

Azure Savings Plans — More flexible than Reserved Instances: commit to a compute spend amount ($/hour) rather than a specific VM family, applied across any compute service (VMs, App Service, Container Instances).

How to scope the reservation:

1. Identify your stable baseline — the minimum compute you'll run at any time, 24/7, for the next 12 months
2. Calculate the on-demand cost of that baseline
3. Purchase reservations to cover the baseline; let elasticity handle peaks on PAYG
4. Review quarterly: add reservations for new stable workloads, let expired ones lapse for decommissioned ones

Typical result: 30–60% savings on the reserved portion. For a £50k/month compute bill with a 60% stable baseline, this yields £9k–18k/month in savings.

---

Category 3: Idle and Orphaned Resources (5–15% Savings)

Every Azure environment accumulates resources that are no longer needed but continue to incur charges. Finding and removing them is pure savings with no trade-offs.

Idle compute: VMs that are powered on but not serving traffic. Check CPU utilisation over 30 days — a VM consistently below 2% CPU is likely idle. Confirm with the owner, then shut down.

Orphaned managed disks: When a VM is deleted, its managed disks are often not deleted. They continue incurring storage costs indefinitely. In Azure Cost Management, filter by resource type "Managed Disks" and check for disks not attached to any VM.

Unused public IP addresses: Static public IPs unattached to a resource still cost money (a small amount, but they add up). Filter by resource type "Public IP Address" and look for unattached ones.

Forgotten development environments: Dev and staging VMs that were created for a project and never decommissioned. Check VM creation dates and last-modified dates. Anything not touched in 90 days should be reviewed with the owning team.

Load balancers and application gateways with no backends: These are easy to miss — the resource is "serving" but has no backends to route to.

---

Category 4: Non-Production Environment Scheduling (10–20% Savings)

Development, staging, and QA environments don't need to run 24 hours a day, 7 days a week. A developer workday is roughly 9 hours in a single timezone. Running environments for 168 hours/week when they're used for 45 hours/week is an 73% waste on those environments.

The action: Implement automated start/stop schedules using Azure Automation or Azure DevOps pipelines:

• Start: Monday–Friday at 07:00 local time
• Stop: Monday–Friday at 19:00 local time
• Weekends: Stopped entirely (or on-demand via a Slack bot)

For AKS non-production clusters: Stop the cluster entirely outside business hours — az aks stop --name and az aks start --name. This stops billing for VM costs while preserving configuration. Combine with a simple GitHub Actions workflow triggered on a schedule.

Typical result: 50–65% reduction in non-production compute costs.

---

Category 5: Storage Tiering and Lifecycle Policies (5–10% Savings)

Azure Blob Storage has four access tiers: Hot, Cool, Cold, and Archive. Most organisations store everything in Hot tier regardless of access patterns — paying Hot prices for data that hasn't been accessed in months.

Implement lifecycle management policies that automatically transition blobs between tiers based on last-access time. This is a set-and-forget optimisation that delivers ongoing savings:

{
  "rules": [{
    "name": "tiering-rule",
    "type": "Lifecycle",
    "definition": {
      "actions": {
        "baseBlob": {
          "tierToCool": { "daysAfterLastAccessTimeGreaterThan": 30 },
          "tierToArchive": { "daysAfterLastAccessTimeGreaterThan": 180 }
        }
      }
    }
  }]
}

---

Category 6: Database Optimisation (10–25% Savings)

Databases are often the most over-provisioned resource in an Azure environment. Azure SQL, Cosmos DB, and PostgreSQL Flexible Server all have multiple pricing dimensions that can be optimised.

Azure SQL and PostgreSQL: Review DTU/vCore allocation against actual utilisation. Many databases run at <20% capacity. Consider downgrading tiers, enabling serverless compute tier for variable workloads (Azure SQL Serverless), or consolidating multiple small databases into an Elastic Pool.

Azure Cosmos DB: Review the provisioned throughput (RU/s) against actual usage. Cosmos DB's autoscale feature allows you to set a maximum RU/s and pay only for what you use — often dramatically cheaper than manually provisioned throughput for variable workloads.

Read replicas vs. caching: If you're using read replicas primarily to offload read traffic, evaluate whether Azure Cache for Redis could handle the same use case at lower cost.

---

Category 7: Networking and Data Egress (5–10% Savings)

Data egress (traffic leaving Azure) is charged per GB in most regions. This is frequently overlooked and can be a significant cost driver for data-intensive workloads.

Common egress optimisation:

• Place resources that communicate heavily in the same Azure region to minimise cross-region transfer costs
• Use Azure CDN or Azure Front Door to serve static content from edge locations, reducing origin bandwidth
• Evaluate whether your backup process unnecessarily moves large volumes of data across regions
• Review Log Analytics data ingestion — verbose application logs sent to Log Analytics can add up quickly; configure sampling for high-volume trace events

---

Building a Continuous FinOps Practice

One-time cost optimisation exercises yield temporary results. Cloud costs grow with product usage; without an ongoing practice, waste accumulates again within months.

The monthly FinOps cadence:

1. Cost review meeting (30 minutes) — Review the top 10 cost items vs. prior month. Flag any unexpected increases. Assign ownership.
2. Advisor recommendations review — Azure Advisor continuously surfaces right-sizing and reservation recommendations. Review and act on them.
3. Budget alerts — Set Azure Budget alerts at 80% and 100% of monthly targets to catch runaway costs before the invoice arrives.
4. Quarterly reservation review — Review reservation utilisation and coverage. Purchase new reservations for stable workloads, let unused ones lapse.

The goal is not to minimise cloud spend — it's to maximise the value delivered per pound spent. A team that's rapidly shipping valuable features at £50k/month is in better shape than one that's running idle infrastructure at £10k/month.

---

FinOps and cloud cost architecture are areas I work on with clients regularly. If you'd like a cost review of your Azure environment — with specific, prioritised savings recommendations — let's talk.