Power Automate Flows to Cut Unused Azure Costs

The cloud has a strange billing property. A server in your comms cupboard costs roughly the same whether it's busy or idle, so nobody worries much about turning it off. A virtual machine in Azure is billed by the hour, so an idle one is simply money leaking out. And because creating resources takes a few clicks, they pile up: a test server from last year's project, a disk from a VM someone deleted, a storage account for a one-off file transfer.

The fix is a mix of discipline and automation. This article walks through three Power Automate flows that do the hunting for you, along with an honest look at when Power Automate is the right tool and when Azure already has something simpler built in.

First, the mechanism that costs people money

Before any automation, it's worth knowing how Azure actually charges for a virtual machine, because it's the source of the most common mistake.

A VM has two separate bills: compute (the processor and memory, charged while the VM is allocated) and storage (its disks, charged as long as they exist). If someone shuts a VM down from inside Windows, the operating system stops, but Azure keeps the hardware reserved. The portal shows it as "Stopped", and you keep paying for compute. Only when the VM is deallocated, by stopping it from the Azure portal or through the management API, does the compute charge stop. The disks still cost money either way.

Now the maths that makes automation worthwhile. A week has 168 hours. A test or development server that's only needed during business hours, say 7am to 6pm on weekdays, is needed for 55 of them. Deallocate it the rest of the time and you're paying for roughly a third of the compute hours. Exact savings depend on the VM size and region, but cutting compute hours by around two thirds on non-production machines is an easy win.

Before you build: licensing and permissions

Power Automate talks to Azure through the Azure Resource Manager connector. That's a premium connector, so it isn't covered by the Power Automate rights included with Microsoft 365. For scheduled flows like the ones below, Microsoft's licensing requires a Power Automate Premium licence for the flow's owner rather than for everyone in the business.

The connector also signs in as the account that creates the connection, so the flow can do anything that account can do in Azure. Don't build these with a global administrator's personal login. Use a dedicated account with only the Azure role it needs, such as Virtual Machine Contributor on the relevant resource groups, and protect it with multi-factor authentication. An automation that can delete resources is a very attractive thing for an attacker to borrow.

Flow 1: deallocate non-production VMs out of hours

The problem: development, test and training VMs running all night and all weekend for nobody.

The flow:

1. Trigger: a scheduled (Recurrence) trigger at 7pm on weekdays.
2. Find the machines: use the connector's "List resources by resource group" action on your non-production resource groups, filtered to virtual machines.
3. Check the tag: for each VM, read its tags and continue only if it carries something like Environment = Dev and does not carry an opt-out tag such as KeepRunning = Yes.
4. Deallocate: use "Invoke resource operation" with the action deallocate on that VM.
5. Report: post a short message to a Teams channel listing what was stopped.

A matching flow can start the machines at 7am, or you can leave them off until someone needs one. Starting them only on request saves more, at the cost of a few minutes' wait.

The honest alternative: if all you need is "turn this VM off every night", Azure has a built-in Auto-shutdown setting on each VM that does exactly that without Power Automate or a premium licence. The flow earns its keep when you want tag-based rules across many machines, opt-outs, and a report people actually see.

Flow 2: a weekly report of orphaned disks

The problem: when you delete a VM, its disks don't necessarily go with it. Microsoft's documentation says it plainly: you continue to pay for unattached disks after the VM is gone.

How to spot one: every managed disk has a managedBy property. When it's attached to a VM, that property holds the VM's ID. When it's orphaned, the property is empty.

The flow:

1. Trigger: Recurrence, every Monday morning.
2. List disks: "List resources by subscription", filtered to the resource type Microsoft.Compute/disks.
3. Check each one: "Read a resource" for each disk, and keep only those where managedBy is empty.
4. Build a table: disk name, size, resource group, and the date it was created.
5. Email it: send the table to whoever looks after your Azure environment.

Notice what this flow doesn't do: delete anything. An unattached disk might be rubbish, or it might be the only copy of a server someone meant to rebuild. A human decides. The same pattern works for public IP addresses that aren't attached to anything, another small charge that quietly accumulates.

Microsoft publishes PowerShell scripts for finding unattached disks too. Use whichever your team will actually maintain.

Flow 3: clean up resources that were meant to be temporary

The problem: "temporary" is the most permanent word in IT. A storage account for a data migration or a VM for a three-week trial outlives the project by years because nobody remembers to delete it.

The fix is a convention, then a flow. Agree that anything temporary gets a tag like DeleteAfter = 2026-12-31 when it's created. Then:

1. Trigger: Recurrence, daily.
2. Find tagged resources: list resources and keep those with a DeleteAfter tag.
3. Compare dates: if today is later than the tag's date, it's expired.
4. Ask first: use the Approvals connector's "Start and wait for an approval" to send the owner a Teams card: "This resource expired on 31 December. Delete it?"
5. Act on the answer: if approved, "Delete a resource". If rejected, update the tag to a new date so the question comes back later.

Yes, a flow that deletes things automatically, with no human, would be more efficient. It would. It really would. And it would also, uh... eventually delete something important at 3am because someone typed 2025 instead of 2026. The approval step costs a few seconds of someone's day. Keep it.

Guardrails for all three flows

• Run in report-only mode first. For the first two weeks, have every flow email what it would do instead of doing it.
• Use resource locks on anything critical. A delete lock on production resource groups stops any automation, or any person, from removing them by mistake.
• Keep production out of scope. Point these flows only at non-production resource groups.
• Make sure backups exist before automating anything near data. Managed backup is the safety net when a cleanup goes wrong.
• Watch for failed runs. If the connection expires, the flow fails and the savings quietly stop.

When Power Automate isn't the best tool

Power Automate suits businesses that already use Microsoft 365 and want results in Teams and Outlook. For bigger environments, Azure's own tools often fit better: Azure Advisor flags underused VMs and other cost recommendations, Cost Management budgets alert you before spending runs over, and Azure Automation runs scheduled scripts without a Power Automate licence. Most businesses end up with a combination.

And automation only fixes waste you can see. Right-sizing VMs, choosing the right storage tier, and deciding which servers belong in the cloud at all are design decisions. Our Azure cloud team does that work, and an IT audit is a good way to find out how much is leaking. If you're weighing up cloud versus on-premises, our server infrastructure page covers the trade-offs.

Frequently asked questions

Can Power Automate shut down Azure VMs?

Yes. The Azure Resource Manager connector's "Invoke resource operation" action can deallocate a VM, and a scheduled trigger can run it every evening. The connector is premium, so the flow owner needs a Power Automate Premium licence.

Do you pay for a stopped VM in Azure?

If it was shut down from inside the operating system, yes, because Azure still reserves the compute. Stop it from the Azure portal or API so it's "Stopped (deallocated)" to end compute charges. You still pay for its disks either way.

How do I find unused resources in Azure?

Check Azure Advisor's cost recommendations for underused VMs, look for managed disks whose managedBy property is empty (they're unattached), and review public IP addresses that aren't associated with anything. A weekly automated report keeps the list from growing again.

Should automation delete Azure resources automatically?

Not without a check. Report first, delete only resources with an agreed expiry tag, add an approval step before deletion, and put resource locks on anything critical. Make sure backups exist before any cleanup touches data.

Local IT and cyber security support across NSW

Chewing IT runs managed IT and cyber security for small and mid-sized businesses from our Wyong and Hornsby offices, covering the Central Coast, Newcastle, Lake Macquarie and Hornsby.

Paying for Azure resources nobody uses? Book an Azure cost review and we'll find the waste and automate the cleanup safely.