Cloud Computing: Your Azure AKS Load Balancer Just Stopped Working

If your Kubernetes service suddenly won’t assign a public IP. You’ve probably hit a limit you didn’t know existed — and it’s about to cost you hours of head-scratching.

The Problem: Your Load Balancer Services Are Stuck in “Pending”

So you deploy your AKS cluster. You expose your apps with type: Load Balancer. Everything works, Then one day, You deploy a new service, and — nothing. It’s stuck in pending. Logs are clean. Helm is green. The Azure portal looks fine. And that’s when you find it:

Azure ran out of frontend IPs for your load balancer, and it never told you that’s even a thing.

The Real Limit: It’s Not Kubernetes. It’s Azure’s infrastructure.

Most AKS users think Kubernetes will scale their services infinitely. But what they don’t realize is that every type of Load Balancer service creates a new Azure Load Balancer frontend configuration.

And guess what?

Standard Azure Load Balancers have a hard default limit of 100 frontend IPs.

Some SKUs have even lower practical limits depending on region, tier, or your vNet subnet space. If your app uses lots of microservices with public endpoints, or you do blue/green or canary deployments with duplicate services, you’ll hit the wall fast.

But wait, It gets worse, here’s what makes this problem extra nasty:

Deleted Services Don’t Always Free Up IPs Immediately

IP resources can get stuck or take time to reallocate, even after the service is gone.

You May Be Sharing a Load Balancer Across Namespaces or Teams

If you’re in a large organization with multi-tenant clusters, other teams may be eating IPs without you knowing.

Azure Won’t Warn You

There’s no alert, error, or dashboard — you’ll only know when a deployment fails when you dig through YAML and portal logs.

How to Check If You’ve Hit the Limit

Use the Azure CLI to see your IP usage:

az network lb frontend-ip list \
  --resource-group <your-rg> \
  --lb-name <your-lb-name>

Or check your subnet IP allocation:

az network vnet subnet show \
  --resource-group <your-rg> \
  --vnet-name <your-vnet> \
  --name <your-subnet>

If you run out of space in your subnet, AKS can’t assign new load balancer IPs, even if you appear to have some.

How to Fix It

1. Clean Up Orphaned Load Balancer Services

Old test services or inactive deployments might still be eating up IPs. Kill them. Run audits.

kubectl get svc - all-namespaces -o wide | grep LoadBalancer

2. Use Internal Load Balancers When Possible

Not everything needs a public IP. Add this to your service YAML:

Annotations:

service.beta.kubernetes.io/azure-load-balancer-internal: "true"

3. Use an Ingress Controller (and Only One Public IP)

Instead of exposing 15 services, expose 1 NGINX/AGIC ingress and route everything internally.

4. Monitor and Alert on IP Usage

Azure Monitor + a custom metric can alert you when you’re approaching IP exhaustion. Don’t let prod be your alert system.

5. Know Your Limits — Literally

Check your region and SKU limits here: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits

It’s Not a Bug. It’s a budgeted limit.

You didn’t do anything wrong. You just ran into an Azure limit that nobody warns you about until it’s too late. Your services aren’t broken. Your Helm charts aren’t cursed. You just need to manage your load balancer footprint like a real cloud architect.