Azure cost optimization: Reservations, Hybrid Benefit, and Advisor

Azure cost optimization is a four-axis pass, not a one-line rightsizing swap. The axes stack in a deliberate order — idle workload hygiene first (no user-facing change, the highest signal-to-noise on any estate), then rightsizing against p95 trailing usage (the highest per-unit saving once idle is gone), then Azure Reservations (https://learn.microsoft.com/azure/cost-management-billing/reservations/save-compute-costs-reservations) vs Savings Plans for Compute (https://learn.microsoft.com/azure/cost-management-billing/savings-plan/overview) (the highest absolute saving, but only after the post-rightsizing baseline is stable), then Azure Hybrid Benefit (https://learn.microsoft.com/azure/virtual-machines/windows/hybrid-use-benefit-overview) for Windows Server and SQL Server (licenses you are already paying for, recognised against Azure compute). This is the on-page runbook the Tallywyrm agent drives on a real Azure subscription; it composes the framework in the FinOps multi-cloud playbook (/blog/finops-multi-cloud-2025-playbook) and the audit shape in the multi-cloud waste-audit playbook (/blog/multi-cloud-waste-audit-playbook) into one provider-scoped guide. The Azure rightsizing-with-Terraform pillar (/blog/azure-rightsizing-terraform-guide) is the closest cousin — read that one once you have chosen Terraform / Pulumi / Crossplane and want a resource-family-scoped diff; this one stays at the platform shape and the four-axis sequence above. The GCP cost optimization pillar (/blog/gcp-cost-optimization) and the AWS rightsizing pillar (/blog/aws-rightsizing-terraform-guide) cover the same sequence on the other two clouds — pair-read all three to land the cross-cloud audit shape. The audit-trail evidence a finance reviewer signs off on sits in the FinOps compliance pillar (/blog/finops-compliance-guide); the verification methodology is on the methodology page (/methodology); the pricing model that pays for the audit is on the pricing page (/pricing). Idle workload hygiene before sizing Idle workloads are the highest signal-to-noise pass on any Azure estate. The detection method is straightforward: pull the trailing 14-day CPU + network-in + network-out metrics at the VM level, and flag any VM where all three read below a configurable floor (a sensible default is 2% CPU and 1MB / day egress). The shift — stop, snapshot, delete, or schedule a nightly pause via Azure Automation's Start/Stop VMs during off-hours (https://learn.microsoft.com/azure/automation/automation-solution-vm-management) — is a one-line Terraform / Pulumi / Crossplane change, reversible without data loss because VM state is preserved through stop+start for the same SKU. The same idle hygiene sequence the waste-audit playbook describes (/blog/multi-cloud-waste-audit-playbook) applies on Azure as on any other provider. The blocker is usually a missing tag — a workload that should be idle was never tagged "non-prod" because nobody owned the tag taxonomy. Fix the taxonomy first; the pass becomes trivial. Untagged resources still surface under the Advisor "Cost" recommendation feed, but with a lower confidence band than a tagged workload whose non-prod status is asserted in the tag itself. Rightsizing against p95, not average Picking a target VM size off average CPU is the single biggest mistake in a first-time Azure rightsizing pass. Average utilization on a load-balanced stateless service tells you almost nothing about whether your smallest machine size still fits the workload's tail-latency budget; p95 latency under peak is what your SLO actually depends on. Always size against trailing 14–30 day p95 CPU and p95 memory, with a safety margin that honours the workload's contract. The B-series is the cheapest shape on Azure for burst-tolerant workloads — B2S / B2ms / B4ms accumulate CPU credits during idle periods and consume them during short bursts. The trap is the credit ceiling: a B-series VM that exhausts its credits reverts to baseline performance, which reads as a 90-minute brown-out for the consumer. A rightsizing recommendation that swaps a D-series VM for a B-series VM without checking the workload's burst pattern is the auditor's favourite example of a wrong target. The rule of thumb: a workload whose burst window is at most 15 minutes every 4 hours is canonically B-series. The Terraform / Pulumi / Crossplane delta for an Azure rightsizing pass is a one-line `vm_size` swap on the `azurerm_linux_virtual_machine` (or `azurerm_windows_virtual_machine`) resource. The PR description carries the trailing-usage numbers, the target VM size, the burst-budget check, and the rollback path — a single PR reverting the `vm_size` line. The same audit trail the multi-cloud playbook describes (PR diff, deploy timestamp, post-deploy measurement) applies end to end. Azure Reservations vs Savings Plans Reservations (https://learn.microsoft.com/azure/cost-management-billing/reservations/save-compute-costs-reservations) are scoped to a specific VM SKU / SQL DB SKU / specific Azure service in a specific region — a one-year or three-year commitment that earns up to ~72% discount against pay-as-you-go in exchange for capacity predictability. They are the right shape when the workload's SKU and region are stable (steady-state production fleets, SQL DB elastic pools, dedicated hosts) and the team is willing to pay for capacity they no longer fully use after a downstream sizing pass. Savings Plans for Compute (https://learn.microsoft.com/azure/cost-management-billing/savings-plan/overview) are the flexible shape — a one-year or three-year hourly commitment against any compute spend across eligible SKUs and regions. They earn up to ~65% (lower cap than reservations) but they move with the workload as SKUs change and regions shift. They are the right shape when the SKU mix is in motion (a rightsizing programme is reducing a fleet, a Kubernetes platform is migrating node sizes, a multi-region rollout is mid-flight) because the saving tracks the actual compute spend rather than locking it to a SKU that may not survive next quarter. The platform implication: anchor Reservations against the post-rightsizing baseline that is stable for at least one quarter; anchor Savings Plans against the portion of the bill that is in motion. Mixing the two is allowed — the typical pattern is Savings Plans for the moving baseline (60% of commit) and Reservations for the locked-in production tail. The audit trail records the commitment against the same six-field shape every other saving ships with — only the `changeArtifact` field differs (it carries the Reservation / Savings Plan purchase order rather than an IaC PR). > Composition rule: anchor 60–70% of the post-rightsizing baseline against commitments, refresh against trailing-usage audit trail, and surface under-utilised reservations the same way you surface idle resources. Layering a fresh Reservation on a workload that is itself rightsizing-eligible is the worst first move — you have locked in a discount on capacity the audit no longer needs to anchor. Azure Hybrid Benefit for Windows Server and SQL Server Azure Hybrid Benefit (https://learn.microsoft.com/azure/virtual-machines/windows/hybrid-use-benefit-overview) unlocks the use of existing on-premises Windows Server and SQL Server licences against Azure VMs and Azure SQL Database — the same licence cannot double-cover both an on-prem server and an Azure VM, but it can move between them when one is decommissioned. The saving is computed against the License-Included price, not the list price — Finance needs both views in the verified pool because line items on the invoice read against the License-Included baseline by default. The scope condition is Software Assurance: only licences currently covered by an active Software Assurance agreement are eligible, and the agreement must cover the entire period of the Azure deployment. The audit shape here is "verify, do nothing on Infrastructure-as-Code" — the FinOps agent reads the per-VM `HybridUseBenefit` license state (a property on `azurerm_virtual_machine` / `azurerm_sql_database`), compares it against the Software Assurance registry, and surfaces the per-row savings without an IaC change. The audit row carries the licence identity (Software Assurance enrolment ID + per-server agreement start date) linkable to the License Mobility verification. A common audit miss: SQL Server Standard Edition licences that already cover an on-prem instance get moved onto an Azure SQL Database without being reassigned away from the on-prem box. The double-cover is the auditor's favourite finding on a Hybrid Benefit review — the agent's job is to verify that the same licence identity is asserted against exactly one Azure resource at any moment. Azure Advisor recommendations interpretation Azure Advisor (https://learn.microsoft.com/azure/advisor/advisor-overview) is Microsoft's recommendation engine across five categories — Cost, Reliability, Performance, Security, Operational Excellence — and it ships an aggregate "potential benefit" score on each recommendation, broken down by Low / Medium / High tiers measured in dollars of forecasted monthly saving. The FinOps use case filters strictly to the Cost category; the other four are operations and security surfaces that belong to a different team and a different review board. The discipline of pairing the Advisor signal with the workload's trailing usage is the safeguard against the audit risk of "the agent recommended the wrong thing". Advisor's "potential benefit" is a forecast, not a measurement — it reads the current SKU and the trailing 14-day utilisation and projects the diff to the recommended SKU. The forecast is wrong in three frequent cases: a workload that is about to scale up next week (Advisor undercounts the saving), a workload with a seasonal pattern Advisor has not seen enough of yet (Advisor overcounts), a B-series target recommended against a baseline that would exhaust burst credits on the recommended SKU. Always pin every Advisor recommendation against the post-rightsizing trailing-usage reading from the rightsizing axis above before recommending. The review-board checklist item is: "show me the trailing 14-day p95 measurement that justifies this target". A recommendation without that measurement is not eligible for the report finance signs off on. The Terraform / Pulumi / Crossplane delta for an Advisor-derived rightsizing recommendation is the same shape the rightsizing pillar above describes — a one-line `vm_size` swap on the `azurerm_linux_virtual_machine` / `azurerm_windows_virtual_machine` resource — but the PR description also carries the Advisor recommendation ID and the potential-benefit score, so the reviewer can re-play the same line of reasoning on a future audit re-read. The Tallywyrm angle: IaC-native PR verification + timestamped savings audit trail The Tallywyrm agent writes every commit-class recommendation (idle hygiene, rightsizing, family swap) as a Terraform / Pulumi / Crossplane PR diff against the team's existing repo. For Reservations, Savings Plans and Hybrid Benefit — which are configuration primitives rather than resource-family IaC — the diff is a scoped `azurerm` resource or a tag-level amendment that carries the same PR-loop discipline: PR to human approver to merge to deploy timestamp. The deploy timestamp attaches in the same PR-loop. A week after deploy, the agent re-reads Azure Monitor (https://learn.microsoft.com/azure/azure-monitor/overview) (the trailing-usage signal), Cost Management (https://learn.microsoft.com/azure/cost-management-billing/cost-management-billing-overview) (the per-resource invoice projection) and Advisor (re-running the recommendation surface against the post-deploy state) and validates the realised saving against the forecasted saving from day 0. The audit row carries the six fields every saving ships with: resource identity, native cloud signal (Advisor recommendation ID where paired, or a directly read Cost Management line item), trailing-usage data from Azure Monitor, IaC diff (or Reservation / Savings Plan purchase order for the commitment axis), deployment timestamp, and post-deploy measurement timestamp + realised-saving cents. The same six-field shape applies to AWS / GCP pillars — one audit aggregator, one signed manifest. The verification methodology is on the methodology page (/methodology); the audit-trail evidence a finance reviewer signs off against the invoice is in the FinOps compliance pillar (/blog/finops-compliance-guide); the SOC 2 / ISO 27001 / EU CSRD / SEC climate disclosure mapping is on the security and compliance page (/security/compliance). The verified-pool pricing model (/pricing) is what pays for this audit: Tallywyrm charges a percentage of the realised saving, so the verification step is not optional — it is the unit of value the customer is paying for, and it is the moment the saving either confirms into the next invoice or registers as a regression and rolls back. A saving that does not verify at day 7 is removed; the customer's invoice is never charged for unverified projected savings. From playbook to the agent loop The single highest-leverage next step is to instrument the four cost levers above as concrete Terraform / Pulumi / Crossplane modules your team can review. Once the modules exist — one per axis, callable from your existing repo — the agent has a stable surface to write changes against, and your team has a stable surface to review changes from. New Azure levers land as the platform evolves (Azure now ships Compute Savings Plans 3-year terms and an expanded Hybrid Benefit scope for SQL Managed Instance) — start with the FAQ (/faq) for the security, credential scope and percentage-of-savings pricing questions, then talk to the team (mailto:tallywyrm@polsia.app) about a real audit on one of your own Azure subscriptions.

Azure cost optimization: Reservations, Hybrid Benefit, and Advisor

Send us your last month’s bill. We’ll show you what the agent finds.

Azure rightsizing with Terraform: a practical 2026 guide

FinOps for multi-cloud teams: a 2025 playbook

AWS rightsizing with Terraform: a practical 2026 guide

Azure cost optimization: Reservations, Hybrid Benefit, and Advisor

Send us your last month’s bill. We’ll show you what the agent finds.

Related posts

Azure rightsizing with Terraform: a practical 2026 guide

FinOps for multi-cloud teams: a 2025 playbook

AWS rightsizing with Terraform: a practical 2026 guide