Azure FinOps for Québec SMBs

The mechanics behind the drift

Since 2022, many Québec organizations have migrated to Azure at scale. The promise: flexibility, scalability, and the latest generation of services. The reality 24 months later, for many of them: a bill two or three times higher than the original estimate.

Azure itself is never the culprit. It comes down to four human and organizational dynamics that compound on each other:

• Machines oversized out of caution during the migration ("we'll downsize later" - which never happens).
• Test environments left running 24/7 (when they're only used 30 hours a week).
• No tagging, which makes it impossible to attribute costs to departments or applications.
• No governance around spinning up new resources - every team adds more with no visibility.

Why FinOps isn't just "cost cutting"

A "cut whatever stands out" approach creates collateral damage: critical resources end up undersized and crash under load, teams work around governance, and IT hiring takes the hit.

Modern FinOps, in the spirit of the FinOps Foundation Framework, pursues three goals at once: optimize existing costs, safeguard performance, and build a culture of shared accountability ("whoever uses it pays, whoever pays knows").

Lever 1 - Reserved Instances and savings plans (25-55% savings)

Microsoft offers two commitment-based mechanisms that meaningfully cut the cost of stable resources:

• Reserved Instances (RIs): a 1- or 3-year commitment on a VM, a SQL Database, or an App Service, with savings of up to 72% versus pay-as-you-go (1 year: 30-40% typically, 3 years: 55-72%).
• Azure savings plans (introduced October 2022): a 1- or 3-year commitment to an hourly volume of compute, more flexible than RIs (they apply across multiple SKUs and regions), with savings of up to 65% according to Microsoft.
• Where to apply them: on stable compute (over 70% utilization), 3-year RIs almost always come out ahead. On variable workloads, savings plans strike a better balance.
• The risk: committing 3 years to a workload that's going to migrate in 6 months is money down the drain. Always validate the application roadmap before any long RI commitment.

Lever 2 - Rightsizing (15-35% savings)

According to Azure Advisor and our own audits, 30 to 60% of production VMs are oversized by more than 30% relative to their actual usage. The reasons: caution during the migration, anticipated growth that never materialized, and copying on-premises specs without rethinking for the cloud.

The method: analyze 30 days of CPU/RAM/IOPS usage through Azure Monitor or Datadog. Identify underused resources (P95 below 40%). Propose new sizing, validate it with the business, and schedule the switch during a maintenance window.

Lever 3 - Automatic dev/test shutdown (60-70% savings on those environments)

Development and test environments are typically used 30 to 50 hours out of the 168 hours in a week. Left running 24/7, they consume 3 to 5 times their actual usage.

The method: an Azure Automation runbook (PowerShell) or an Azure Logic App that shuts down dev/test VMs at 7 p.m. and brings them back up at 7 a.m. on weekdays, leaving them off over the weekend.

Add a "manual restart" button for developers working weekends. Communicate it as "here's how this works," not "here's the new rule."

Lever 4 - Storage tiering (40-80% savings on cold storage)

Azure Blob Storage offers several tiers: Hot (frequent access), Cool (monthly), Cold (quarterly), and Archive (yearly or rare). The Archive tier costs about 1/10 of the Hot tier.

Where to apply it: all logs, older backups, long-term backups, and regulatory data belong in the cold tiers. Azure lifecycle management policies automate the transition based on the last-access date.

Lever 5 - Removing orphaned resources (a one-time gain that's often significant)

Unattached managed disks, unused public IPs, forgotten snapshots, orphaned NSGs, empty App Service plans: all billed, none in use. A typical one-time audit: 5 to 15% in immediate savings with zero operational impact.

Repeat it every 6 months - orphaned resources pile up as projects wrap up.