Cost

Release orphaned public IP addresses

One capability across the whole estate: find every standard-SKU public IP that is attached to nothing, or to a NIC that itself does nothing, and release it, because Azure bills a static public IP whether or not anything is using it.

12 min·10 sections·AZURE

Last reviewed 18 June 2026

Orphaned public IPs: the basics

Why does a public IP attached to nothing still cost money?

A public IP address is one of the few Azure resources that bills for simply existing. A standard-SKU static public IP is charged irrespective of whether it is associated with a running resource, so the moment you delete the virtual machine, load balancer or NAT gateway it used to front, the address keeps ticking on the bill while doing nothing at all. Microsoft documents this plainly: you are charged for a static public IP whether or not it is attached. That is the whole shape of this waste, an address sitting in a resource group with no ipConfiguration, quietly priced.

Orphans appear in two distinct shapes, and a good sweep catches both. The first is the truly unattached address: its ipConfiguration is null and it is not bound to a NAT gateway, so nothing in Azure references it. The second is subtler: an address that is still attached, but to a network interface on a virtual machine that has been stopped and deallocated for weeks, or to a load balancer with no backend. The address is technically in use, yet the thing it fronts does no work, so the spend is just as wasted.

Almost all of this is drift, not intent. A VM was rebuilt and its old IP was left behind. A load balancer was decommissioned but its frontend address was never released. The Basic SKU retired on 30 September 2025, and migrations to standard left a trail of detached addresses. Azure Advisor surfaces the unassociated ones under its cost recommendations, and the Cost Optimization workbook's Networking tab lists them with the 'Unattached Public IPs' query. The work is to release every address that fronts nothing, while keeping the handful you are holding on purpose, such as a reserved address kept for an allow-list that a partner has whitelisted.

In this lesson you will learn why an Azure public IP bills even when it is attached to nothing, how to find every orphaned address across a subscription, the two shapes an orphan takes, and how to release them safely without touching the handful you are holding deliberately. You will use Azure Advisor, the Cost Optimization workbook and the az CLI to build the inventory, then a single safe deletion loop and a Bicep-plus-policy backstop to stop the drift returning.

Fun fact

The address that outlived its server

When the Basic SKU public IP retired on 30 September 2025, a lot of estates discovered just how many addresses they had been carrying with nothing behind them. Basic dynamic IPs only cost money while attached, so they hid in plain sight for years; the move to standard, where a static address bills whether or not it is associated, turned a free orphan into a paid one overnight. The lesson teams took away was simple: in Azure, deleting the server is not the same as deleting its bill. The address has to be released explicitly, or it keeps charging long after the thing it fronted is gone.

Finding orphaned public IPs across a subscription

Priya runs the platform team at a mid-size SaaS company doing its first serious cost pass. Azure Advisor's cost tab is showing a recommendation to delete unassociated public IP addresses, and she wants to know how many there really are before anyone deletes anything.

Rather than work the Advisor list address by address, she starts from the CLI so she can separate the two shapes of orphan, the truly unattached and the attached-but-idle, before anything is released.

List the standard-SKU public IPs that are attached to nothing: no ipConfiguration and no NAT gateway. These are the clean orphans Advisor flags.

$ az network public-ip list --query "[?ipConfiguration==null && natGateway==null && sku.name=='Standard'].{name:name, rg:resourceGroup, ip:ipAddress}" -o table

Name Rg Ip

------------------- --------------- --------------

vm-web01-pip-old rg-web-prod 20.51.12.44

lb-legacy-frontend rg-net-prod 20.51.9.130

partner-allowlist rg-net-prod 20.51.9.131

# Three addresses front nothing. The first two are drift; partner-allowlist may be held on purpose.

An address with a null ipConfiguration and no NAT gateway is billing for nothing. Confirm each is not a reserved address held for an allow-list before releasing it.

How Azure decides a public IP is orphaneddeep dive

An orphaned address resolves to two properties on the public IP resource. The first is 'ipConfiguration': when it is null, the address is bound to no network interface, load balancer frontend or other configuration, so nothing references it. The second is 'natGateway': an address can be attached to a NAT gateway instead of a NIC, which does not show up as an ipConfiguration, so a sweep that checks only ipConfiguration would wrongly flag a working NAT address. The reliable test for a true orphan is that both are empty, which is exactly the check the Cost Optimization workbook's Networking tab applies in its 'Unattached Public IPs' query.

