Node Pool Automatic Placement

# 🌐AKS Node Pool Automatic Zone Placement

Azure Kubernetes Service (AKS) is working on a new feature that dynamically selects the optimal availability zones (AZs) for your system and user VMSS/VMs node pools.

## 📋 Overview

The **Automatic Zone Placement** feature automatically selects the optimal availability zones for your node pools, providing the best opportunity for successful deployment while maintaining optimal zone distribution based on available capacity. 🎯

## ✨ Key benefits

- **Region-agnostic deployments** 🌍: Use consistent configurations across regions without worrying about zone availability differences
- **Improved resilience** 💪: Automatically achieve multi-zone redundancy for better application availability
- **Automatic zone expansion** 📈: Seamlessly leverage new availability zones when regions expand (e.g., from 3 to 4 zones)
- **Reduced deployment failures** 🛡️: Reduce creation and scaling allocation failures caused by capacity constraints in specific zone based on your workload tolerance of zonal balancing

## ⚙️ How it works

When you use `availabilityZones="auto"`, AKS leverages the VMSS Zone Placement Policy to automatically:

```
"agentPoolProfiles": [{
"availabilityZones": [“auto”],
}],
```

1. Attempt to evenly spread VMs across 3 availability zones ⚖️
2. Ensure no more than 50% of VMs are in any single zone if even distribution isn't possible (default policy) 🔒
3. Expand to additional zones (e.g., 4th zone) when available to meet scaling requests 🚀

### 🎛️ Customizing zone distribution policy

By default, the platform ensures that no more than 50% of VMs are placed in any single zone to maintain resilience.
**In the next phase**, AKS will support the **maxInstancePercentPerZone** parameter, allowing you to adjust this threshold based on your specific resilience requirements and capacity tolerance. This will give you greater control over the balance between availability and deployment success rates.

```
"agentPoolProfiles": [{
"availabilityZones": [“auto”],
"maxInstancePercentPerZone": 80
}],
```

## 📚 Common scenarios

### Scenario 1: VM SKU availability varies across zones and regions 🗺️

**Before (without Automatic Zone Placement):** ❌

You want to deploy a 10-node pool with VM SKU "Standard_D8s_v5" across multiple regions, but the SKU has different zone availability:
- **Region 1**: SKU available only in zones 1 and 2
- **Region 2**: SKU available only in zones 2 and 3

You need to manually track and configure zones per region:

```bash
# Region 1 deployment - must specify zones 1 and 2
az aks create -g rg-region1 --node-vm-size Standard_D8s_v5 --node-count 10 --zones 1 2

# Region 2 deployment - must specify zones 2 and 3
az aks create -g rg-region2 --node-vm-size Standard_D8s_v5 --node-count 10 --zones 2 3
```

**Problem:** You must research, understand, and maintain zone-specific configurations for each region based on SKU availability. This becomes complex when managing multiple regions and SKUs. 😓

**After (with Automatic Zone Placement):** ✅

```bash
# Works consistently across all regions with 10 nodes
az aks create -g rg-region1 --node-vm-size Standard_D8s_v5 --node-count 10 --zones auto
az aks create -g rg-region2 --node-vm-size Standard_D8s_v5 --node-count 10 --zones auto
```

**Result:** The platform automatically detects where the SKU is available in each region and deploys 10 nodes accordingly: 🎉
- **Region 1**: Automatically deploys 10 nodes across zones 1 and 2 (e.g., 5/5 distribution)
- **Region 2**: Automatically deploys 10 nodes across zones 2 and 3 (e.g., 5/5 distribution)

No need to track SKU availability per region. 🙌

### Scenario 2: Region expansion to new availability zones 🔄

In region A, Zone 2,3 has limited capacity, no SKU A node is available, while Zone 4 is available.

**Before (without Automatic Zone Placement):** ❌

Your existing SKU A 10-node pool is configured with:

```json
"availabilityZones": ["1", "2", "3"],
"count": 10
```
Nodes spreading as 4/3/3 across zone 1/2/3.

**Problem:** When scaling out to 20 nodes, new nodes remain constrained to zones 1, 2, and 3 and you will get zonal allocation failure error because we will not put all 10 nodes in zone 1 now. 🚫

**After (with Automatic Zone Placement):** ✅

```json
"availabilityZones": ["auto"],
"count": 10
```

**Result:** When zone 4 becomes available and existing zones face capacity constraints, the platform automatically expands to zone 4 for new scale-out operations. 🎯
- After zone 4 is available and scaling to 20 nodes: 7/3/3/7 across zones 1/2/3/4

### Scenario 3: Adjust Zonal Balancing Tolerance ⚖️

**Before (without Automatic Zone Placement):** ❌

You request a 10-node pool with fixed zones:

```json
"availabilityZones": ["1", "2", "3"],
"count": 10
```

**Problem:** If zone 2 has insufficient capacity: 🚨
- Complete deployment failure even though other zones have capacity
- Example: Zone 1 has capacity for 7 nodes, zone 2 for 0 nodes, zone 3 for 1 nodes → you might get a partial failure: 5/0/1 across zones 1/2/3

**After (with Automatic Zone Placement):** ✅

If you prioritize allocation success over strict zone distribution and can tolerate more than 50% of nodes in a single zone, the upcoming **maxInstancePercentPerZone** parameter will allow you to increase this threshold (e.g., to 85%, allowing up to Ceil(85*10)/100 = 9 nodes in a single zone).

```json
"availabilityZones": ["auto"],
"maxInstancePercentPerZone": 85
"count": 10
```

You will end up with 9/0/1 across zones 1/2/3. 🎉