Study guide
Technical reference and lesson notes
Purpose of This Lesson
EC2 placement groups control how Amazon EC2 instances are positioned on the underlying AWS infrastructure. The correct placement group depends on whether the priority is:
- Maximum network performance and minimum latency
- Isolation of distributed workloads across physical racks
- Maximum hardware-level isolation for a small number of critical instances
Placement groups are an infrastructure placement decision, not a replacement for application-level resiliency, replication, or multi-AZ architecture.
Key Concepts
Cluster placement groups
A cluster placement group packs instances close together within a single Availability Zone. This is designed to provide:
- Very low inter-instance network latency
- High network throughput
- Strong performance for tightly coupled workloads
Typical use cases include:
- High-performance computing (HPC)
- Machine learning clusters
- High-speed data processing
- Applications with intensive east-west traffic
- Workloads using enhanced networking or Elastic Fabric Adapter (EFA), where supported
A cluster placement group can use multiple subnets, but all subnets must be in the same Availability Zone. Because instances are concentrated within an AZ, a hardware or Availability Zone issue can affect a relatively large portion of the group.
Partition placement groups
A partition placement group divides instances into logical partitions. Each partition is placed on separate underlying hardware racks, reducing the chance that a single hardware failure affects multiple partitions.
Instances within the same partition can still share underlying hardware. Therefore, partition placement groups provide group-level isolation rather than one-instance-per-rack isolation.
They are well suited to distributed systems that already replicate data across nodes or partitions, including:
- Apache Hadoop and HDFS
- Cassandra
- Large distributed NoSQL systems
- Distributed queues and streaming platforms
Partition placement groups can span multiple Availability Zones and subnets. You specify the number of partitions, with up to seven partitions per Availability Zone.
Spread placement groups
A spread placement group places each instance on distinct underlying hardware, typically across separate racks. This minimizes correlated hardware failure and provides the strongest instance-level isolation of the three placement group types.
Spread placement groups are appropriate for a small number of instances that must not fail together, such as:
- Critical control-plane nodes
- Small clusters of replicated application servers
- Independent primary and standby instances
- Infrastructure components requiring strong hardware separation
A spread placement group can span multiple Availability Zones and subnets. It supports a maximum of seven running instances per Availability Zone per placement group.
Architecture Decision Guide
| Requirement | Recommended placement group | Why |
|---|---|---|
| Lowest possible latency between tightly coupled EC2 instances | Cluster | Packs instances closely within one AZ |
| Highest network throughput for HPC or ML | Cluster | Optimizes inter-instance networking; can be used with EFA where supported |
| Distributed database or filesystem requiring rack-level separation | Partition | Separates groups of instances across racks |
| Strongest isolation for a small number of critical instances | Spread | Places each instance on separate underlying hardware |
| More than seven critical instances per AZ needing individual rack isolation | Not spread alone | The seven-instance-per-AZ limit requires another design, such as multiple placement groups or a different resiliency strategy |
| Multi-AZ distributed workload | Partition or spread | Cluster placement groups are limited to one AZ |
| Workload that can tolerate correlated failure and prioritizes performance | Cluster | Performance takes precedence over hardware isolation |
Placement group selection sequence
- Determine whether the workload needs physical proximity or physical separation.
- If low latency and high throughput are dominant, evaluate a cluster placement group.
- If the application is distributed and needs failure-domain separation between node groups, evaluate a partition placement group.
- If each instance must be isolated from every other instance, evaluate a spread placement group.
- Confirm Availability Zone scope, instance limits, capacity, networking support, and application replication requirements.
Exam-Relevant Takeaways
- Cluster means close together: best for low latency and high throughput, but limited to one Availability Zone.
- Partition means separate groups: each partition is placed on a separate rack, and the group can span Availability Zones.
- Spread means separate instances: each instance is placed on separate hardware, providing the strongest isolation.
- Partition placement groups support up to seven partitions per Availability Zone.
- Spread placement groups support up to seven running instances per Availability Zone.
- A cluster placement group may use multiple subnets, but those subnets must belong to the same AZ.
- Placement groups influence infrastructure placement; they do not automatically provide data replication, failover, or protection from an entire AZ failure.
- For distributed systems such as HDFS or Cassandra, partition placement is usually more appropriate than spread because the workload benefits from rack-level separation while supporting larger node counts.
- Cluster placement groups are most effective when instances are launched as a coordinated group. Capacity constraints can make launching or adding instances more difficult.
Common Exam Traps
- Choosing cluster for multi-AZ resilience: A cluster placement group is constrained to a single AZ. Use partition or spread when the placement group must span AZs.
- Confusing partition and spread: Partition separates groups of instances; spread separates each individual instance.
- Assuming partition provides one-instance-per-rack isolation: Multiple instances in the same partition can share a rack or failure domain.
- Ignoring the spread limit: Spread placement groups are intended for small deployments and have a seven-running-instances-per-AZ limit.
- Treating placement groups as disaster recovery: They address placement on AWS infrastructure, not backups, replication, multi-region recovery, or application failover.
- Using spread for a large distributed database by default: A partition placement group is generally a better fit when the application has many nodes and already distributes replicas across partitions.
- Assuming enhanced networking alone determines placement: Enhanced networking improves network performance, while the placement group controls physical proximity or separation.
Real-World Engineer Notes
- A cluster placement group can deliver excellent performance, but concentrating instances in one AZ creates a larger correlated-failure domain. Design the application so that another AZ or recovery environment can take over when availability matters.
- Placement group membership is an EC2 launch and capacity consideration. Test scaling, replacement, and instance-type changes rather than validating only the initial deployment.
- Partition placement groups work best when the application understands failure domains and distributes replicas across partitions and AZs. Merely assigning instances to partitions does not guarantee correct data placement.
- Spread placement groups are useful for a small set of highly important nodes, but normal multi-AZ Auto Scaling and service-level redundancy may be more practical for larger fleets.
- Placement group behavior and supported configurations can vary by instance type and AWS Region. Confirm current EC2 documentation when using specialized networking, EFA, or unusual instance configurations.
Quick Reference Summary
- Cluster: One AZ, instances close together, lowest latency and highest throughput.
- Partition: Multiple AZs allowed, groups separated across racks, suited to large distributed systems.
- Spread: Multiple AZs allowed, one instance per separate rack or hardware, strongest isolation for small groups.
- Cluster tradeoff: Better performance, greater correlated-failure risk.
- Partition tradeoff: Good rack-level isolation and scale, but instances within a partition are not individually isolated.
- Spread tradeoff: Best isolation, but limited to seven running instances per AZ.
Flashcards
- Q: What is the primary goal of a cluster placement group?
A: Very low latency and high network throughput between EC2 instances.
- Q: How many Availability Zones can a cluster placement group use?
A: One Availability Zone.
- Q: Can a cluster placement group use multiple subnets?
A: Yes, provided all subnets are in the same Availability Zone.
- Q: What does a partition placement group isolate?
A: Logical groups of instances, with each partition placed on separate underlying racks.
- Q: Which workloads commonly benefit from partition placement groups?
A: HDFS, Hadoop, Cassandra, and other large distributed systems.
- Q: How many partitions can a partition placement group have per Availability Zone?
A: Up to seven.
- Q: What is the defining property of a spread placement group?
A: Each instance is placed on separate underlying hardware, typically separate racks.
- Q: What is the spread placement group limit per AZ?
A: Seven running instances per Availability Zone per placement group.
- Q: Which placement group offers the strongest hardware failure isolation?
A: Spread placement groups.
- Q: Which placement group is best for tightly coupled HPC nodes?
A: A cluster placement group.
- Q: Which placement group can span multiple Availability Zones while separating groups of nodes?
A: A partition placement group.
- Q: Do placement groups provide application-level failover automatically?
A: No. The application and surrounding architecture must provide replication and recovery.
Practice Questions
Question 1
A financial modeling application runs a tightly coupled HPC workload across 32 EC2 instances. The workload exchanges large volumes of data between instances and requires the lowest practical network latency. The application can run within one Availability Zone, and the team is willing to accept AZ-level recovery through a separate environment. Which design is most appropriate?
- A. Spread placement group across three Availability Zones
- B. Partition placement group with one partition per instance
- C. Cluster placement group in one Availability Zone
- D. No placement group because enhanced networking provides the same behavior
Correct answer: C
A cluster placement group places instances close together in one AZ and is designed for low latency and high throughput. Spread is limited to seven running instances per AZ, while partition placement is intended for failure-domain separation rather than maximum proximity.
Question 2
A company is deploying a large Cassandra cluster. It wants node groups separated across physical racks and Availability Zones to reduce the effect of infrastructure failures. Which placement group should the architect recommend?
- A. Cluster placement group
- B. Partition placement group
- C. Spread placement group with every node isolated
- D. Dedicated Hosts only
Correct answer: B
Partition placement groups separate instances into rack-level partitions and can span multiple AZs. This matches the failure-domain and scale requirements of Cassandra. A spread placement group is limited to seven running instances per AZ and is better for small critical groups.
Question 3
An application has six critical EC2 instances in each of two Availability Zones. No two instances should share the same underlying rack whenever possible. Which option best matches this requirement?
- A. Cluster placement group
- B. Partition placement group with two partitions
- C. Spread placement group
- D. Auto Scaling group without a placement group
Correct answer: C
A spread placement group provides individual instance-level hardware isolation and supports up to seven running instances per AZ. A partition placement group separates groups, but instances in the same partition may share hardware.
Question 4
An architect proposes a cluster placement group for an application that must distribute instances across three Availability Zones for high availability. What is the principal issue with this proposal?
- A. Cluster placement groups support only one subnet total
- B. Cluster placement groups cannot use enhanced networking
- C. Cluster placement groups are limited to a single Availability Zone
- D. Cluster placement groups support only seven instances per AZ
Correct answer: C
Cluster placement groups are scoped to a single AZ, although they can use multiple subnets within that AZ. A multi-AZ placement-group design should generally use partition or spread placement groups, depending on the isolation requirement.
Question 5
A team needs to isolate 20 independent control-plane instances in one Availability Zone, with every instance placed on separate hardware. Which statement is most accurate?
- A. One spread placement group satisfies the requirement
- B. One partition placement group always places every instance on a separate rack
- C. A single spread placement group cannot satisfy the requirement because of its seven-instance-per-AZ limit
- D. A cluster placement group provides the strongest hardware isolation
Correct answer: C
Spread placement groups provide the strongest per-instance isolation, but only support seven running instances per AZ per placement group. The architect must reconsider the design, potentially using multiple placement groups where appropriate or relying on a broader resiliency strategy rather than assuming one spread group can contain all 20 instances.