DEV Community

Cover image for AWS EC2 Placement Groups Explained (2025): High Availability, Cluster, Spread & Partition with Real-World Automation
Ismail Kovvuru
Ismail Kovvuru

Posted on

AWS EC2 Placement Groups Explained (2025): High Availability, Cluster, Spread & Partition with Real-World Automation

#aws #devops #discuss #terraform

Learn to master AWS EC2 Placement Groups in 2025: Cluster, Spread, and Partition. When to use them, real scenarios, Terraform, CloudFormation & CLI scripts, capacity pitfalls, practical HA design, and troubleshooting.

Many AWS engineers never touch Placement Groups — and then wonder why their HPC jobs fail to launch or why a single rack outage kills their entire Kafka cluster.

EC2 Placement Groups are one of AWS’s least understood yet most powerful tools for designing true rack-level High Availability, low-latency HPC, and fault-domain isolation at scale.

What is an EC2 Placement Group?

By default, when you launch EC2s, AWS places them where it best fits capacity & resiliency needs.

A Placement Group (PG) lets you override that default — so you can:

  1. Pack nodes together for max speed
  2. Spread them apart for fault isolation
  3. Split them into clear failure domains

The 3 Placement Group Types 

| Type          | Best For                   | How It Works                                                     | Limits                                             | When to Use                                                      |
| ------------- | -------------------------- | ---------------------------------------------------------------- | -------------------------------------------------- | ---------------------------------------------------------------- |
|   Cluster     | HPC, ML, GPU               | Puts all nodes on same rack / rack set                           | Single AZ, practical limit is available hardware   | When you need ultra-low latency, high throughput                 |
|   Spread      | Small HA nodes             | Guarantees each node is on separate rack                         | 7 per AZ, can span AZs                             | When 3–7 nodes must survive single rack failure                  |
|   Partition   | Large distributed clusters | Divides nodes into partitions → racks → explicit failure domains | Up to 7 partitions per AZ, each can hold many EC2s | When you need explicit rack-level fault domains for big clusters |
Enter fullscreen mode Exit fullscreen mode

Cluster Placement Group — What It Is ?
A Cluster Placement Group tries to pack your EC2 instances as close together as possible, usually in the same rack, to minimize latency and maximize throughput.

Used for:

  • HPC jobs
  • Distributed ML training
  • Big data pipelines needing tight east-west traffic

Why not always use it?
If the rack runs out of slots, your launch fails — so you must design for capacity.

Always pair Cluster PG with Capacity Reservations for predictable launches.

+-----------------------------+
|      Cluster PG (AZ-a)      |
+-----------------------------+
|                             |
| [ Rack A ]                  |
| -------------------------   |
| EC2-1   EC2-2   EC2-3       |
| EC2-4   EC2-5   EC2-6       |
|                             |
+-----------------------------+
Enter fullscreen mode Exit fullscreen mode

Spread Placement Group — What It Is
A Spread Placement Group places each EC2 on a completely separate rack with separate hardware, power, and network.

Used for:

  • Small sets of must-not-fail nodes
  • HA quorum services (web servers, payment front ends, DNS)

Limit: Only 7 per AZ — so multi-AZ Spread PGs are common.

+-----------------------------------------------+
|               Spread PG (AZ-a)                |
+-----------------------------------------------+
|                                               |
| [ Rack A ]   EC2-1                            |
| [ Rack B ]   EC2-2                            |
| [ Rack C ]   EC2-3                            |
|                                               |
+-----------------------------------------------+
Enter fullscreen mode Exit fullscreen mode

Partition Placement Group — What It Is
A Partition PG splits your cluster into partitions → mapped to rack sets → each acts as a fault domain.

Used for:

  • Large clusters like Kafka, Cassandra, Hadoop
  • If Rack A fails, only Partition 1 is affected → cluster keeps running 
+-----------------------------+
|  Partition Placement Group  |
+-----------------------------+
|                             |
| Partition 1 → Rack A        |
| -------------------------   |
| EC2-1   EC2-2   EC2-3       |
|                             |
| Partition 2 → Rack B        |
| -------------------------   |
| EC2-4   EC2-5   EC2-6       |
|                             |
| Partition 3 → Rack C        |
| -------------------------   |
| EC2-7   EC2-8   EC2-9       |
+-----------------------------+
Enter fullscreen mode Exit fullscreen mode

How Many EC2s? — Actual Limits 

