This chapter covers EC2 placement groups—cluster, spread, and partition—a key topic for the SAA-C03 exam under Resilient Architectures (Objective 2.1). Placement groups control how EC2 instances are physically placed on underlying hardware, directly impacting performance, fault tolerance, and cost. Expect 2–3 exam questions on placement groups, often testing your ability to select the correct type for a given workload scenario. Mastering the trade-offs between latency, availability, and scale is essential for designing resilient, high-performance architectures.
Jump to a section
Imagine three different ways to organize 100 employees in a company.
Cluster Placement Group (Rack of Servers): You take a single, massive rack and cram all 100 employees into it, shoulder-to-shoulder, with a single high-speed elevator connecting their desks directly. They can pass papers instantly, but if the rack catches fire or the elevator breaks, everyone is affected. This is like a cluster placement group: all instances are in the same availability zone, packed close together to minimize network latency, but with a single point of failure.
Spread Placement Group (Orchestra): You place each employee on a separate, isolated platform spread across the entire office floor, each with their own power outlet and network cable. No two share a platform. This ensures that a power surge or network outage takes out at most one employee, but communication between them requires walking across the floor—higher latency. This mirrors a spread placement group: each instance is on a distinct rack and underlying hardware, maximizing fault isolation but with higher network latency between instances.
Partition Placement Group (Office Floor): You divide the office floor into 7 distinct zones, each with its own power and network infrastructure. You assign employees to zones, but within a zone they can sit close together. A failure in one zone (e.g., a burst pipe) affects only that zone, not the whole floor. This is exactly how a partition placement group works: instances are grouped into logical partitions (up to 7 per AZ), each partition sits on a separate rack with independent power and network, so a hardware failure takes out only one partition. You can pack many instances per partition, balancing fault tolerance and low latency.
What Are Placement Groups and Why Do They Exist?
Placement groups are a logical grouping of EC2 instances within a single Availability Zone (AZ) that influence how instances are placed on underlying hardware. They exist to solve a fundamental trade-off: you can have instances close together for low-latency communication (e.g., HPC clusters) or spread apart for high availability (e.g., critical web servers). Without placement groups, AWS spreads instances across multiple racks and data centers by default to maximize availability—but this increases network latency between instances. Placement groups give you explicit control over this placement.
How Placement Groups Work Internally
When you launch an instance into a placement group, AWS's placement algorithm selects a physical host (server) and rack based on the group type. The underlying hardware is abstracted, but the effect is deterministic:
Cluster Placement Group: All instances are placed on the same rack, often on the same hypervisor or adjacent hypervisors connected via a high-speed, low-latency network. This enables up to 10 Gbps of single-flow network throughput and sub-millisecond latency between instances. The rack shares power and network switches, so a rack failure takes down all instances in the group.
Spread Placement Group: Each instance is placed on a distinct rack, each with its own power and network. AWS guarantees that no two instances in a spread group share the same underlying hardware. The maximum number of instances per AZ per spread group is 7 (hard limit). This provides maximum fault isolation but introduces higher latency because instances are physically separated.
Partition Placement Group: Instances are divided into logical partitions (up to 7 per AZ). Each partition sits on a separate rack with independent power and network. Within a partition, instances are placed close together (like a mini-cluster), but different partitions are isolated. You can have many instances per partition (up to the instance limit of the account). Failures (e.g., rack power loss) affect only one partition.
Key Components, Values, and Defaults
- Maximums: - Cluster: No hard limit per group, but depends on instance type and account limits (typically up to 500 instances). - Spread: 7 instances per AZ per group. You can create multiple spread groups to exceed this. - Partition: 7 partitions per AZ per group. Each partition can hold many instances (e.g., hundreds). - Network Performance: - Cluster: Up to 10 Gbps single-flow, 25 Gbps with enhanced networking. Sub-millisecond latency. - Spread/Partition: Standard network performance (up to 5 Gbps single-flow, 10 Gbps with enhanced networking). Latency similar to random placement. - Supported Instance Types: All instance types, but cluster groups require supported instance types (e.g., compute-optimized, GPU instances). Check AWS documentation for compatibility. - AZ Constraint: All instances in a placement group must be in the same AZ. You cannot span AZs within a single placement group. - Group Name: Must be unique within your account per region. You can specify a placement group when launching instances via console, CLI, or SDK. - Default Placement: If no group specified, AWS uses default spread placement across racks (no single point of failure).
Configuration and Verification
You can create a placement group via:
- AWS Console: EC2 > Placement Groups > Create Placement Group. Choose name, strategy (cluster, spread, partition), and partition count (for partition).
- AWS CLI: aws ec2 create-placement-group --group-name MyGroup --strategy cluster
- Launch Instance: aws ec2 run-instances --placement-group MyGroup ...
Verification:
- CLI: aws ec2 describe-placement-groups --group-name MyGroup returns group details including strategy and instance list.
- Console: View placement group details to see which instances belong.
- Instance Metadata: curl http://169.254.169.254/latest/meta-data/placement/placement-group-name returns the group name.
Interaction with Related Technologies
Auto Scaling Groups (ASGs): You can specify a placement group when creating an ASG. The ASG will launch instances into that group. For partition groups, you must specify the partition number for each instance (or use a launch template with partition placement).
Elastic Load Balancing (ELB): ELB can distribute traffic to instances in a placement group. No special configuration needed.
Enhanced Networking: Required for cluster groups to achieve maximum throughput. Use instance types with ENA (Elastic Network Adapter) support.
Elastic Fabric Adapter (EFA): For HPC workloads, cluster groups combined with EFA provide ultra-low latency.
Reserved Instances: Can be used with placement groups—no conflict.
Spot Instances: Can be launched into placement groups, but cluster groups may have limited capacity for Spot.
Exam-Relevant Details
Cluster groups are for tightly coupled workloads requiring low latency and high throughput (e.g., HPC, data analytics). They sacrifice fault tolerance.
Spread groups are for critical instances that must be isolated from each other (e.g., multiple web servers for high availability). Limited to 7 per AZ.
Partition groups are for distributed systems that need fault isolation across partitions but can tolerate many instances per partition (e.g., Hadoop, Kafka, Cassandra). Each partition is isolated.
Common Trap: Candidates often choose spread groups for large distributed systems (e.g., 100-node Hadoop) but spread has a 7-instance limit. Partition is the correct choice for large-scale fault isolation.
Another Trap: Thinking cluster groups span AZs—they do not. All instances must be in the same AZ.
Exam Scenario: You need low latency between two instances for a real-time application. Answer: cluster placement group. Option: same AZ, same rack.
Summary of Mechanism
Placement groups are implemented at the hypervisor allocation layer. When you launch an instance, AWS's placement service checks the group type and enforces placement rules:
Cluster: Place all instances on the same rack (same top-of-rack switch, same power distribution unit).
Spread: Place each instance on a different rack (distinct failure domain).
Partition: Assign each instance to a partition, each partition mapped to a distinct rack.
The physical mapping is opaque to the user but guaranteed by AWS. This allows you to design for either performance or resilience.
Define Workload Requirements
First, determine if your workload requires low latency (e.g., real-time data processing, HPC) or high fault tolerance (e.g., critical web servers). Also consider scale: how many instances? If you need more than 7 instances and fault isolation, spread won't work. This step is critical because choosing the wrong type leads to either poor performance or insufficient availability.
Create Placement Group
Use AWS Console, CLI, or SDK to create a placement group with a unique name and strategy (cluster, spread, partition). For partition groups, specify the number of partitions (max 7 per AZ). The group is region-scoped and tied to a VPC. No instances are launched yet.
Launch Instances Into Group
When launching an EC2 instance, specify the placement group name. For partition groups, you can optionally specify the partition number. AWS will place the instance according to the strategy. For cluster groups, all instances must be in the same AZ. If you launch an instance without specifying a group, it's placed per default spread.
Verify Placement
After launch, verify the instance's placement group using AWS CLI (`describe-instances` or `describe-placement-groups`). For partition groups, you can see which partition each instance is in. For spread groups, confirm that no two instances share the same rack (by checking the `groupName` and `spreadStrategy`).
Monitor and Adjust
Use CloudWatch metrics (e.g., NetworkIn, NetworkOut) to verify performance expectations. If latency is higher than expected, check if instances are in the same placement group and AZ. For cluster groups, ensure enhanced networking is enabled. If fault tolerance is insufficient, consider moving to a different placement group type.
Enterprise Scenario 1: HPC Cluster for Financial Risk Modeling
A hedge fund runs Monte Carlo simulations across 100 compute-optimized EC2 instances (c5n.18xlarge) that require sub-millisecond latency for MPI communication. They use a cluster placement group in a single AZ. The instances are launched with enhanced networking (ENA) and Elastic Fabric Adapter (EFA) for maximum throughput. The group achieves 25 Gbps per flow and 0.1 ms latency. However, a rack power failure takes down the entire cluster, causing a 4-hour outage. To mitigate, they now run two separate cluster groups in the same AZ (if possible) or use a partition group with 2 partitions to isolate half the instances. The key lesson: cluster groups maximize performance but create a single point of failure. For critical HPC, consider partition groups to balance performance and resilience.
Enterprise Scenario 2: Multi-Tier Web Application with Spread Placement
An e-commerce company runs 6 web servers (t3.large) behind an ALB. They need high availability—no two servers should fail simultaneously. They use a spread placement group, placing each server on a separate rack. This ensures that a rack failure takes out at most one server. The group has 6 instances (under the 7-instance limit). They also use an Auto Scaling group with a spread placement group to maintain fault isolation during scale-out. A common issue: when they tried to add a 7th instance, it failed because the group reached its limit. They had to create a second spread group. This scenario is typical for small, critical workloads.
Enterprise Scenario 3: Distributed Database (Cassandra) with Partition Placement
A media streaming service runs a Cassandra cluster with 50 nodes across 3 AZs for fault tolerance. Within each AZ, they need to distribute nodes across failure domains to avoid correlated failures. They use a partition placement group with 7 partitions per AZ. Each partition corresponds to a rack. They launch 7 nodes per partition (total 49 nodes) and assign each node to a specific partition to spread the load. When a rack fails, only one partition (7 nodes) goes down, and the cluster remains operational. The misconfiguration trap: they originally used a spread group, which limited them to 7 instances per AZ—far too few. Partition groups allowed them to scale while maintaining fault isolation.
What SAA-C03 Tests on Placement Groups
The exam tests your ability to select the correct placement group type based on workload requirements. Objective 2.1 (Resilient Architectures) includes placement groups under 'Designing for fault isolation.' Expect questions that present a scenario and ask which placement group to use. Key discriminators: latency vs. fault tolerance, number of instances, and need for partition-level isolation.
Common Wrong Answers and Why Candidates Choose Them
Choosing spread for large distributed systems (e.g., 50-node Hadoop cluster). Candidates see 'fault tolerance' and think spread, but spread has a 7-instance limit. The correct answer is partition, which allows many instances per partition with fault isolation.
Choosing cluster for a web application requiring high availability. Candidates see 'low latency' but ignore fault tolerance. Cluster creates a single point of failure. The correct answer is spread (if ≤7 instances) or partition (if >7).
Thinking cluster groups span multiple AZs. The exam may describe a multi-AZ scenario and ask for a placement group. Candidates might choose cluster, but cluster is single-AZ. The correct answer is to use separate groups per AZ or no group.
Assuming partition groups limit instances per partition to 7. The limit is 7 partitions per AZ, but each partition can hold many instances. Candidates confuse partition count with spread's instance limit.
Specific Numbers and Terms That Appear Verbatim
'7 instances per AZ per spread placement group'
'7 partitions per AZ per partition placement group'
'Low latency and high throughput' for cluster groups
'No two instances share the same underlying hardware' for spread groups
'Partitions are isolated from each other' for partition groups
'All instances must be in the same Availability Zone' for cluster groups
Edge Cases and Exceptions
Reserved Instances: Can be used with placement groups, but the reservation applies to instance type, not placement.
Spot Instances: Can be launched into placement groups, but cluster groups may have limited capacity for Spot. If a Spot request cannot be fulfilled, the instance fails to launch.
Changing placement group after launch: You cannot move an instance to a different placement group after launch. You must terminate and relaunch.
Multiple placement groups in same AZ: You can have multiple groups of different types in the same AZ.
Launching into a full spread group: If you try to launch an 8th instance into a spread group, it fails with an error.
How to Eliminate Wrong Answers
If the scenario mentions 'large number of instances' (e.g., 100), eliminate spread immediately.
If the scenario mentions 'lowest possible latency' or 'HPC', eliminate spread and partition (unless partition also provides low latency? No—partition does not guarantee low latency between instances in different partitions).
If the scenario mentions 'fault tolerance across racks' and 'many instances', choose partition.
If the scenario mentions 'critical application with only a few instances', choose spread.
Always check the number of instances: if >7, spread is impossible.
Check if the workload is tightly coupled (cluster) or loosely coupled (spread/partition).
Cluster placement groups: low latency, high throughput, single point of failure, all instances in same AZ, no instance limit.
Spread placement groups: maximum fault isolation, 7 instances per AZ per group, each instance on different rack.
Partition placement groups: up to 7 partitions per AZ, each partition isolated, many instances per partition, good for large distributed systems.
You cannot change placement group after instance launch; must terminate and relaunch.
All instances in a placement group must be in the same Availability Zone.
Enhanced networking (ENA) is required for maximum performance in cluster groups.
Auto Scaling groups can be configured with placement groups, including partition placement with partition numbers.
These come up on the exam all the time. Here's how to tell them apart.
Cluster Placement Group
All instances on same rack, same AZ
Lowest latency (sub-millisecond), highest throughput (10-25 Gbps)
Single point of failure (rack failure kills all)
No instance limit per group (depends on account limits)
Best for HPC, tightly coupled workloads
Spread Placement Group
Each instance on separate rack, same AZ
Higher latency, standard network throughput
Maximum fault isolation (no two instances share hardware)
7 instances per AZ per group (hard limit)
Best for critical small-scale applications (e.g., 2-7 web servers)
Spread Placement Group
7 instances per AZ per group
Each instance isolated on its own rack
No partition concept
Best for small, critical workloads
Cannot scale beyond 7 instances per AZ
Partition Placement Group
Up to 7 partitions per AZ, many instances per partition
Instances within a partition share a rack; partitions are isolated
Logical partitions for fault isolation
Best for large distributed systems (Hadoop, Kafka, Cassandra)
Scales to hundreds of instances per group
Mistake
You can have up to 20 instances in a spread placement group per AZ.
Correct
The hard limit is 7 running instances per AZ per spread placement group. You can create multiple spread groups to exceed this.
Mistake
Cluster placement groups provide the highest fault tolerance.
Correct
Cluster groups place all instances on the same rack, creating a single point of failure. They provide the lowest fault tolerance.
Mistake
Partition placement groups guarantee that instances in different partitions are on different power sources and network switches.
Correct
True. Each partition maps to a distinct rack with independent power and network, so a failure affects only one partition.
Mistake
You can change the placement group of a running instance.
Correct
No. You must stop or terminate the instance and launch a new one into the desired placement group.
Mistake
Placement groups can span multiple Availability Zones.
Correct
All instances in a placement group must be in the same Availability Zone. You cannot span AZs within a single group.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A spread placement group places each instance on a separate rack, limiting the group to 7 instances per AZ. A partition placement group divides instances into up to 7 logical partitions, each on a separate rack, but each partition can hold many instances. Use spread for small, critical workloads and partition for large distributed systems requiring fault isolation.
Yes, instances in a placement group can be in different subnets within the same VPC and same Availability Zone. The placement group only affects physical placement, not network layer.
The launch fails with an error indicating that the placement group cannot accommodate more instances. You must either create another spread group or use a different placement group type.
Placement groups affect EC2 instance placement only. EBS volumes are attached to instances and are not directly impacted, but EBS performance can be affected by network distance. For optimal EBS performance, use cluster groups for instances that need low-latency EBS access.
Yes. You can specify a placement group when creating an Auto Scaling group. For partition groups, you must use a launch template that specifies the partition number or let ASG assign partitions automatically.
No. Placement groups are a free feature. You only pay for the EC2 instances and related resources.
No. You cannot move a running or stopped instance into a placement group. You must create a new instance with the placement group specified at launch.
You've just covered EC2 Placement Groups: Cluster, Spread, Partition — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?