Remove application gateways with empty backend pools

An empty-pool application gateway is one of the cleaner savings line items you will find in Azure, because the resource produces no value at all: it routes nothing, so there is no service to protect, no migration to weigh, no performance trade-off. The whole charge is waste. Microsoft documents the v2 fixed gateway-hour cost as a flat per-hour rate billed for every hour the gateway is provisioned, even with zero instances and zero traffic, so a gateway left running all month pays that rate across roughly 730 hours whether or not anything is connected to it.

The saving is immediate and complete. Stopping the gateway stops its billing the same way starting it resumes billing, so an idle gateway you stop today stops costing you this hour, not next budget cycle. Deleting it removes the resource and any residual charges entirely. There is no payback period to model because there is no spend to recover: you are simply switching off a meter that was running against nothing.

Frame each idle gateway as a recurring charge with a known monthly figure, not as a one-off cleanup. The right metric for the cost review is the sum of fixed gateway-hour cost across every empty-pool gateway in the estate, annualised, because that is the figure that keeps reappearing on the bill until someone acts on it.

Priya is the finance partner sitting in on the quarterly cost review when application gateway spend comes up as a line nobody can fully justify. The workbook flags three gateways with empty backend pools. The instinct is not to ask what it will cost to remove them, because removing them costs nothing. It is to put a number on what they are costing while they stay. Priya asks the team for the SKU and the running time of each: two are Standard_v2 and one is WAF_v2, which carries the higher fixed rate, and all three have been running for months.

The figure is straightforward to build. Each gateway pays a fixed gateway-hour cost for roughly 730 hours a month, so Priya takes the published per-hour fixed rate for each SKU, multiplies by the hours, and sums across the three. The result is a recurring monthly charge that has been buying nothing, and annualised it is the number that goes on the savings tracker. The finance pack reads: 'Three idle gateways, full fixed cost recoverable immediately, no service behind any of them, no payback to model because there is no spend to recover, only a meter to switch off.' The only nuance flagged is the staging gateway, which the team must confirm is genuinely abandoned and not waiting on a backend that is still being built.

Most cost work involves a judgement call: reduce capacity and you might hurt performance, buy a reservation and you commit for a year. Idle application gateways have none of that. The resource delivers zero value, so the entire fixed charge is recoverable with no downside, which makes this one of the highest-confidence savings on the board. The expected return is simply the fixed gateway-hour cost you stop paying.

The figure is easy to defend because Microsoft publishes the inputs. The fixed cost is a flat per-hour rate per SKU, billed across roughly 730 hours a month, with WAF_v2 carrying a higher fixed rate than Standard_v2. Multiply the rate by the hours for each idle gateway, sum across the estate, and you have an annualised saving with a clear provenance. There is no payback period because there is no investment, and the saving lands the same hour the gateway is stopped. The finance role is to keep this on the recurring-savings tracker rather than treating it as a closed one-off, because the lifecycle gap that created these gateways will create more.

An application gateway with no backend is the clearest possible example of cloud waste: a resource that costs real money every hour and returns an error to anyone who touches it. There is no service behind it to disrupt, so there is no reason to keep it, yet it sits on the bill because nobody connected the front door to a finding.

The leadership question is not whether to spend money to fix this. It is why these gateways exist at all and why they were not caught sooner. The answer is almost always lifecycle: something was built, the work moved on, and the teardown step was skipped. The fix costs nothing and recovers the full charge the moment the gateway is stopped.

This is the kind of waste that, multiplied across a large estate, adds up to a meaningful annual number while being individually invisible. Treating it as a routine, automated sweep rather than a one-off cleanup is what stops it accumulating again.

The cost review surfaced three application gateways routing nothing, and the CFO's question was the obvious one: how long have we been paying for these, and how many more are there. The honest answer was that nobody knew, because there was no routine that looked for them. They had been found this time only because the quarterly workbook happened to flag them.

The team's response was to stop treating it as a one-off cleanup. They removed the three idle gateways, recovering the full fixed cost immediately, and then put the empty-pool query into a scheduled report that runs against every subscription, so any gateway that loses its backend shows up within days rather than at the next audit. The shift the leadership cared about was not the size of this quarter's saving, which was modest, but moving from 'we find these by accident' to 'these cannot accumulate unnoticed', because that is what stops the same line reappearing on every future bill.

The cost of an idle gateway is small per unit and unbounded over time: it bills every hour until someone notices, and nobody notices because it is invisible against the wider bill. The saving from removing it is immediate and complete, with no service to disrupt and no risk to weigh, which makes it the rare cost decision that needs no analysis, only execution.

The leadership move is not to approve each removal but to require that the estate is swept for them on a schedule, so idle gateways are caught within days of their backend disappearing rather than at the next audit. That converts a recurring leak into a closed loop, and it is the difference between recovering this quarter's waste once and preventing it from accumulating again.