| Type          | Max per AZ                                     | Multi-AZ?                     | Notes                               |
| ------------- | ---------------------------------------------- | ----------------------------- | ----------------------------------- |
| 1.Cluster     | No strict limit, practical capacity limit only |   One AZ only                 | Constrained by available rack slots |
| 2.Spread      | 7 per AZ                                       |   Create one Spread PG per AZ | Each instance on different rack     |
| 3.Partition   | 7 partitions per AZ (each can hold 100s)       |   One AZ only                 | Must replicate across AZs yourself  |
Enter fullscreen mode Exit fullscreen mode

Why These Limits Exist 

| Type          | Limit               | Why?                            | If Exceeded                          |
| ------------- | ------------------- | ------------------------------- | ------------------------------------ |
| 1.Cluster     | Hardware capacity   | All nodes must fit on same rack | `InsufficientInstanceCapacity` error |
| 2.Spread      | 7 per AZ            | AWS guarantees unique racks     | 8th instance won’t launch            |
| 3.Partition   | 7 partitions per AZ | 7 unique rack sets per AZ       | Error if you request 8+ partitions   |
Enter fullscreen mode Exit fullscreen mode

These limits come from real hardware constraints — not arbitrary. So you must design for them.

Real Error Snippet

Trying to launch a big Cluster PG without capacity?

An error occurred (InsufficientInstanceCapacity) when calling the RunInstances operation:
We currently do not have sufficient m5.4xlarge capacity in the Availability Zone you requested.
Our system will be working on provisioning additional capacity.
Enter fullscreen mode Exit fullscreen mode

How to fix:

  1. Try this one later
  2. Switch AZ
  3. Use Capacity Reservation: 
aws ec2 create-capacity-reservation \
  --instance-type m5.4xlarge \
  --instance-count 4 \
  --availability-zone us-east-1a
Enter fullscreen mode Exit fullscreen mode

Terraform, CLI & CloudFormation — Explained

Terraform — Spread PG

# Define a Placement Group resource in AWS using Terraform
resource "aws_placement_group" "spread_pg" {
  name     = "my-spread-pg"   # Human-friendly name for this PG
  strategy = "spread"         # Placement strategy: Spread means each instance on a separate rack
}

# Launch an EC2 instance attached to the Spread Placement Group
resource "aws_instance" "web_node" {
  ami             = "ami-xxxxxxx"                 # Replace with your AMI ID (e.g., Amazon Linux)
  instance_type   = "t3.micro"                    # Choose your desired instance type
  placement_group = aws_placement_group.spread_pg.name  # Attach to the defined Spread PG
}
Enter fullscreen mode Exit fullscreen mode

How to use:

  1. Save as main.tf
  2. Run: 
terraform init   # Initialize Terraform
terraform plan   # See what will be created
terraform apply  # Create the PG and launch your instance
Enter fullscreen mode Exit fullscreen mode

AWS CLI — Spread PG

# Create a Spread Placement Group named "my-spread-pg"
aws ec2 create-placement-group \
  --group-name my-spread-pg \
  --strategy spread

# Launch an EC2 instance into the Spread Placement Group
aws ec2 run-instances \
  --image-id ami-xxxxxxx \    # Replace with your AMI ID
  --instance-type t3.micro \  # Choose your instance type
  --placement GroupName=my-spread-pg   # Attach to your Spread PG
Enter fullscreen mode Exit fullscreen mode

How to use:

  1. Replace ami-xxxxxxx with a real AMI ID (e.g., Amazon Linux 2).
  2. Run each command in your terminal (must be authenticated with aws configure). CloudFormation — Spread PG 
Resources:
  # Define the Placement Group with Spread strategy
  MyPlacementGroup:
    Type: AWS::EC2::PlacementGroup
    Properties:
      Strategy: spread

  # Launch an EC2 instance inside the Placement Group
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-xxxxxxx      # Replace with your AMI ID
      InstanceType: t3.micro    # Your desired instance type
      PlacementGroupName: !Ref MyPlacementGroup  # Reference the defined Spread PG
Enter fullscreen mode Exit fullscreen mode

How to use:

  1. Save as spread-pg.yaml
  2. Deploy with: 
aws cloudformation create-stack \
  --stack-name my-spread-stack \
  --template-body file://spread-pg.yaml
Enter fullscreen mode Exit fullscreen mode

