在AWS上跑分布式系统的人或多或少都遇到过这样的困惑：同样是m5.8xlarge实例，同样在一个可用区，为什么有的实例之间ping值稳定在0.3毫秒，有的却抖动到1毫秒以上？答案往往藏在Placement Group这个配置里。Placement Group决定了EC2实例在物理硬件上的摆放方式，而物理摆放方式直接决定了实例间通信走的是什么样的网络路径。这篇文章会从原理讲起，再带你搭一套测试环境，用真实数据看看三种放置策略在网络性能上的差距。
三种Placement Group策略的底层逻辑
AWS提供了三种放置策略，分别是cluster、partition和spread。很多人只是背了一下概念，但不太理解它们在网络层面到底意味着什么差别。
cluster模式的思路是把一组实例紧密地放在同一块物理机架上，甚至同一个机架的相邻槽位。这样做的好处是实例之间的网络路径非常短，流量大概率不会穿过数据中心的骨干交换层，延迟自然低，带宽也容易跑满。代价是这些实例共享同一组上游网络设备和电源，一旦机架级故障，整个集群可能同时掉线，所以cluster模式不适合对可用性要求高的服务，典型场景是HPC计算、大规模并行训练这类任务跑完就释放的负载。
spread模式正好相反，它把每个实例分散到不同的底层硬件上，同一时间每个可用区内一个spread group最多只允许7个运行中的实例。它的目标是故障域隔离，牺牲了一点网络亲和性来换取高可用，适合跑少数几台关键实例，比如数据库主从、堡垒机集群。partition模式则介于两者之间，它把实例分到不同的partition里，同一partition内的实例共享底层硬件，不同partition之间互相独立。Hadoop、Cassandra、EMR这类自带副本机制的分布式系统常用partition模式，把同一份数据的副本分布到不同partition，既拿到了局部的高密度组网，又保证了机架级容灾。
搭建测试环境并执行网络压测
光讲概念没有说服力，我们直接动手搭一套环境测一下。用CloudFormation或者AWS CLI都可以，这里给出CLI方式，先创建不同策略的Placement Group，再启动实例。
aws ec2 create-placement-group \ --group-name pg-cluster-test \ --strategy cluster aws ec2 create-placement-group \ --group-name pg-partition-test \ --strategy partition \ --partition-count 3 aws ec2 create-placement-group \ --group-name pg-spread-test \ --strategy spread aws ec2 run-instances \ --image-id ami-xxxxxxxx \ --instance-type m5.8xlarge \ --count 2 \ --placementGroupName pg-cluster-test \ --subnet-id subnet-xxxxxxxx \ --key-name my-key
测试实例建议选择m5.8xlarge以上规格，因为小规格实例的 baseline 带宽限制会成为瓶颈，测出来的数据反映的是实例规格而不是Placement Group。系统层面务必确认增强联网已启用，执行ethtool -i eth0查看驱动，如果看到ena且bus-info正常，说明网卡走了SR-IOV虚拟化直通，否则数据完全不可信。
测试工具推荐三个组合：ping看RTT，iperf3看TCP带宽，sockperf看UDP延迟和PPS。下面是一次典型测试的命令。
# 服务端实例执行 iperf3 -s # 客户端实例执行，测试TCP带宽，单流 iperf3 -c 10.0.1.20 -t 60 # 8条并行流，逼近网卡上限 iperf3 -c 10.0.1.20 -P 8 -t 60 # 测试PPS和延迟 sockperf ping-pong -i 10.0.1.20 -p 11111 --full-log ping.log
实测数据解读与常见误区
在同一可用区、相同实例规格的条件下，三种策略的典型结果大致是：cluster模式的RTT普遍在0.2到0.4毫秒之间，单流iperf3能接近线速，PPS表现也最好；spread模式RTT通常会高出一些，因为实例可能落在不同的机架甚至不同的网络汇聚组，流量要经过更多跳的交换设备。partition模式在同一partition内的表现接近cluster，跨partition则接近spread，这也是它设计上的中间态体现。
需要注意，同一可用区不等于网络就近。可用区本身就是一个或多个数据中心组成的逻辑概念，两个都标着us-east-1a的实例，物理上可能隔着相当远的距离。所以Placement Group是控制网络拓扑的手段，可用区只控制故障域，两者不能混为一谈。
还有几个常见的坑值得提醒。第一，cluster模式要求所有成员实例都启动在同一可用区，如果launch template里没有固定可用区，自动扩容可能会失败，报错信息往往只是含糊的InsufficientCapacity，排查起来很痛苦。第二，jumbo frame要显式确认，MTU 9001的巨型帧在cluster内部能明显提升单流吞吐，但默认路径MTU发现如果被安全组或ACL挡了ICMP，会退化到1500还很难察觉。第三，stop再start的实例（非stop-protected场景）在非cluster模式下可能被迁移到其他硬件，之前测好的网络基线可能悄悄失效，建议对关键集群使用置放群组加容量预留的组合来固化硬件位置。
总结一下选型思路：跑完即释放的高性能计算选cluster；自带副本机制的分布式存储和大数据选partition；只有三五台关键实例追求最大可用性就选spread。 Placement Group本身免费，唯一成本是规划上的心智负担，但换来的网络确定性在高性能场景下绝对值得。
Placement GroupEC2网络性能AWS修改时间：2026-09-03 11:41:08