Billing follows the SKU, not the attachment. A standard-SKU static public IP is charged whether or not it is associated with a resource, which is why a detached address keeps costing. The classic exception is the Basic dynamic IP, which was only charged while attached and was released automatically when its VM deallocated, but Basic retired on 30 September 2025, so on a modern estate almost every address is standard and bills regardless. The second shape of waste, an address attached to a stopped-deallocated VM or an empty load balancer, will not show as null ipConfiguration at all, so it needs a separate check against the state of the resource behind it.

Azure Advisor evaluates the unassociated addresses on a periodic cycle and surfaces them as a cost recommendation, so deleting an address clears the recommendation on the next assessment rather than instantly. The strongest position pairs the regular sweep with an Azure Policy that audits for unused public IPs by display name, so a new orphan is flagged the moment it appears rather than waiting for the next manual pass. That is the difference between cleaning up the orphans you have today and stopping the estate accruing new ones tomorrow.

What is the impact of leaving orphaned IPs running?

The direct impact is a recurring charge for nothing. A standard-SKU static public IP bills at a fixed rate per address every hour it exists, attached or not, so each orphan is a small standing cost that never produces a request, serves a connection or fronts a workload. One address is negligible; the impact is that estates accumulate them silently, one per rebuilt VM and decommissioned load balancer, until a sweep finds dozens carrying a monthly total that surprises everyone.

The second-order impact is forecasting drift. Because the charge is fixed and quietly recurring rather than spiky and usage-driven, it does not trip the alerts that catch a runaway workload. It just sits in the baseline, nudging the bill up a little more each quarter, which is precisely the kind of slow creep that makes a budget hard to reason about. Releasing the orphans cleans the baseline so the spend that remains actually maps to something running.

There is also an operational tidiness impact. Addresses count against subscription quotas, so a drawer full of orphans can push you toward a public IP limit and block a legitimate deployment until something is released. Sweeping them keeps the address space honest, the quota free for real work, and the bill an accurate picture of what the estate is actually doing.

How do you release orphaned IPs safely?

Work this as one repeatable sweep rather than a one-off cleanup. The order matters: confirm an address is genuinely idle and not a deliberate reservation before you delete it, because a released static address is gone and a new one will not come back with the same value.

1. Inventory both shapes of orphan

List standard-SKU addresses with a null ipConfiguration and no NAT gateway, the clean orphans. Then separately check for addresses attached to a stopped-deallocated VM or an empty load balancer, the idle-but-attached shape. Use the Cost Optimization workbook's Networking tab and Azure Advisor's cost recommendation as cross-checks against your own query, since one address can be missed by a check that looks at ipConfiguration alone.

2. Separate deliberate reservations from drift

A few addresses are held on purpose: a reserved IP a partner has put on an allow-list, an address kept warm for a planned cutover. For each orphan, confirm whether anything external depends on that specific value. Anything with a documented reason to exist is ring-fenced and tagged; everything else is drift and can be released.

3. Release the drift, recording what you remove

Delete each confirmed orphan with a single command and log the name and address so the saving is auditable and a mistaken deletion is recoverable as a known event. Releasing a static address frees its value back to the pool, so do this only once you are sure no allow-list still references it. The deletion takes effect immediately; the Advisor recommendation clears on the next assessment cycle.

4. Stop the drift returning with policy and IaC

Assign an Azure Policy that audits for unused public IPs so a new orphan is flagged as soon as it appears, and define addresses you do keep in Bicep with explicit tags and ownership, so a reserved address is a deliberate, documented resource rather than an accident waiting to be re-orphaned. This turns a one-off sweep into a self-maintaining baseline.

# Release every standard-SKU public IP that is attached to nothing.
# Both ipConfiguration AND natGateway must be empty for a true orphan.
for id in $(az network public-ip list \
    --query "[?ipConfiguration==null && natGateway==null && sku.name=='Standard'].id" -o tsv); do
  name=$(az network public-ip show --ids "$id" --query name -o tsv)
  echo "Releasing orphan: $name"
  az network public-ip delete --ids "$id"
