Add CPU calculation formulas and capacity planning guidance

- Add formula table for calculating broker CPU requirements
- Add caution about other AIO components consuming ~200-300m CPU
- Add small cluster example showing why equal cores isn't enough
- Expand larger deployment example with step-by-step math
- Based on test results confirming pods get stuck Pending when
  cluster CPU is at or below broker reservation

Author: jlian

articles/iot-operations/manage-mqtt-broker/howto-configure-availability-scale.md

@@ -5,7 +5,7 @@ author: sethmanheim
 ms.author: sethm
 ms.topic: how-to
 ms.subservice: azure-mqtt-broker
-ms.date: 05/14/2025
+ms.date: 02/20/2026
 ms.service: azure-iot-operations
 
 # CustomerIntent: As an operator, I want to understand the settings for the MQTT broker so that I can configure it for high availability and scale.
@@ -258,12 +258,59 @@ To prevent resource starvation in the cluster, the broker can be configured to [
 >
 > If you enable CPU resource limits, make sure your cluster has enough CPU resources to satisfy the broker's requests based on your cardinality configuration. See the CPU requirements below.
 
-The MQTT broker currently requests one (1.0) CPU unit per frontend worker and two (2.0) CPU units per backend worker. For more information, see [Kubernetes CPU resource units](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu).
+### Calculate CPU requirements
 
-For example, the following cardinality would request the following CPU resources:
+The MQTT broker requests CPU resources per pod based on the number of workers configured:
 
-- **For frontends**: 2 CPU units per frontend pod, totaling 6 CPU units.
-- **For backends**: 4 CPU units per backend pod (for two backend workers), times 2 (redundancy factor), times 3 (number of partitions), totaling 24 CPU units.
+- **Frontend pods**: 1.0 CPU per worker
+- **Backend pods**: 2.0 CPU per worker
+
+Use the following formulas to calculate total CPU requirements:
+
+| Component | Formula |
+|-----------|---------|
+| Frontend CPU | `replicas` × `frontend.workers` × 1.0 CPU |
+| Backend CPU | `partitions` × `redundancyFactor` × `backend.workers` × 2.0 CPU |
+| **Total broker CPU** | Frontend CPU + Backend CPU |
+
+For more information, see [Kubernetes CPU resource units](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu).
+
+> [!CAUTION]
+> The broker isn't the only component that consumes CPU on the cluster. Other Azure IoT Operations components (such as the dataflow engine, OPC UA connector, and system pods) also reserve CPU resources, typically around 200-300m in aggregate. When planning cluster capacity, make sure to account for this overhead on top of the broker's CPU requirements. If the total CPU requested by all pods exceeds the available CPU on your cluster, broker pods get stuck in a `Pending` state.
+
+#### Example: small cluster
+
+Consider a 2-node cluster with 4 CPU cores per node (8 cores total) with the following cardinality:
+
+```json
+{
+  "cardinality": {
+    "frontend": {
+      "replicas": 2,
+      "workers": 2
+    },
+    "backendChain": {
+      "partitions": 1,
+      "redundancyFactor": 2,
+      "workers": 1
+    }
+  }
+}
+```
+
+The broker requests:
+
+- **Frontend CPU**: 2 replicas × 2 workers × 1.0 = **4.0 CPU**
+- **Backend CPU**: 1 partition × 2 RF × 1 worker × 2.0 = **4.0 CPU**
+- **Total broker CPU**: **8.0 CPU**
+
+Even though the cluster has 8 cores total, this deployment fails because other Azure IoT Operations components also consume CPU (~280m). The broker pods get stuck in `Pending` state with `Insufficient cpu` errors.
+
+To resolve this, either add more nodes, increase cores per node, or reduce the broker cardinality.
+
+#### Example: larger deployment
+
+The following cardinality requests significantly more CPU resources:
 
 ```json
 {
@@ -281,6 +328,10 @@ For example, the following cardinality would request the following CPU resources
 }
 ```
 
+- **Frontend CPU**: 3 replicas × 2 workers × 1.0 = **6.0 CPU**
+- **Backend CPU**: 3 partitions × 2 RF × 2 workers × 2.0 = **24.0 CPU**
+- **Total broker CPU**: **30.0 CPU**
+
 To change this setting, set the `generateResourceLimits.cpu` field to `Enabled` or `Disabled` in the Broker resource.
 
 # [Portal](#tab/portal)