How to reserve a private IP from a virtual networks subnet

Question

I would like to reserve a single IP from a subnet, and only use it explicitly when needed

My kubernetes cluster can get torn down on different occasions, and we have a Kubernetes Service resource of type LoadBalancer

I want to be the one to set the IP for my LoadBalancer for this service, and also ensure the IP stays the same if the Kubernetes cluster gets recreated, or the service itself gets recreated

Is there a way of reserving a single IP from a subnet, which can only later be used explicitly by my resource only when I want

Answer 1

For an Azure VNet private IP, there isn’t a native concept of “reserving” a single IP in a subnet as a standalone resource the way Public IPs work. Azure only guarantees a private IP is held if it is attached to something like a NIC or a Load Balancer frontend configuration. If nothing owns it, it’s just part of the free pool and can be taken by anything.

So if you want a private IP that survives Kubernetes cluster or Service teardown, you have to anchor that IP to an Azure resource that persists independently of the cluster. The usual pattern is to pre-create an Azure Standard Load Balancer with a frontend IP configuration set to a specific static private IP from your subnet.

Example of creating that frontend IP on a load balancer:

az network lb create \
  --resource-group <rg> \
  --name <lb-name> \
  --sku Standard \
  --vnet-name <vnet> \
  --subnet <subnet> \
  --frontend-ip-name <frontend-name> \
  --private-ip-address 10.0.0.50

That effectively “reserves” 10.0.0.50 because it is now owned by the load balancer frontend config. This resource can live independently of AKS and will not be deleted when the cluster is torn down.

Then, instead of letting Kubernetes create its own load balancer, you make your Service attach to this existing one using annotations:

apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-resource-group: <rg>
    service.beta.kubernetes.io/azure-load-balancer-name: <lb-name>
spec:
  type: LoadBalancer
  loadBalancerIP: 10.0.0.50
  ports:
    - port: 80
  selector:
    app: my-app

Now the important behavior is that the IP is not being “reserved by Kubernetes”. It is reserved because the Azure Load Balancer frontend owns it, and Kubernetes is simply reusing that frontend. As long as you do not delete that load balancer resource, the IP will persist across cluster and Service recreation.

If you instead only do:

spec:
  loadBalancerIP: 10.0.0.50

without pre-creating and owning that IP via an Azure resource, there is no guarantee. It will work only if the IP is free at that moment, and it can be lost or reassigned when the Service or cluster is deleted.

So the correct mental model in Azure VNet is that private IP persistence requires binding the IP to a durable Azure resource such as a Load Balancer frontend. Kubernetes alone cannot reserve or hold a private IP across its own lifecycle.

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Answer 2

HI @Justin Obanor,

Welcome to Microsoft Q&A Platform.

It makes sense that you want to “park” a single private IP in your VNet and then hand it to your AKS LoadBalancer only when you need it—so that even if you tear down and rebuild your cluster (and its MC_* resource group), your IP never gets sucked back into the pool.

Pre-create an internal Load Balancer (Standard SKU) in your own resource group and reserve your desired IP as its frontend IP az CLI example:

az network lb create \
  --resource-group MyLBResourceGroup \
  --name myStaticILB \
  --sku Standard \
  --vnet-name MyVnet \
  --subnet MySubnet \
  --private-ip-address 10.0.0.50 \
  --frontend-ip-name myFrontend

This command spins up an internal LB called myStaticILB with frontend IP 10.0.0.50. That IP is now tied to this LB resource and won’t be returned to the subnet’s dynamic pool until you delete the LB or change its IP config.

Tell your Kubernetes Service to use that existing LB (and its IP) instead of letting AKS create one in MC_* In your Service manifest:

apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    # make it internal
    service.beta.kubernetes.io/azure-load-balancer-internal: 
    # point to your own RG (so the LB isn’t created in the MC_* RG)
    service.beta.kubernetes.io/azure-load-balancer-resource-group: MyLBResourceGroup
spec:
  type: LoadBalancer
  # must match the IP you reserved above
  loadBalancerIP: 10.0.0.50
  ports:
    - port: 80
      targetPort: 80

When you apply this, Kubernetes won’t try to carve a new IP from the subnet. It re-uses the LB + IP you manage in MyLBResourceGroup. If your AKS cluster gets deleted and re-created, you simply re-deploy this Service and it re-attaches to your existing LB+IP.

(Optional) If you need finer-grained IP-reservations in the future, look at Azure Virtual Network Manager’s IPAM feature

• You can define an IP address pool and carve out static CIDR blocks (today minimum /28) so that no other resource can consume those addresses.
• When you need that IP, you allocate it from the pool via ARM/CLI and attach it to your resource.

Ref:

How Azure assigns private IPs (static vs dynamic)

Assign private IP prefixes as secondary IP configs on a NIC (preview)

Azure Virtual Network Manager IPAM (static CIDR reservations)

Pleaseand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.