done

# Back it with policy: audit any unused public IP by EXACT display name.
# Look the definition up at runtime so no GUID is hard-coded.
pid=$(az policy definition list \
  --query "[?displayName=='Unused Public IP addresses driving cost should be avoided'].name" -o tsv)
az policy assignment create \
  --name audit-unused-pip \
  --policy "$pid" \
  --scope "/subscriptions/<subscription-id>"

# Addresses you keep on purpose belong in IaC. Bicep for a reserved, tagged standard IP:
#
# resource partnerAllowlistPip 'Microsoft.Network/publicIPAddresses@2024-05-01' = {
#   name: 'partner-allowlist'
#   location: location
#   sku: {
#     name: 'Standard'
#     tier: 'Regional'
#   }
#   properties: {
#     publicIPAllocationMethod: 'Static'
#     publicIPAddressVersion: 'IPv4'
#   }
#   tags: {
#     purpose: 'partner-allowlist'
#     owner: 'platform-team'
#   }
# }

Quick quiz

Question 1 of 5

Why does a standard-SKU static public IP attached to nothing still appear on the Azure bill?

Keep learning

Go deeper on how Azure prices public IPs, how to find the orphaned ones, and how to keep the estate from accruing new drift.

You can now treat orphaned public IPs as one repeatable sweep rather than a scatter of small charges: inventory both shapes of orphan, the truly unattached and the idle-but-attached, separate the deliberate reservations, release the drift, and back it with an audit policy and infrastructure as code so the estate stops accruing new orphans. A static address bills whether or not anything uses it, so releasing the ones that front nothing is a clean, recurring saving with no trade-off attached.

Back to the library

Orphaned public IPs: the savings view

A pure subtraction from the bill with no service to migrate and no trade-off to weigh

This is one of the cleanest savings lines in Azure. Every orphaned standard-SKU public IP is a fixed monthly charge for an address that fronts nothing, so releasing it removes a recurring cost outright with no replacement spend and no workload to re-architect. Unlike rightsizing a VM or moving a store behind a front door, there is no migration, no performance trade-off and no risk to a live service: the address was already doing nothing. The saving is the full price of the address, recurring, from the day you delete it.

Treat the orphan list as a recurring-cost subtraction, not a one-off cleanup. Each address has a known unit price, so the savings are trivially forecastable: multiply the address count by the standard-SKU static IPv4 rate for your region and you have the monthly figure the release returns to the budget. Because the charge is fixed per address rather than usage-based, the saving compounds every month the address would otherwise have lived on, which is what makes a fleet of small orphans add up.

The payback is immediate and the downside is close to zero. The only cost of the change is the few minutes it takes to confirm an address is genuinely idle, and the only risk is releasing one that was being held deliberately for an allow-list, which a short review removes. This is the rare optimisation where the ROI question answers itself: a recurring charge for nothing, removed, in exchange for a moment of engineering attention.

This lesson is for the finance partner who wants a forecastable, no-trade-off line on the savings plan. It covers why these addresses cost money for nothing, how to turn the orphan count into a monthly saving you can quote, why the payback is immediate, and how to ring-fence the few addresses held on purpose so the saving is clean.

Fun fact

The address that outlived its server

How a finance partner turns the orphan list into a number

Priya is the finance partner on the cost pass. The platform team hands her a list of fourteen orphaned standard-SKU public IPs across three subscriptions. The instinct is not to ask 'is it safe to delete these?', because by definition they front nothing; it is to turn the count into a recurring saving she can put on the plan. She multiplies the fourteen addresses by the standard-SKU static IPv4 rate for the region and has the monthly figure in a minute, because the charge is a fixed unit price per address rather than anything usage-based.

She frames it on the savings plan as a clean subtraction with immediate payback: fourteen recurring charges removed from the day of deletion, no replacement spend, no migration, no service to protect. The only caveat she records is the one address the team flagged as a partner allow-list reservation, which she rings off as a documented, deliberate hold rather than waste. The finance note reads: 'Thirteen addresses release as pure savings, recurring from day one; one is a documented reservation we keep on purpose. No trade-off, no migration, payback is immediate.'

Why orphaned IPs are the cleanest line on the savings plan

