By default, AWS uses a best-effort spread when placing your instances — it tries to put them on different hardware to reduce correlated failures, but makes no guarantees. For specialized workloads, you need explicit control over physical placement. That's what Placement Groups provide.
There are three types, each solving a different problem.
1. Cluster Placement Group (Optimize for Speed)
- Goal: Minimize network latency and maximize throughput between instances.
- Topology: Packs all instances as close together as physically possible — ideally on the same rack, within the same Availability Zone.
- What you get: Access to Enhanced Networking at up to 100 Gbps between instances, and the lowest possible inter-instance latency (single-digit microseconds).
- Use case: High-Performance Computing (HPC), tightly-coupled parallel jobs, financial modeling, scientific simulations where nodes exchange data constantly.
- Risk: All eggs in one basket. If that rack loses power or network connectivity, every instance in the group goes down simultaneously. This is an intentional trade-off: you're choosing speed over resilience.
2. Spread Placement Group (Optimize for Safety)
- Goal: Maximize availability by eliminating correlated hardware failures.
- Topology: Each instance is placed on a distinct rack with its own independent network uplink and power supply. AWS guarantees no two instances in the group share a rack.
- Limitation: Maximum 7 instances per Availability Zone per spread placement group.
- Use case: Small clusters of critical instances where simultaneous failure is unacceptable — primary/secondary database pairs, ZooKeeper quorum nodes, Kafka brokers.
- Key insight: The 7-instance limit is not arbitrary. It reflects the physical guarantee AWS is making: 7 distinct racks, 7 distinct failure domains.
3. Partition Placement Group (Optimize for Rack Awareness)
- Goal: Give distributed systems the information they need to replicate data safely across physical failure domains.
- Topology: Instances are divided into logical partitions (up to 7 per AZ). AWS guarantees that no two partitions share a rack. Each partition can contain many instances.
- What makes it different from Spread: Spread gives each instance its own rack. Partition gives each group of instances its own rack. This scales to hundreds of instances.
- Use case: Rack-aware distributed systems — Apache Hadoop (HDFS), Apache Cassandra, Apache Kafka. These systems have built-in rack awareness: if you tell Cassandra that nodes in partition 1 are on rack A and nodes in partition 2 are on rack B, it will ensure replicas are placed on different racks. If rack A fails, rack B still has a full copy.
- How to use it: When you launch an instance into a partition placement group, AWS exposes the partition number via the EC2 Instance Metadata Service. Your application (or bootstrap script) reads this and configures the node's rack label accordingly.