Trim load balancer and public IP costs on Azure

Why this matters

Azure bills a public IP by the hour while it exists. A Standard static address with no network interface still shows up on the invoice. Azure Load Balancer Standard adds charges for load balancing rules and data processed. A lab with leftover addresses and two idle load balancers can cost more than the VMs it was built to test.

Public IPs and load balancers pile up during migrations. Teams create one for a jump host, one for an old app, and one per environment, then DNS points at only some of them. Each address is also a way in from the internet, so cleanup is a security task. For HTTP, a shared Application Gateway or Front Door can host many sites behind one public IP. For TCP, one Standard load balancer with a few rules often replaces several.

Before you start

Start with an inventory. In the Azure portal, open All resources, filter by type Public IP address, and export the list. Do the same for Load balancer. For a larger estate, query microsoft.network/publicipaddresses and microsoft.network/loadbalancers in Azure Resource Graph. Include subscription, resource group, SKU, allocation method, attached IP configuration, and tags.

For each public IP, write down what uses it: a VM network interface, a load balancer frontend, a VPN gateway, Azure Firewall, Bastion, or an Application Gateway. An address with no association is a candidate, but check DNS zones and partner allowlists first. The Activity log shows who created it and when.

Open Cost Management, scope it to the subscription, filter to Load Balancer and Virtual Network, and group by Meter. You should see separate meters for public IP addresses and load balancing rules. Run the view for three months. Then agree on a rule: public IPs only for inbound services that must be internet reachable. Internal tiers use an internal load balancer, private endpoint, or private DNS. Outbound uses NAT Gateway or a firewall.

How to do it

Start with changes that cannot break traffic. Delete public IPs with no association and no DNS record. Delete load balancers with no backend pool, no rules, or no frontend that anyone can name. Remove duplicate frontend configurations on load balancers that serve the same service. Give every deletion an owner and a line in the change record.

Next, collapse HTTP and HTTPS entry points. Put several host names on one Application Gateway or Front Door using host-based and path-based rules. Terminate TLS at the gateway and use SNI so one IP serves many certificates. For internal web apps, use an internal load balancer or private endpoint and keep the public address out of the design.

For TCP and UDP, review the rule list on each Standard load balancer. Remove rules for ports no backend listens on. Combine health probes where one backend pool serves several ports. If two load balancers share a backend pool and a purpose, merge them. Then move outbound traffic to NAT Gateway or firewall egress and remove public IPs from VM NICs. Update partner allowlists with the new egress address. Finish with an Azure Policy that denies public IP creation outside approved groups.

1. Export the inventory. Use All resources or Azure Resource Graph to list every public IP and load balancer with its subscription, resource group, SKU, and attachment. Include the IP configuration field so unattached addresses stand out. Save the export where the team can review it.
2. Tag every resource. Tag each public IP and load balancer with an application and an owner. If nobody claims it within a week, treat it as a deletion candidate. Tags also make the next review faster.
3. Delete unattached public IPs. Confirm there is no DNS record, firewall rule, or partner allowlist that uses the address. Delete the public IP in the portal or with Azure CLI. For a public IP prefix, remove child addresses before the prefix.
4. Merge HTTP entry points. Move several sites onto one Application Gateway or Front Door using host-based rules and SNI. Keep the old listener until DNS TTLs expire, then remove the extra public IP. Test each host name after the cutover.
5. Move internal apps to internal load balancers. Change the frontend from public to internal, or create an internal Standard load balancer and move the backend pool. Update private DNS records. Remove the public IP once clients use the private name.
6. Trim load balancer rules. Delete rules for ports with no listener and probes that duplicate another probe. Merge load balancers that serve the same backend pool. Check the rule count before and after.
7. Remove outbound public IPs. Move egress to NAT Gateway or Azure Firewall, then detach public IPs from VM NICs. Update external allowlists with the new egress address before you remove the old one. Watch SNAT port usage during the change.
8. Add guardrails. Create an Azure Policy that denies public IPs outside approved resource groups. Add a budget alert and a monthly review of the public IP and load balancer meters. Give the review a named owner.

How to check it worked

Use Cost Management with a daily view, filtered to Load Balancer and Virtual Network, grouped by Meter. Compare the next full month with the month before. You want fewer public IP hours and fewer load balancing rule hours, not just less data. If the line barely moves, look for subscriptions you did not include.

Check traffic. Application Gateway shows backend health and failed requests. Load Balancer shows health probe status and data path metrics. Resolve each public host name from outside the network and confirm the TLS certificate and SNI binding. Test internal names from a VM in the same virtual network.

If you changed outbound traffic, check the egress address from a VM with a request to a service that echoes the source IP. Compare it with the partner allowlist. Watch NAT Gateway metrics or firewall logs for SNAT port exhaustion. Run a Resource Graph query for public IPs with an empty ipConfiguration field and load balancers with zero rules. The count should be zero or close. Review Azure Policy compliance for the deny rule.

Mistakes to avoid

Deleting an address that DNS still points at is the classic error. The bill drops, then a customer hits a dead host. Lower the DNS TTL before the change, keep the old record until traffic moves, and check every zone in every subscription. The same applies to partner allowlists and webhook callbacks.

Consolidating too far creates a shared failure domain. One Application Gateway with many sites needs capacity planning, autoscale, and zone support. Keep production and development separate, and keep a rollback path for each host name. Some public IPs are required: VPN gateways, Azure Firewall, Bastion, and Application Gateway frontends. Do not delete those unless you remove the service.

Plan egress before you remove VM public IPs. NAT Gateway needs a subnet association and a route, and partners need the new address. If the inventory is messy, a fixed scope review can help. Cloudverg's Cloud cost audit at $4,500/month is one option: it reviews up to three cloud accounts, ranks idle resources and commitment fixes, and includes a readout. You can also run the steps here yourself with a spreadsheet and a change window.

Frequently asked questions