The economics here are unusually simple, which is what makes this a model savings line. The charge is a fixed unit price per standard-SKU static address, so the saving from releasing an orphan is exactly that price, recurring, with no replacement spend and no migration to fund. There is no trade-off to weigh, because the address was producing nothing: you are not trading performance for cost, you are deleting a charge that bought you nothing in the first place.

Because the unit price is known and the count is a single query, the saving is fully forecastable: address count times the regional standard-SKU static IPv4 rate gives the monthly figure, and it compounds every month the orphan would have lived on. The finance role is to quote that recurring number on the plan, log the immediate payback (the only cost is a few minutes of confirmation), and ring-fence the small number of addresses held deliberately for allow-lists so the headline saving is clean and the one documented exception is not mistaken for waste.

What finance can do about orphaned IPs

Finance cannot delete an address, but it owns the framing that turns a list of orphans into a forecastable, recurring saving and keeps the one or two deliberate reservations from being mistaken for waste. Three levers.

1. Turn the orphan count into a quoted monthly saving

Make the saving concrete and forecastable: address count times the regional standard-SKU static IPv4 rate equals the recurring monthly figure released. Because the charge is a fixed unit price per address rather than usage-based, this number is reliable and compounds every month the orphan would otherwise have lived on. Put it on the savings plan as a recurring subtraction with immediate payback, not a vague cleanup.

2. Record the payback as immediate and the trade-off as none

Unlike rightsizing or reservations, there is no replacement spend, no migration and no service to protect, because the address fronts nothing. The only cost is the few minutes of confirmation per address. State this explicitly so the capability is approved as the no-risk saving it is, rather than queued behind work that carries a genuine trade-off.

3. Ring-fence the deliberate reservations

A small number of addresses are held on purpose, a partner allow-list reservation, an address kept for a cutover. Require each to be tagged and recorded with a reason so it is visibly a deliberate hold, not unswept waste. The distinction between 'released as pure saving' and 'kept on purpose and documented' is what makes the savings figure defensible and stops the next sweep from accidentally deleting something an external party depends on.

Quick quiz

Question 1 of 5

A platform team hands finance fourteen orphaned standard-SKU public IPs. What is the quickest reliable way to put a saving on the plan?

Keep learning

Go deeper on how Azure prices public IPs, how to find the orphaned ones, and how to keep the estate from accruing new drift.

You have finished the finance view of releasing orphaned IPs. You know the saving is forecastable and recurring: address count times the regional standard-SKU static IPv4 rate, removed from the day of deletion, with immediate payback and no migration or replacement spend. Next time an orphan list lands, you will quote the recurring monthly figure, log the payback as immediate, and ring-fence the documented reservations so the headline saving is clean.

Back to the library

Orphaned public IPs: the headline

Whether the estate is paying a standing charge for addresses that front nothing

Orphaned public IPs are the textbook example of cloud spend that delivers no value: a fixed monthly charge for an address attached to nothing, multiplied across an estate that has been rebuilding resources for years. Individually each is small. Across hundreds of resource groups and several years of drift, the standing charge is real, recurring, and entirely avoidable.

The leadership question is not 'how much does one address cost?' It is 'does our process leave a paid-for address behind every time we decommission something?' If the answer is yes, the estate is accruing a slow, invisible tax. The defensible end state is that orphaned addresses are swept regularly, the few held on purpose are documented, and a policy flags any new orphan so the drift cannot quietly rebuild.

This is a savings decision with no trade-off attached. Releasing these addresses takes nothing away from any running service, because by definition they front nothing. It is the kind of clean, risk-free reduction that demonstrates the cost discipline boards increasingly expect to see evidenced rather than asserted.

A short read for the leader who wants to know whether the estate is paying a standing charge for nothing, why releasing it is a risk-free saving rather than a trade-off, and what a defensible, self-maintaining end state looks like so the waste does not quietly rebuild.

Fun fact

The address that outlived its server

What it looks like when the estate stops leaking standing charges

After a cost review flagged that the Azure bill had crept up faster than usage, the CFO asked the platform team the uncomfortable question: how much are we paying for things we are not using? Orphaned public IPs were the easiest part of the answer to demonstrate, because there is no ambiguity about whether an address attached to nothing is delivering value.

