One more thing, from the docs you can also infer the level of overcommit of the networking of the host by looking at the documented perf of .metal instances. Fo

One more thing, from the docs you can also infer the level of overcommit of the networking of the host by looking at the documented perf of .metal instances. For example m6in.8xlarge has 50 Gbps networking and m6in.metal has 200 Gbps. But also m6in.metal is equivalent to m6in.32xlarge in terms of capacity, and 32xlarge is 4 times bigger than 8xlarge. So from that you can easily tell that m6in.8xlarge has no overcommit for networking because the network and CPU/mem allocation match exactly. At the same time you can tell that m6in.large does have network overcommit; m6in.large is 1/64th of the .metal instance in terms of size but 25 Gbps × 64 = 1600 Gbps, 8 times more than the 200 Gbps of the .metal instance! Finally EC2 has controls for instance "tenancy" and "placement"; you can ensure that your instances are run on hosts dedicated to your account, again avoiding host-level noisy neighbours. Of course both of these aspects only control the physical host, the networking infra outside the host is afaik almost completely out of control. But at the same time I'd be surprised if there is any significant level of congestion within an AZ. This is all to say that there is whole spectrum of things between "using random public instances with no consideration" and "set up private dedicated hardware lab", its not just binary choice.