Tips

  1. Always double-check your AMI ID — wrong region = launch failure.
  2. Use terraform destroy to clean up your test infra.
  3. Tag your Placement Groups (tags block in Terraform) for cost tracking.
  4. Combine with an Auto Scaling Group if you need elasticity with rack-level isolation.

AWS Terms Cheat Sheet 

| Term                 | What It Means                  |
| -------------------- | ------------------------------ |
| Placement Group      | Logical rack placement control |
| Cluster PG           | Same rack                      |
| Spread PG            | Separate racks                 |
| Partition PG         | Fault-domain racks             |
| Capacity Reservation | Guarantees physical slots      |
| AZ                   | Availability Zone              |
| ASG                  | Auto Scaling Group             |
Enter fullscreen mode Exit fullscreen mode

Updated — Multi-AZ Placement Groups (2025)

1. Cluster PG:
Not multi-AZ capable. A Cluster Placement Group must keep all instances physically close on the same rack or rack set for ultra-low latency — this is only possible inside a single Availability Zone. Cross-AZ networking would destroy its main benefit.

2. Partition PG:
Not multi-AZ capable. A Partition Placement Group logically maps each partition to a unique rack set within one AZ to create explicit failure domains. AWS does not support Partition PGs that span multiple AZs. To achieve multi-AZ fault tolerance, deploy separate Partition PGs in each AZ and handle replication at the application layer (e.g., Kafka multi-AZ topic replication).

3. Spread PG:
Multi-AZ capable. Unlike Cluster or Partition, a Spread Placement Group can be deployed in multiple AZs by creating one Spread PG per AZ. Each guarantees that its instances are placed on separate racks in that specific AZ. Combining multiple Spread PGs across AZs gives you both rack-level failure isolation and AZ-level disaster recovery for small, critical node sets.

Best Practice: When using Spread PG for multi-AZ HA, plan separate subnets, separate Spread PGs, and properly configure cross-AZ load balancing (e.g., ALB or NLB) to keep traffic healthy if a rack or AZ fails.

Conclusion

Designing high-performance, fault-tolerant EC2 workloads is far more than just choosing the right instance type — it’s also about controlling where your instances run physically.

Placement Groups (Cluster, Spread, and Partition) are powerful tools for advanced engineers who truly need:

  1. Ultra-low network latency (Cluster)
  2. Rack-level fault tolerance for critical nodes (Spread)
  3. Explicit fault domains for large clusters (Partition)

Are they recommended for every workload?
No. For most small or generic auto-scaling workloads, AWS’s default placement is good enough — using Placement Groups when you don’t need them can add unnecessary complexity and failure points.

When are they strongly recommended?

  • When you run HPC, distributed GPU, or tight MPI jobs needing rack-level speed (Cluster)
  • When you must guarantee that no single rack outage takes down all quorum nodes (Spread)
  • When you design large, stateful clusters that need explicit failure domains for fast recovery (Partition)

What to keep in mind before using them:

  1. Always verify AZ capacity. Cluster PGs commonly hit Insufficient Instance Capacity if you request large node counts.
  2. Combine Cluster PGs with Capacity Reservations for mission-critical HPC.
  3. Design Spread PGs for multi-AZ from day one — never assume one AZ’s 7-instance limit will be enough for future scale.
  4. Partition PGs do not magically replicate across AZs — you must handle multi-AZ replication at the app level.

Placement Groups work best when you deeply understand the physical infra behind AWS’s virtual promise. Used right, they unlock HA and throughput levels you can’t get from default placement alone. Used wrong, they cause launch failures or false sense of redundancy.

References — AWS Official Docs

  1. AWS Placement Groups Documentation
  2. AWS EC2 Capacity Reservations
  3. AWS HPC Best Practices
  4. AWS Well-Architected Framework — Reliability Pillar

You will find these topics useful

AWS Bedrock vs SageMaker JumpStart: Which One to Use for Your GenAI Use Case?

AWS Bedrock or SageMaker JumpStart? Deep-dive comparison for GenAI projects. Use cases, costs, and performance insights explained clearly.

favicon dubniumlabs.blogspot.com

10 Proven kubectl Commands: The Ultimate 2025 AWS Kubernetes Guide

10 proven kubectl commands with examples for AWS DevOps in 2025. Master Kubernetes clusters, pods, deployments, services, and ultimate hands-on.

favicon dubniumlabs.blogspot.com

Top comments (0)