The team swept every subscription for addresses with no ipConfiguration and no NAT gateway, released the drift, documented the one address held for a partner allow-list, and then set a policy that flags any new orphan as soon as it appears. The next review had a different tone: instead of a vague 'we think there's some waste', the answer was a specific count of addresses released, a recurring monthly figure returned to the budget, and a backstop so the leak could not silently reopen. That shift, from suspecting waste to evidencing a recurring saving with a control that keeps it from returning, is the signal this capability sends, and it costs nothing but a sweep to reach.

Why this is the easiest saving to approve

Most cost decisions involve a trade-off: a cheaper tier with less headroom, a reserved commitment that bets on future usage, a re-architecture that costs engineering time now to save later. Releasing orphaned public IPs has none of that. It removes a recurring charge for addresses that, by definition, front nothing, so there is no service to protect, no performance to give up and no commitment to make.

The saving is modest per address but recurring and entirely free of downside, and it evidences exactly the kind of cost discipline that reassures a board: a process that does not leave paid-for resources behind when it decommissions things. This is the trade leadership should approve fastest, because the only thing standing between the estate and the saving is the decision to sweep regularly and back it with a policy so the waste cannot quietly return.

The leadership move on orphaned IPs

The executive handle is not to approve each deletion; it is to require that the estate sweeps orphaned addresses regularly, documents the few held on purpose, and backs it with a policy so the waste cannot quietly rebuild.

1. Ask for the saving as a recurring number, not a one-off

Request the count of orphaned addresses released and the recurring monthly figure that returns to the budget, framed as a standing charge removed rather than a single cleanup. Because the cost was recurring, the saving is too, and it should be tracked that way so the discipline is visible quarter on quarter.

2. Require a backstop so the drift cannot return

A one-off sweep is undone the next time a VM is rebuilt and its IP is left behind. Ask for an Azure Policy that flags new orphans as they appear and for reserved addresses to live in infrastructure as code with owners and tags. The goal is a baseline that stays clean on its own, not a cleanup that has to be repeated by hand.

3. Treat deliberate reservations as named, owned exceptions

A handful of addresses are kept on purpose, and that is fine. The leadership requirement is that each is a documented, owned decision with a recorded reason, not an orphan that happened to survive the sweep. The goal is not zero reserved addresses; it is zero accidental ones.

Quick quiz

Question 1 of 5

At a cost review you ask whether the estate is paying for things it does not use. Why are orphaned public IPs the easiest part of that answer to demonstrate?

Keep learning

Go deeper on how Azure prices public IPs, how to find the orphaned ones, and how to keep the estate from accruing new drift.

Two takeaways. Releasing orphaned public IPs is the rare saving with no trade-off, because the addresses front nothing, so it is the cost decision you should approve fastest. And the defensible end state is not 'we cleaned them up once'; it is a regular sweep, the few deliberate reservations documented and owned, and an audit policy that flags new orphans as they appear, so the recurring saving stays banked and the drift cannot quietly rebuild.

Back to the library

Part of the learning path Kill idle Azure waste

Release orphaned public IP addresses

Orphaned public IPs: the basics

The address that outlived its server

Finding orphaned public IPs across a subscription

How Azure decides a public IP is orphaneddeep dive

What is the impact of leaving orphaned IPs running?

How do you release orphaned IPs safely?

1. Inventory both shapes of orphan

2. Separate deliberate reservations from drift

3. Release the drift, recording what you remove

4. Stop the drift returning with policy and IaC

Quick quiz

Keep learning

Orphaned public IPs: the savings view

The address that outlived its server

How a finance partner turns the orphan list into a number

Why orphaned IPs are the cleanest line on the savings plan

What finance can do about orphaned IPs

1. Turn the orphan count into a quoted monthly saving

2. Record the payback as immediate and the trade-off as none

3. Ring-fence the deliberate reservations

Quick quiz

Keep learning

Orphaned public IPs: the headline

The address that outlived its server

What it looks like when the estate stops leaking standing charges

Why this is the easiest saving to approve

The leadership move on orphaned IPs

1. Ask for the saving as a recurring number, not a one-off

2. Require a backstop so the drift cannot return

3. Treat deliberate reservations as named, owned exceptions

Quick quiz

Keep learning

Related cost lessons