Microsoft Cloud guide

Azure Cost Optimization: 10 Quick Wins

December 20, 2024 · 8 min read · Big Sky Dynamics

Practical strategies to reduce your Microsoft Azure spending without sacrificing performance.

Email me the PDF More free guides

Start with the invoice, not the console

Cost optimization fails when it starts with a list of best practices. Start with the bill: export the last three months of cost by resource group, service and meter, and rank the top twenty line items. In most subscriptions a small number of resources and meters explain the majority of spend, and those are the only ones worth touching first.

Tag every resource with owner, environment and workload before you optimize anything. Untagged spend cannot be attributed, and unattributed spend always grows, because nobody defends it.

The ten quick wins

• Rightsize: compare 30-day peak CPU and memory with the SKU you buy; step down one size on the top ten off-peak VMs, then remeasure.
• Kill idle: find resources with under five percent CPU or no network traffic for 14 days, then snapshot and delete rather than leaving them running.
• Reserve the steady state: apply one-year reservations to the baseline that will not move, and keep burst on pay-as-you-go.
• Use savings plans for compute you would buy anyway; they trade a commitment for a lower rate without pinning a region.
• Turn off dev and test on a schedule: 12 hours a day and weekends is a 65 percent reduction on those workloads.
• Move cold data to the right tier: lifecycle rules on blob storage, archive what legal allows, delete what neither policy nor product needs.
• Clean orphaned disks and public IPs: unattached disks and unused static addresses are pure waste.
• Right-size the database tier: check DTU/vCore utilization and storage growth before renewing a premium tier.
• Watch egress: move chatty services into one region and put a CDN in front of public assets.
• Set budgets and anomaly alerts per subscription so a runaway resource is a notification, not a surprise invoice.

Rightsizing without breaking production

Use a two-week observation window, not a single load test. Capture CPU, memory pressure, disk queue and network at the 95th percentile, then move down one step and keep the old SKU as a documented rollback. Resize in the maintenance window and watch the same metrics for a week before you touch the next group.

The trap is rightsizing by average CPU. A machine that sits at four percent average but spikes to full on an hourly batch will fail at the smaller size; the percentile tells you which one you have.

Commitment strategy that survives change

Reservations and savings plans are a bet on a baseline. Split your estate into a stable core (always-on services), a seasonal band (predictable peaks) and a volatile tail (experiments, migrations). Commit only the core, use savings plans for the band, and leave the tail on-demand. Review the commitment coverage monthly; anything beyond roughly 80 percent coverage is usually overcommitted.

Governance is the durable win

The quick wins will regrow unless the guardrails change. Put an Azure Policy in place that requires the cost tags, blocks expensive SKUs in development subscriptions, and denies public IPs by default. Give each workload an owner who sees its bill. Publish a monthly variance report with the top five movers and a required comment for any increase above ten percent.

This is the difference between a one-time cleanup and a cost culture: the first saves money this quarter, the second keeps saving it.

A 30-day plan

Week one: export cost data, apply tags, enable budgets and anomaly alerts. Week two: delete idle and orphaned resources, schedule dev/test shutdowns. Week three: rightsize the top ten VMs and set storage lifecycle rules. Week four: buy reservations against the verified baseline and publish the first variance report.

Measure the result against the original invoice, not against the discount you were promised, and keep the monthly review on a calendar.