EC2 offers three placement group strategies — cluster, spread and partition. What does each one do to where instances physically land, and which kind of workload does each suit?

## The problem placement groups solve Normally you have no say in which physical host, rack or network segment your instances land on — EC2 spreads them however it likes within the Availability Zone you chose. That is fine until physical adjacency starts to matter, and it matters in exactly two opposite directions: sometimes you want instances **as close together as possible** (latency), and sometimes you want them **as far apart as possible** (correlated failure). Placement groups are the control for both. A placement group is a free, zone-scoped construct you create and then reference at launch. ## Cluster: pack them together A cluster placement group asks EC2 to place instances close to each other on the network, inside a **single Availability Zone**. The result is the lowest inter-instance latency and the highest per-flow throughput EC2 offers, which is what HPC codes, tightly coupled simulations, and low-latency trading or distributed-training workloads need. The costs are real: - **One AZ means one failure domain.** A cluster group is architecturally the opposite of high availability. If the workload must survive an AZ event, a cluster group is the wrong tool. - **Capacity risk.** Packing many instances close together is a demanding request. The standard mitigation is to launch all the instances you need **in a single request**, so EC2 plans the placement once, and to use a homogeneous instance type — adding instances to an existing cluster group later is where `InsufficientInstanceCapacity` typically appears. To get the network benefit you also need instances whose types support enhanced networking, which effectively means current-generation types. ## Spread: keep them apart A spread placement group does the reverse: every instance is placed on **distinct underlying hardware** — different racks, with their own power and network — so that no single hardware failure can take out two of them. The trade is scale: a spread group permits at most **seven running instances per Availability Zone**. Spread it across three zones and you have twenty-one, which tells you what it is for. Use it for a small set of instances whose simultaneous loss would be catastrophic and which are not trivially replaceable: a quorum of consensus nodes, a pair of domain controllers, licence servers, a handful of stateful singletons. It is not a way to place a large web fleet. ## Partition: the middle ground A partition placement group divides the group into **up to seven partitions per Availability Zone**. Partitions share no underlying racks with each other, but a partition can hold as many instances as you like. So you get failure isolation *between* partitions with no cap on total fleet size. This is the shape that large replicated data systems want — HDFS, HBase, Cassandra, Kafka — because those systems already have a notion of replicas that must not share a failure domain. You place replica sets in different partitions and a rack-level failure loses one replica rather than all of them. EC2 tells you which partition an instance landed in, so topology-aware software can be configured to match: ```bash aws ec2 describe-instances \ --filters Name=placement-group-name,Values=kafka-pg \ --query 'Reservations[].Instances[].{Id:InstanceId,Partition:Placement.PartitionNumber,AZ:Placement.AvailabilityZone}' ``` You can let EC2 assign partitions or request a specific one at launch, which is how a broker or data node is pinned to the partition its rack-awareness configuration expects. ## Choosing between them The decision is a single question: **is adjacency an asset or a liability for this workload?** - Latency between peers dominates, and the workload can be rebuilt if the zone fails → **cluster**. - A handful of instances must never fail together → **spread**. - A large replicated system with its own replica placement rules → **partition**. - None of the above → **no placement group at all**, which is the right answer for most services. Ordinary stateless fleets behind a load balancer get their availability from spanning Availability Zones, and adding a placement group only introduces capacity constraints for no benefit. ## Practical notes Placement groups are per-region constructs referenced at launch; you cannot merge two groups, and moving a running instance into or out of a group requires it to be stopped. Mixing instance types inside a cluster group weakens the guarantee, because EC2 cannot always place dissimilar hardware close together. And none of this replaces multi-AZ design: a placement group shapes placement *within* the zones you already chose.