AKS Private Cluster: Create a Private Azure Kubernetes Service (AKS) Cluster – Part 1
You may also be interested in my other AKS-related blogs
- Azure AKS Networking Explained: Critical Differences Between Azure CNI Overlay vs Node Subnet vs Pod Subnet – Part 1
- Azure AKS FailedScheduling – Kubernetes scheduler failure Insufficient CPU
- Kubectl Cheat Sheet – 41 Unique Kubernetes Commands Every Admin Should Know – Part 1
About AKS Private Cluster
A private AKS cluster is a configuration where the control plane (API server) is assigned an internal IP address rather than a public one. The connection relies on the Azure Private Link service and a private endpoint located in your AKS cluster’s subnet
Create AKS Private Cluster Azure Managed DNS – Azure Portal

Create AKS Private Cluster Azure Managed DNS – Azure CLI
A few important points to note:
- If you need to enable Azure Container Registry on a private AKS cluster, set up a private link for the container registry in the cluster virtual network (VNet) or set up peering between the container registry’s virtual network and the private cluster’s virtual network.
- You can’t apply IP authorised ranges to the private API server endpoint – they only apply to the public API server. Refer to this link for more limitations here
#Connect-AzAccount
az account clear
az login --tenant <tenantid>
# Get a list of available subscriptions.
az account list --output table
# If the subscription you are seeking is now in the list,
# change your subscription.
az account set --subscription "Visual Studio Enterprise Subscription"
# See what subscription you are currently using.
az account show
# Get the cluster Node Subnet ID
az network vnet subnet list `
--resource-group rg-vnet-poc-ci `
--vnet-name vnet-poc-ci `
--query "[2].id" --output tsv
# Now create the AKS private cluster and enable the cluster autoscaler
#system will be the default value when configuring a private DNS zone, If we omit --private-dns-zone, AKS will create a private DNS zone in the node resource group i.e. MC_rg..
#If we set --private-dns-zone to none, AKS doesn't create a private DNS zone.
#For custom DNS please refer this link https://learn.microsoft.com/en-us/azure/aks/private-clusters
az aks create `
--resource-group mak-aks-poc `
--name mak-aks-ci01 `
--vnet-subnet-id "/subscriptions/subid/resourceGroups/rg-vnet-poc-ci/providers/Microsoft.Network/virtualNetworks/vnet-poc-ci/subnets/snet-aks-ci" `
--node-vm-size "Standard_D2ls_v5"`
--tier standard `
--dns-name-prefix "aks-dns-poc" `
--tags "Owner=mak" , "Stack=qa", "Billing=qa" `
--node-osdisk-size "256" `
--network-plugin-mode overlay `
--pod-cidr 172.244.0.0/16 `
--dns-service-ip 172.26.42.12 `
--service-cidr 172.26.42.0/24 `
--enable-azure-rbac `
--generate-ssh-keys `
--location "CentralIndia" `
--node-os-upgrade-channel NodeImage `
--zones 1 2 3 `
--enable-aad `
--node-count 1 `
--enable-private-cluster `
--vm-set-type VirtualMachineScaleSets `
--load-balancer-sku standard `
--enable-cluster-autoscaler `
--min-count 1 `
--os-sku Ubuntu `
--enable-azure-monitor-metrics `
--max-count 2 `
--enable-workload-identity `
--nodepool-name "systempool" `
--enable-oidc-issuer `
--network-plugin azure
#Add Usernodepool
az aks nodepool add --resource-group MyResourceGroup --cluster-name MyManagedCluster --name usernp1 --node-vm-size Standard_D2ls_v5 --os-type Linux --os-sku Ubuntu --node-count 2 --enable-cluster-autoscalerPost Checks – AKS Private Cluster Azure Managed DNS
- System will be the default value when configuring a private DNS zone. If you omit –private-dns-zone, AKS creates a private DNS zone in the node resource group i.e MC_RSG_ClusterName..

- The cluster uses an A record in the private zone to resolve the IP of the private endpoint for communication to the API server.

- If you go to AKS VNET and select the “Private Enpoints” you see the private endpoint private IP address the API host A records was pointing


Connect AKS Private Cluster Azure Managed DNS – Cloud Shell
Configure Cloud Shell to connect to Private AKS cluster using Azure POrtal (preview)
- This option creates a separate VNet with the necessary resources for Cloud Shell and configures VNet peering for you with AKS deployed Vnet.
- Configuration takes at least 5 to 10 minutes, followed by a few additional minutes to connect to the cluster.

- Click “Configure,” and the remaining steps will proceed automatically.
- After successful configuration, the “Configure” button will be greyed out. Then, click “Cloud Shell” to open the Cloud Shell.



References
FAQ
Configure Custom DNS with Hub and Spoke Model where DNS is On-prem Hosted
When your DNS servers are hosted on-premises (or you are using “Custom DNS” configurations within an Azure VNet), specific configurations are required to ensure the AKS cluster—particularly a Private AKS cluster—can resolve addresses correctly and be reached by your network.
Here are the required configurations:
- The “Golden Rule”: Upstream Forwarding
If you configure your VNet to use a custom DNS server (such as an on-premises server connected via VPN/ExpressRoute), that server generally cannot resolve Azure-specific private domains (like the API server’s private endpoint) on its own.
- Configuration: You must configure your custom DNS server to use the Azure recursive resolver IP address 168.63.129.16 as an upstream forwarder.
- Priority: This Azure IP address should be configured as the first DNS server in the list.
- Function: This ensures that when the AKS nodes (or on-prem clients) try to resolve the private Kubernetes API address (e.g., privatelink.<region>.azmk8s.io), the request is forwarded to Azure’s internal DNS, which holds the correct records.
Custom DNS with Hub and Spoke Architecture Strategy
In a typical on-premises scenario, you likely use a Hub and Spoke network model. The “Hub” VNet contains a DNS forwarder (or connectivity to on-prem), and the “Spoke” VNet contains the AKS cluster.
When creating a Private AKS cluster in this setup, the default behavior often fails because the Private DNS Zone is automatically linked only to the Spoke VNet, not the Hub (where your DNS infrastructure lives).
To fix this, you should use the Custom Private DNS Zone (BYO) method:
- Pre-create the Zone: Create a private DNS zone (e.g., privatelink.<region>.azmk8s.io) in Azure.
- Link the Zone: Link this zone to your Hub VNet (so your on-prem/custom DNS can resolve it).
- Create Cluster: Use the –private-dns-zone parameter to tell AKS to use this specific existing zone rather than creating a new, isolated one.
- Note: The identity used by the cluster requires Private DNS Zone Contributor and Network Contributor permissions on that zone.
Critical Limitations
When configuring this hybrid DNS setup, be aware of the following constraints mentioned in the sources:
- Conditional Forwarding: If you are configuring your on-prem DNS to conditionally forward traffic for the cluster domain, note that conditional forwarding does not support subdomains.
- Route Tables (Kubenet): If you are using Kubenet networking with a Bring-Your-Own (BYO) Route Table and custom DNS, the cluster creation will fail. You must associate the route table with the subnet after the cluster creation attempt fails.
- Public FQDN: You cannot set the private DNS zone to none (public DNS only) and disable the public FQDN at the same time; this configuration is unsupported