Two EC2 topics quietly decide a handful of SAA-C03 marks, and both are about where your instances physically run rather than what they are: placement groups and instance tenancy. They show up as scenario questions — “an HPC workload needs the lowest possible node-to-node latency,” or “a company must run Windows Server under a per-physical-core license they already own” — and each has one best answer. Miss the vocabulary and these look interchangeable; learn the mechanics and they become quick, confident points.
This guide covers both in the depth the exam actually rewards. First, the three placement group strategies — cluster, spread, and partition — including the numeric limits and gotchas AWS loves to test. Then tenancy — shared (the default), Dedicated Instances, and Dedicated Hosts — and the one comparison that trips up most candidates: Dedicated Hosts vs Dedicated Instances. Throughout you’ll find decision tables that map a scenario’s strongest signal to the right choice, which is exactly the skill the SAA-C03 measures.
Where Placement and Tenancy Fit on the SAA-C03
The exam is built around designing high-performing, resilient, secure, and cost-optimised architectures. Placement groups live mostly in the performance and resilience conversation: they influence latency, throughput, and how instance failures correlate. Tenancy lives mostly in the security, compliance, and cost conversation: it controls hardware isolation and licensing. You don’t configure anything in the exam — you choose. So the goal here is to build a reliable scenario-to-answer reflex, the same way you would for storage classes or load balancer types.
What a Placement Group Is
By default, AWS spreads your EC2 instances across underlying hardware to reduce correlated failures — you don’t control where they land. A placement group lets you influence that placement for a specific goal: either packing instances tightly for speed, or separating them deliberately for fault isolation. Placement groups themselves are free; you only pay for the instances.
There are three strategies, and picking between them is the whole game.
Cluster Placement Groups: Pack Tightly for Low Latency
A cluster placement group packs instances close together on the same high-bisection-bandwidth hardware within a single Availability Zone. Instances get the lowest network latency and highest packet-per-second throughput the platform can offer — network flows between instances can reach very high bandwidth when using the Elastic Network Adapter.
Use a cluster placement group when the workload is tightly coupled and node-to-node communication dominates performance:
- High-performance computing (HPC) and scientific simulation.
- Big data jobs that need fast, low-latency chatter between nodes.
- Any workload where milliseconds and throughput between instances are the bottleneck.
The trade-off is the flip side of “packed together”: because the instances share nearby hardware, a hardware failure can affect several instances at once. Cluster placement groups optimise for speed, not resilience, and they stay within a single AZ.
Two practical notes AWS may test: use the same instance type and launch all instances in a single request for the best chance of success, and if you get an insufficient capacity error, stop and start all the instances in the group so AWS can re-place them together.
Spread Placement Groups: Isolate a Few Critical Instances
A spread placement group does the opposite of cluster: it places each instance on distinct underlying hardware — separate racks with independent power and network — so that no two instances share a rack. The goal is maximum fault isolation for a small number of critical instances that must not fail together.
The defining limit — and a favourite exam number — is that a spread placement group supports a maximum of seven running instances per Availability Zone. Because you can span multiple AZs, that’s seven per AZ, not seven total. Spread groups suit scenarios like:
- A small set of critical, standalone application servers.
- Instances that each hold a replica you never want on the same physical host.
If a scenario says “a small number of critical instances that must be kept on separate hardware,” that’s a spread placement group — and if it mentions more than seven per AZ, spread is disqualified.
Partition Placement Groups: Fault Domains for Large Distributed Systems
A partition placement group splits your instances into logical groups called partitions, where each partition runs on its own distinct set of racks (no two partitions share hardware). Within a partition, instances can share hardware, but a hardware failure in one partition cannot affect any other partition. This gives you fault domains at scale.
Key limits: up to seven partitions per Availability Zone, and a partition group can span multiple AZs in the same Region. Each partition can hold many instances, so partition groups scale far beyond spread’s seven-per-AZ ceiling.
Partition placement groups are designed for large distributed and replicated workloads that are already partition-aware:
- Apache Cassandra, HDFS/Hadoop, HBase, and Apache Kafka.
These systems replicate data across nodes, so aligning replicas with different partitions (and therefore different hardware) means a single rack failure loses at most one replica. AWS even exposes partition information through instance metadata, so topology-aware software can place replicas intelligently.
Placement Groups Compared
| Cluster | Spread | Partition | |
|---|---|---|---|
| Goal | Lowest latency, highest throughput | Maximum hardware isolation | Fault domains at scale |
| How it places | Packed on nearby hardware | Each instance on distinct hardware | Each partition on distinct racks |
| AZ span | Single AZ | Can span multiple AZs | Can span multiple AZs (same Region) |
| Size limit | Limited by AZ capacity | 7 running instances per AZ | 7 partitions per AZ (many instances each) |
| Best for | HPC, tightly-coupled compute | Small set of critical instances | Cassandra, HDFS, Kafka, HBase |
| Resilience | Low (shared hardware) | Highest (no shared hardware) | High (isolated partitions) |
Rules and Gotchas Worth Memorising
- A placement group name must be unique within your AWS account per Region.
- An instance can be in only one placement group at a time — you can’t put an instance in two groups.
- You cannot merge placement groups.
- Not every instance type supports every strategy; cluster in particular works best with modern, network-optimised types.
- Placement groups carry no additional charge.
Instance Tenancy: Who Shares the Physical Server
Tenancy is a separate dimension from placement groups. It answers a different question: does your instance share physical hardware with other AWS customers, or not? There are three options.
Shared Tenancy (the Default)
With shared (default) tenancy, your instances may run on the same physical hardware as instances from other AWS accounts. The hypervisor keeps every tenant strongly isolated — this is the normal, most cost-effective model and the right answer unless a scenario explicitly demands physical isolation or special licensing.
Dedicated Instances
Dedicated Instances run on hardware dedicated to a single AWS account — no other customer’s instances share that hardware. You get physical isolation at the account boundary, billed per instance. What you don’t get is visibility into or control over the underlying server: you can’t see sockets and physical cores, and you can’t guarantee an instance returns to the same host after a stop/start. Dedicated Instances suit compliance or regulatory requirements for physical isolation where you don’t need host-level control.
Dedicated Hosts
A Dedicated Host is an entire physical server allocated to you. This is the most control-heavy option and unlocks capabilities the others can’t:
- Visibility into the physical server — you can see the number of sockets and physical cores, which matters for licensing.
- Bring Your Own License (BYOL) for software licensed per socket, per core, or per VM — for example existing Windows Server or SQL Server licenses tied to physical hardware.
- Host affinity — pin an instance to the same host across stop/start cycles, which some licenses require.
- Control over instance placement on the host, and the ability to address strict compliance regimes.
Dedicated Hosts are billed per host (On-Demand or via a reservation), not per instance.
Dedicated Hosts vs Dedicated Instances: The Comparison That Matters
This is the single most confused pair in the topic, and the exam tests it directly. Both give you single-tenant hardware; the difference is control and licensing.
| Dedicated Instances | Dedicated Hosts | |
|---|---|---|
| Isolation | Hardware dedicated to your account | Entire physical server is yours |
| Billing | Per instance | Per host |
| See sockets / physical cores | No | Yes |
| BYOL per socket/core | Not supported | Supported |
| Host affinity / same-host placement | No | Yes |
| Control over placement on the host | No | Yes |
| Typical driver | Compliance needing physical isolation | Socket/core-bound licensing, tight compliance |
The clean rule: if the scenario is about existing per-socket or per-core software licensing (Windows Server, SQL Server) or needing to see and control the physical host, the answer is Dedicated Hosts. If it’s simply “isolate our instances from other AWS customers” with per-instance billing and no host-level requirement, the answer is Dedicated Instances. If neither isolation nor special licensing is mentioned, stay on shared (default) tenancy — it’s cheapest.
Placement Groups + Tenancy: The Exam Decision Table
| The scenario says… | The answer is… |
|---|---|
| ”Lowest node-to-node latency for HPC / tightly-coupled compute” | Cluster placement group |
| ”A small number of critical instances on separate hardware” | Spread placement group |
| ”More than 7 critical instances per AZ needing isolation” | Partition placement group (spread is disqualified) |
| “Large distributed system like Cassandra/HDFS/Kafka with fault domains” | Partition placement group |
| ”Maximise throughput between instances in one AZ” | Cluster placement group |
| ”Existing Windows/SQL Server BYOL tied to physical cores” | Dedicated Hosts |
| ”See the number of physical sockets and cores” | Dedicated Hosts |
| ”Keep an instance on the same physical host across restarts” | Dedicated Hosts (host affinity) |
| “Isolate our instances from other accounts, billed per instance” | Dedicated Instances |
| ”No isolation or licensing requirement, minimise cost” | Shared (default) tenancy |
Common SAA-C03 Mistakes
| Mistake | The correction |
|---|---|
| Treating placement groups and tenancy as one topic | They’re independent: placement controls layout; tenancy controls hardware sharing |
| Thinking a cluster group improves resilience | It reduces latency but increases correlated failure risk (shared hardware) |
| Forgetting the spread limit | 7 running instances per AZ — beyond that, use partition |
| Assuming Dedicated Instances allow socket/core BYOL | Only Dedicated Hosts expose sockets/cores and support per-core BYOL |
| Choosing Dedicated Hosts when only account isolation is needed | Dedicated Instances are simpler and per-instance billed |
| Putting an instance in two placement groups | An instance can be in only one at a time |
| Expecting cluster groups to span AZs | Cluster is single-AZ; spread and partition can span AZs |
Practice These Until They’re Reflexive
Placement and tenancy questions are pure pattern-matching once you know the mechanics: latency and throughput point to cluster, “a few critical instances” points to spread, big replicated data systems point to partition, and per-core licensing points to Dedicated Hosts. The way to make those matches automatic is to answer scenario questions until the strongest signal in a stem jumps out at you.
Sailor.sh’s AWS Certified Solutions Architect – Associate (SAA-C03) Mock Exam Bundle gives you exam-style EC2 placement and tenancy scenarios that mirror the real format and difficulty — including the spread-vs-partition and Dedicated-Hosts-vs-Dedicated-Instances traps covered here — with a detailed explanation on every question so a wrong answer becomes a lesson. Use the free concepts here to build the model; use timed mock exams to make the choice automatic.
To connect this to the wider compute and performance picture, read the deep dive on designing high-performing architectures for the SAA-C03, and for how placement affects failure isolation, see designing resilient architectures. Round out your prep with the SAA-C03 exam guide for 2026, a structured SAA-C03 study plan, the VPC concepts guide for the networking side of EC2, the AWS storage services decision guide, and cost-optimised architectures — where the cheaper-default-tenancy trade-off matters most.
Frequently Asked Questions
What is the difference between cluster, spread, and partition placement groups?
Cluster packs instances close together in one AZ for the lowest latency and highest throughput (best for HPC), at the cost of correlated failure risk. Spread places each instance on distinct hardware for maximum isolation, capped at 7 running instances per AZ (best for a few critical instances). Partition divides instances into up to 7 partitions per AZ, each on separate racks, giving fault domains for large distributed systems like Cassandra, HDFS, and Kafka.
How many instances can a spread placement group have?
A spread placement group supports a maximum of 7 running instances per Availability Zone. Because it can span multiple AZs, the total across a Region can be higher, but the per-AZ limit is 7. If you need more isolated instances than that, use a partition placement group.
What is the difference between Dedicated Hosts and Dedicated Instances?
Both run on single-tenant hardware, but Dedicated Hosts give you an entire physical server with visibility into sockets and physical cores, support per-socket/per-core BYOL (e.g. Windows Server, SQL Server), and offer host affinity — billed per host. Dedicated Instances simply isolate your instances from other AWS accounts, billed per instance, with no host-level visibility or control. Choose Dedicated Hosts for licensing and host control; choose Dedicated Instances for straightforward account-level isolation.
Do placement groups cost extra?
No. Placement groups themselves are free — you only pay for the EC2 instances and their normal associated resources. Tenancy is different: Dedicated Instances and especially Dedicated Hosts cost more than default shared tenancy.
Can an EC2 instance belong to more than one placement group?
No. An instance can be a member of only one placement group at a time, and you cannot merge placement groups. To change strategy, you generally move the instance to a different (or new) placement group while it’s stopped.
When should I use a partition placement group instead of spread?
Use partition for large, partition-aware distributed systems (Cassandra, HDFS, HBase, Kafka) that need fault domains and scale well beyond spread’s 7-instances-per-AZ limit. Use spread for a small number of critical, standalone instances that must each sit on separate hardware.