Hey yuncancode - Regarding placement of machines, we only controlled the placement of machines in the same availability zone in the us-east region. We did not u

Hey yuncancode - Regarding placement of machines, we only controlled the placement of machines in the same availability zone in the us-east region. We did not use more granular controls, such as AWS's Placement groups, Azure's Proximity placement groups, or GCP's placement policies. We did this to ensure fairness in the test between the cloud providers and to align with a common pattern of distributing machines within an availability zone to maximize availability. Fairness: Each of the cloud provider's have varying placement systems. According to AWS's documentation, AWS's Placement groups allows one to choose among three different placement strategies: Cluster, Partition, and Spread. On the other end of the spectrum, Azure's Proximity placement groups are focused on a single strategy of minimizing network latencies. In the end, we decided to go with the default placement of machines for each cloud by not using these granular controls. Maximizing Availability: As discussed in more detail in the Network Benchmark section of the report, there is a tradeoff between maximizing availability and minimizing network latency when placing machines. For this report, we intentionally did not use the Cluster strategy. We oriented our tests with the common pattern among CockroachDB use cases of distributing one’s machines across an availability zone to maximize availability. Depending on one’s use case, it also may make sense to focus more on minimizing latency.