In AKS, the absolute maximum number of nodes that a cluster can have depends on a few configurations, including whether the node is in a VM State Set or Availability Set, and whether cluster networking uses kubenet or the Azure CNI. Even then, it is still unclear which number takes absolute precedence for specific configurations.

Meanwhile, in EKS, planning for the maximum number of pods scheduled on a Linux node requires some research and math. EKS clusters use the AWS VPC CNI for cluster networking. This CNI puts the pods directly on the VPC network by using ENIs (Elastic Network Interfaces), virtual network devices attached to EC2 instances. Different EC2 instance types support both a different number of ENIs and different IP addresses (one is needed per pod) per ENI.Therefore, to determine how many pods a particular EC2 instance type can run in an EKS cluster, you would get the values from this table and plug them into this formula: ((# of IPs per Elastic Network Interface - 1) * # of ENIs) + 2. A c5.12xlarge EC2 instance, which can support 8 ENIs with 30 IPv4 addresses each, can therefore accommodate up to ((30 - 1) * 8) + 2 = 234 pods. Note that large nodes with the maximum number of scheduled pods will eat up the /16 IPv4 CIDR block of the cluster’s VPC very quickly. Pod limits for Windows nodes in EKS are easier to compute and much more lower. Here, use the formula # of IP addresses per ENI - 1. The same c5.12xlarge instance could run as many as 234 pods as a Linux node could only run 29 pods as a Windows node.