An engineer deploys a two-pod Cisco ACI Multi-Pod environment. Why should no more than two Cisco APIC controllers be deployed in the same pod?

APIC capacity relates to management capabilities, not data plane scaling, and the number per pod constraint is primarily for resilience, not equal scaling capacity.

Limiting APIC controllers to no more than two per pod ensures that the three replicas of each data shard in the APIC's distributed database are spread across different pods. This design prevents the loss of all replicas for a shard if an entire pod fails, maintaining data availability and cluster quorum.

Hair-pinning traffic to the primary APIC controller between pods is not the primary architectural driver for limiting APICs per pod; resilience and data distribution are key.

While having controllers in each pod is desirable for local access, the specific limit of 'no more than two' is driven by redundancy requirements for data sharding, not simply ensuring local access.