AWS Placement Groups: Control Where Your Instances Run
AWS Placement Groups let you control where EC2 instances run relative to each other. Use a Cluster group for low-latency HPC, or Spread/Partition groups to reduce correlated hardware failures. The main footgun is picking the wrong strategy for your workload.
Why it exists
By default, AWS tries to spread your instances across hardware to minimize risk. But some applications need the exact opposite for low latency, while others need stronger guarantees about separation. Placement groups give you direct control over the physical location of your EC2 instances to optimize for performance or fault tolerance.
The mental model
A placement group is a logical label you apply to instances to enforce a physical placement strategy. It's like telling the datacenter manager: "Put these servers in the same rack" (Cluster), "Put these servers in different racks" (Spread), or "Group these servers into sets, and make sure each set is in a different rack" (Partition).
How it works
You create a placement group with one of three strategies. When you launch an instance into that group, AWS enforces the rule. The three strategies are: Cluster, which packs instances close together in one Availability Zone for low-latency networking; Partition, which spreads instances across logical hardware partitions, each with its own power and network; and Spread, which strictly places each instance on distinct underlying hardware.
When to use it
Use Cluster for High-Performance Computing (HPC) or any tightly-coupled workload needing minimal network latency. Use Partition for large distributed systems like Kafka or Cassandra, where you want to reduce the chance of losing multiple nodes to a single hardware failure. Use Spread for a small number of critical instances, like a primary and secondary database, to maximize availability.
When not to use it
Do not use a Cluster group if your primary goal is high availability, as it concentrates your failure risk onto a single rack. Avoid using a Spread group for a very large number of instances, as you can exhaust the available distinct hardware in an Availability Zone. An instance can only be in one placement group at a time, and you cannot merge groups.
One canonical example
A financial modeling application runs a simulation across 10 compute nodes that must communicate constantly. To minimize network latency, the nodes are launched into a Cluster placement group. This ensures they are physically co-located, enabling the high-speed communication needed for the job to complete on time. If high availability were the goal instead, a Spread group would be used.
Interview question
Which AWS Placement Group strategy is best for a large distributed database to minimize correlated hardware failures?
- a.Dedicated Host, to provide exclusive physical servers for the database instances.
- b.Cluster, to ensure all nodes are in the same rack for fastest communication.
- c.Spread, to place each instance on entirely distinct hardware for maximum isolation.
- d.Partition, to distribute instances across logical hardware segments, reducing single point of failure impact.Correct
Why? this is the answer
Partition placement groups are designed for large distributed systems like Kafka or Cassandra, allowing instances to be spread across logical hardware partitions to reduce the chance of multiple nodes failing from a single hardware issue. While Spread groups also offer isolation, they are typically recommended for a small number of critical instances, not large distributed databases, due to the potential to exhaust distinct hardware.
Just read this? Test yourself on what you have been reading.
Read the original → docs.aws.amazon.com
- #aws
- #ec2
- #cloud-computing
- #infrastructure
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on aws — each one lists the topics its interview covers.
See open roles