1. Overview

EC2 Placement Groups let you control how your instances are placed on the underlying hardware. Different strategies optimize for different goals: performance, availability, or cost. There are three strategies.

2. Cluster Placement Group

All instances are placed on the same rack (and often the same physical host) within a single Availability Zone. Optimized for the lowest possible network latency between instances.


Key Characteristics

  1. All instances in the SAME AZ, same rack
  2. 10 Gbps network bandwidth between instances (enhanced networking)
  3. Lowest latency, highest throughput (packets-per-second)
  4. If the rack fails, ALL instances fail simultaneously


Use Cases

  1. High Performance Computing (HPC)
  2. Big data jobs requiring fast inter-node communication
  3. Applications needing extremely low latency (sub-millisecond)


Best Practices

  1. Use the same instance type for all instances in the group
  2. Launch all instances at once (if possible) to reduce allocation failures
  3. Use enhanced networking (ENA) for best performance
Important Warning Cluster = HIGH PERFORMANCE but HIGH RISK. If the rack fails, you lose everything. Never use Cluster for workloads that need high availability. It is the opposite of a Spread group.

3. Spread Placement Group

Each instance is placed on a different physical rack. Designed to minimize the risk of simultaneous failure. Optimized for high availability.


Key Characteristics

  1. Each instance is on a DIFFERENT rack (different hardware, different power, different network)
  2. Can span multiple AZs within a Region
  3. Maximum of 7 instances per AZ per placement group
  4. If one rack fails, only one instance is affected


Use Cases

  1. Critical applications that must maximize availability
  2. Applications where individual instance failure must be isolated
  3. Primary/secondary database replicas that must not fail together
Spread Limit The 7-instance-per-AZ limit is a hard constraint. If you need more than 7 instances per AZ, consider Partition placement groups instead. With 3 AZs, a Spread group supports a maximum of 21 instances (7 × 3).

4. Partition Placement Group

Instances are divided into logical partitions. Each partition runs on a different rack. Instances in different partitions do NOT share underlying hardware. Designed for large distributed workloads.


Key Characteristics

  1. Up to 7 partitions per AZ
  2. Can span multiple AZs
  3. Hundreds of instances per group (no 7-instance limit like Spread)
  4. Each partition is on a separate rack — partitions are isolated from each other
  5. Instances within the SAME partition may share a rack
  6. You can see which instances are in which partition (metadata available)


Use Cases

  1. Hadoop, HDFS, HBase
  2. Apache Cassandra, Apache Kafka
  3. Any large, distributed, replicated workload that is partition-aware

5. Placement Groups Comparison

6. Important Rules

  1. You cannot merge placement groups
  2. An instance can only be in one placement group at a time
  3. You can move an existing instance into a placement group (must be stopped first)
  4. Not all instance types support all placement group strategies
  5. Placement groups are free — no additional charges

7. When to use

Use Placement Groups when you need to control how EC2 instances are physically placed on underlying hardware for performance, availability, or both.

Key exam triggers:

  1. "low latency between instances"
  2. "high throughput"
  3. "hardware failure isolation"
  4. "spread across racks."
  5. "HPC"
  6. "big data cluster"


Exam Tip Placement group questions: "Lowest latency between instances" = Cluster. "Maximum fault tolerance, each instance on separate hardware" = Spread. "Large distributed workload like Hadoop/Kafka" = Partition. Cluster = single AZ, high risk. Spread = 7 instances per AZ limit. Partition = up to 7 partitions per AZ, hundreds of instances total.