diff --git a/website/content/en/docs/concepts/scheduling.md b/website/content/en/docs/concepts/scheduling.md
index 90339674f24c..3dc49adda4e6 100755
--- a/website/content/en/docs/concepts/scheduling.md
+++ b/website/content/en/docs/concepts/scheduling.md
@@ -352,6 +352,10 @@ The three supported `topologyKey` values that Karpenter supports are:
 
 See [Pod Topology Spread Constraints](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) for details.
 
+{{% alert title="Note" color="primary" %}}
+NodePools do not attempt to balance or rebalance the availability zones for their nodes. Availability zone balancing may be achieved by defining zonal Topology Spread Constraints for Pods that require multi-zone durability, and NodePools will respect these constraints while optimizing for compute costs.
+{{% /alert %}}
+
 ## Pod affinity/anti-affinity
 
 By using the `podAffinity` and `podAntiAffinity` configuration on a pod spec, you can inform the Karpenter scheduler of your desire for pods to schedule together or apart with respect to different topology domains. For example:
diff --git a/website/content/en/preview/concepts/scheduling.md b/website/content/en/preview/concepts/scheduling.md
index 90339674f24c..08947b395b93 100755
--- a/website/content/en/preview/concepts/scheduling.md
+++ b/website/content/en/preview/concepts/scheduling.md
@@ -349,9 +349,12 @@ The three supported `topologyKey` values that Karpenter supports are:
 - `kubernetes.io/hostname`
 - `karpenter.sh/capacity-type`
 
-
 See [Pod Topology Spread Constraints](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) for details.
 
+{{% alert title="Note" color="primary" %}}
+NodePools do not attempt to balance or rebalance the availability zones for their nodes. Availability zone balancing may be achieved by defining zonal Topology Spread Constraints for Pods that require multi-zone durability, and NodePools will respect these constraints while optimizing for compute costs.
+{{% /alert %}}
+
 ## Pod affinity/anti-affinity
 
 By using the `podAffinity` and `podAntiAffinity` configuration on a pod spec, you can inform the Karpenter scheduler of your desire for pods to schedule together or apart with respect to different topology domains. For example:
diff --git a/website/content/en/v0.30/concepts/scheduling.md b/website/content/en/v0.30/concepts/scheduling.md
index 0f70f1a0463f..b81d8fcade3f 100755
--- a/website/content/en/v0.30/concepts/scheduling.md
+++ b/website/content/en/v0.30/concepts/scheduling.md
@@ -354,6 +354,10 @@ The three supported `topologyKey` values that Karpenter supports are:
 
 See [Pod Topology Spread Constraints](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) for details.
 
+{{% alert title="Note" color="primary" %}}
+NodePools do not attempt to balance or rebalance the availability zones for their nodes. Availability zone balancing may be achieved by defining zonal Topology Spread Constraints for Pods that require multi-zone durability, and NodePools will respect these constraints while optimizing for compute costs.
+{{% /alert %}}
+
 ## Pod affinity/anti-affinity
 
 By using the `podAffinity` and `podAntiAffinity` configuration on a pod spec, you can inform the provisioner of your desire for pods to schedule together or apart with respect to different topology domains. For example:
diff --git a/website/content/en/v0.31/concepts/scheduling.md b/website/content/en/v0.31/concepts/scheduling.md
index 0f70f1a0463f..b81d8fcade3f 100755
--- a/website/content/en/v0.31/concepts/scheduling.md
+++ b/website/content/en/v0.31/concepts/scheduling.md
@@ -354,6 +354,10 @@ The three supported `topologyKey` values that Karpenter supports are:
 
 See [Pod Topology Spread Constraints](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) for details.
 
+{{% alert title="Note" color="primary" %}}
+NodePools do not attempt to balance or rebalance the availability zones for their nodes. Availability zone balancing may be achieved by defining zonal Topology Spread Constraints for Pods that require multi-zone durability, and NodePools will respect these constraints while optimizing for compute costs.
+{{% /alert %}}
+
 ## Pod affinity/anti-affinity
 
 By using the `podAffinity` and `podAntiAffinity` configuration on a pod spec, you can inform the provisioner of your desire for pods to schedule together or apart with respect to different topology domains. For example:
diff --git a/website/content/en/v0.32/concepts/scheduling.md b/website/content/en/v0.32/concepts/scheduling.md
index cecc70c0c4a0..1f9b6bce49a0 100755
--- a/website/content/en/v0.32/concepts/scheduling.md
+++ b/website/content/en/v0.32/concepts/scheduling.md
@@ -351,6 +351,10 @@ The three supported `topologyKey` values that Karpenter supports are:
 
 See [Pod Topology Spread Constraints](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) for details.
 
+{{% alert title="Note" color="primary" %}}
+NodePools do not attempt to balance or rebalance the availability zones for their nodes. Availability zone balancing may be achieved by defining zonal Topology Spread Constraints for Pods that require multi-zone durability, and NodePools will respect these constraints while optimizing for compute costs.
+{{% /alert %}}
+
 ## Pod affinity/anti-affinity
 
 By using the `podAffinity` and `podAntiAffinity` configuration on a pod spec, you can inform the Karpenter scheduler of your desire for pods to schedule together or apart with respect to different topology domains. For example:
diff --git a/website/content/en/v0.33/concepts/scheduling.md b/website/content/en/v0.33/concepts/scheduling.md
index 90339674f24c..3dc49adda4e6 100755
--- a/website/content/en/v0.33/concepts/scheduling.md
+++ b/website/content/en/v0.33/concepts/scheduling.md
@@ -352,6 +352,10 @@ The three supported `topologyKey` values that Karpenter supports are:
 
 See [Pod Topology Spread Constraints](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) for details.
 
+{{% alert title="Note" color="primary" %}}
+NodePools do not attempt to balance or rebalance the availability zones for their nodes. Availability zone balancing may be achieved by defining zonal Topology Spread Constraints for Pods that require multi-zone durability, and NodePools will respect these constraints while optimizing for compute costs.
+{{% /alert %}}
+
 ## Pod affinity/anti-affinity
 
 By using the `podAffinity` and `podAntiAffinity` configuration on a pod spec, you can inform the Karpenter scheduler of your desire for pods to schedule together or apart with respect to different topology domains. For example: