EC2 Placement Groups and Networking

Create all three EC2 placement group types and benchmark network throughput.

Introduction

30 Second Summary

When you run a fleet of servers, where they physically sit in the data center matters more than you might think. Servers on the same rack can talk to each other at blazing speeds, but if that rack fails, they all go down together.

In this project, you will create all three types of EC2 placement groups, verify enhanced networking on Nitro-based instances, explore ephemeral instance store volumes, and benchmark network throughput to see cluster placement in action.

What You'll Build

A multi-instance EC2 lab environment that demonstrates advanced placement, networking, and storage concepts tested on the SAA-C03 exam.

By the end of this project, you'll have:

  • Three functioning placement groups (cluster, spread, partition) with instances demonstrating each strategy's constraints and behaviors.
  • Verified enhanced networking (ENA) on Nitro-based instances and explored instance store ephemeral NVMe volumes on a c5d instance.
  • Network benchmark results comparing instance-to-instance throughput within a cluster placement group, with CloudWatch metrics confirming the measurements.
  • Secret Mission: Move a running instance between placement groups using the EC2 Console and observe the constraints firsthand.

Are there any prerequisites?

You need an active AWS account, an existing VPC with a public subnet and key pair (from Project 1), and comfort with SSH and basic Linux commands for the on-instance exercises.

Create Placement Groups

When you launch EC2 instances, AWS decides where to place them across its physical hardware. Placement groups let you override that decision by telling AWS exactly how to position your instances relative to each other.

In this step, you will create all three placement group types (cluster, spread, and partition) using the AWS Management Console. You will also check instance type capabilities to confirm the hardware features available on the instances you will use throughout this project.

In this step, get ready to:
  • Create cluster, spread, and partition placement groups.
  • Verify all three groups reach the available state and review their constraints.
  • Query instance type capabilities for c5.large and c5d.large.
Create cluster, spread, and partition placement groups

AWS supports three placement strategies, each optimizing for a different trade-off between performance and fault tolerance.

  • In the AWS Management Console, type EC2 in the top search bar and select EC2.
  • In the left sidebar, scroll down to Network & Security and click Placement Groups.
  • Click Create placement group.
  • Enter cluster-pg in the Name field.
  • For Placement strategy, select Cluster.
  • Click Create group.
  • You should see a success banner confirming the cluster placement group was created.
  • Click Create placement group again to create the second group.
  • Enter spread-pg in the Name field.
  • For Placement strategy, select Spread.
  • Click Create group.
  • Click Create placement group one more time for the third group.
  • Enter partition-pg in the Name field.
  • For Placement strategy, select Partition.
  • Set Number of partitions to 3.
  • Click Create group.
  • Back on the Placement Groups list page, confirm all three groups appear: cluster-pg, spread-pg, and partition-pg.
  • Each group should show State as Available and display its correct strategy.

Getting an error when creating the group?

If you see an error about a duplicate name, a placement group with that name already exists in your account. Check the Placement Groups list for an existing group with the same name and delete it first, or choose a different name.

If you do not see the Placement Groups option in the left sidebar, make sure you are in the EC2 service (not VPC or another service). It is under Network & Security.

Help me troubleshoot my placement group creation error in the Console.

Review placement group strategies and exam constraints

Each placement group strategy has strict rules that are frequently tested on the SAA-C03. Understanding these constraints now will help you predict instance behavior in later steps.

  • On the Placement Groups page, click the name of each group to view its details.
  • Note the Strategy and State columns in the list view.

What should I see?

The Placement Groups list shows each group's name, strategy, state, and partition count (for partition groups). You should see three rows: cluster-pg with strategy Cluster, spread-pg with strategy Spread, and partition-pg with strategy Partition and 3 partitions.

  • Confirm cluster-pg shows strategy Cluster, spread-pg shows Spread, and partition-pg shows Partition with 3 partitions.

What are the key exam facts for each strategy?

  • Cluster = single Availability Zone, same high-bisection bandwidth segment. Cannot span multiple AZs. Best for low-latency, high-throughput workloads (HPC, machine learning).
  • Spread = maximum of 7 running instances per AZ per group, each on a distinct rack. Maximizes fault isolation. Best for small groups of critical instances.
  • Partition = up to 7 partitions per AZ, each on a separate rack. Instances in different partitions never share hardware. Best for distributed workloads like Hadoop, Cassandra, and Kafka.
Query instance type capabilities

Before launching instances in the next step, you need to confirm which hardware features your chosen instance types support. This helps you verify ENA (Enhanced Networking Adapter) availability and whether a type includes instance store volumes.

  • In the EC2 left sidebar, click Instance Types (under Instances).
  • In the search/filter bar at the top, type c5.large and press Enter.
  • Click the c5.large row to expand its details.
  • Select the Networking tab and note the ENA Support field (it should say Required).
  • Select the Storage tab and note that Instance store supported is No (EBS-only).
  • Clear the filter, then type c5d.large and press Enter.
  • Click the c5d.large row, check the Networking tab (ENA Required) and the Storage tab (instance store Yes, NVMe SSD).

What do these details tell me?

The Networking tab shows whether the Elastic Network Adapter is Required, Supported, or Unsupported. The Storage tab shows whether local instance store volumes are included with the instance type.

You should confirm that c5.large has ENA Required and no instance store (EBS-only). The c5d.large has ENA Required and includes NVMe SSD instance store.

  • Verify your findings: c5.large shows ENA Required with no instance store, and c5d.large shows ENA Required with NVMe instance store available.

Why do c5 instances require ENA?

C5 instances are built on the Nitro system, which uses ENA as the only networking interface. Older instance families (like t2) use the traditional Xen networking stack. The required value means you cannot launch this instance type without an ENA-compatible AMI.

The d in c5d stands for local NVMe storage. This is a physically attached SSD that provides extremely high IOPS but does not persist when you stop the instance.

🙋‍♀️ Not seeing c5.large or c5d.large in the list?

Your current region may not support these instance types. Check the region selector in the top-right corner of the Console. Switch to us-east-1 (N. Virginia) which supports all C5 variants.

If the Instance Types page shows too many results, use the filter bar and type the exact instance type name (e.g. c5.large) to narrow results.

Help me find instance type details in the EC2 Console.

Your three placement groups are ready and you know exactly what hardware features your instances support. Next up, you will launch instances into these groups and verify enhanced networking in action.

Launch Instances and Verify ENA

In the previous step, you created three placement groups to organize your instances. Now it is time to launch actual EC2 instances into those groups and see how Enhanced Networking works on Nitro-based hardware.

The c5.large instance type is built on the Nitro system, which means ENA (Elastic Network Adapter) is required and enabled by default. You will verify this both through the EC2 Console and at the OS level inside the instance.

In this step, get ready to:
  • Launch two c5.large instances into the cluster placement group and verify ENA.
  • Query EFA-supported instance types for exam reference.
  • Launch instances into the spread and partition placement groups.
Launch two instances into the cluster placement group

Cluster placement groups pack instances together in the same Availability Zone on the same high-bisection bandwidth network segment. You will launch two c5.large instances here to later benchmark their network throughput.

  • In the EC2 left sidebar, click Instances.
  • Click Launch instances.
  • In the Name field, enter Cluster-1.
  • Under Application and OS Images, keep the default Amazon Linux 2023 AMI selected.
  • Under Instance type, search for and select c5.large.
  • Under Key pair, select your existing key pair from Project 1.
  • Click Edit next to Network settings.
  • Select your existing VPC and public subnet from Project 1.
  • Set Auto-assign public IP to Enable.
  • Select your existing security group that allows SSH inbound (port 22).
  • Expand the Advanced details section at the bottom.
  • Scroll down to Placement group and select cluster-pg from the dropdown.
  • Click Launch instance.
  • You should see a success message. Click View all instances to return to the instances list.
  • Now launch the second cluster instance. Click Launch instances again.
  • Enter Cluster-2 in the Name field.
  • Use the same settings: Amazon Linux 2023, c5.large, same key pair, same VPC/subnet/security group, Auto-assign public IP enabled.
  • Under Advanced details, select cluster-pg for the Placement group.
  • Click Launch instance.
  • Wait 30-60 seconds, then click the refresh icon at the top of the instances list.
  • Both instances should transition from pending to running.
  • Confirm both Cluster-1 and Cluster-2 show the same Availability Zone in the table. This is enforced by the cluster placement group.

Instances stuck in pending?

If your instances stay in pending for more than a minute, click the refresh icon again. It typically takes 30-60 seconds for c5.large instances to transition to running. If an instance fails to launch, you may have hit capacity constraints for the cluster placement group. Try terminating and relaunching, choosing a different subnet (and therefore a different Availability Zone).

Help me troubleshoot my EC2 instance launch into a cluster placement group.

Verify ENA and explore EFA-supported types

All C5 instances are Nitro-based, which means ENA is not optional. It is the required network driver. You will now confirm this at two levels: the EC2 Console and the Linux kernel inside the instance.

  • In the Instances list, select the checkbox next to Cluster-1.
  • Click the Networking tab in the details panel below.
  • Scroll down to the Network interfaces section and look for the Interface type field. It should show ENA.
  • Repeat for Cluster-2 to confirm both instances have ENA enabled.

What should I see?

The Networking tab shows that the interface type is ENA (Elastic Network Adapter). On Nitro-based instances like c5.large, ENA is required and always enabled. This is a key SAA-C03 exam fact.

  • Now SSH into Cluster-1 to verify the ENA driver at the OS level.
  • Select Cluster-1 in the Instances list and click the Details tab.
  • Copy the Public IPv4 address value.
  • Open a terminal on your local machine and SSH into the instance using the IP you just copied:
ssh -i [[PEMPATH="path/to/your-key.pem"]] ec2-user@[[CLUSTER1_IP="public-ip-of-cluster-1"]]
  • Once connected, confirm the network driver is ENA by running:
ethtool -i ens5

What does this output mean?

The driver: field should show ena. This confirms that the Elastic Network Adapter driver is loaded and active at the kernel level. The ens5 interface is the primary network interface on Nitro-based instances.

  • Exit the SSH session by running:
exit
  • For exam preparation, check which instance types support EFA (Elastic Fabric Adapter).
  • In the EC2 left sidebar, click Instance Types (under Instances).
  • Click Add filter, select EFA supported, and set the value to true.
  • The list now shows only instance types that support EFA. Note that these are large, expensive types like c5n.18xlarge.

What is EFA?

Elastic Fabric Adapter uses OS-bypass and the Scalable Reliable Datagram (SRD) protocol for low-latency, high-throughput communication. It is designed for HPC workloads like molecular simulations and distributed machine learning.

EFA-supported types include large instances like c5n.18xlarge. These are extremely expensive, so you will not launch one in this lab. Knowing which types support EFA is enough for the SAA-C03 exam.

Launch instances into spread and partition placement groups

With your cluster instances running, you will now place one instance into each of the other two placement group types. This demonstrates how the Console options differ for spread versus partition groups.

  • Click Launch instances to start a new instance.
  • Enter Spread-1 in the Name field.
  • Use the same settings as before: Amazon Linux 2023, c5.large, same key pair, same VPC/subnet/security group, Auto-assign public IP enabled.
  • Under Advanced details, select spread-pg for the Placement group.
  • Click Launch instance.

How is the spread group different?

Each instance in a spread placement group runs on a distinct physical rack. This maximizes fault tolerance. The trade-off is that you can have a maximum of seven running instances per Availability Zone per group.

  • Click Launch instances one more time.
  • Enter Partition-1 in the Name field.
  • Use the same settings: Amazon Linux 2023, c5.large, same key pair, same VPC/subnet/security group, Auto-assign public IP enabled.
  • Under Advanced details, select partition-pg for the Placement group.
  • In the Target partition dropdown that appears, select 2.
  • Click Launch instance.

What does the Target partition field do?

The Target partition dropdown tells EC2 to place this instance specifically in partition 2 of your partition group. Each partition runs on a separate rack. This is the pattern used for distributed systems like Hadoop, Cassandra, and Kafka where you want data replicas on physically isolated hardware.

  • Click View all instances to return to the instances list.
  • Refresh the page and verify all four instances (Cluster-1, Cluster-2, Spread-1, Partition-1) show the running state.
  • To confirm placement group membership, select each instance and check the Details tab.
  • The Placement group field shows which group the instance belongs to.
  • For Partition-1, the Partition number field should show 2.

Spread instance failing to launch?

Spread placement groups enforce a limit of seven running instances per AZ per group. If you get an insufficient capacity error, verify you do not already have seven instances in that AZ for this group. Also confirm that your security group allows SSH inbound (port 22) from your IP.

help me fix my spread placement group instance launch failure

You now have four instances distributed across all three placement group strategies. In the next step, you will launch a c5d.large instance to explore ephemeral NVMe instance store volumes.

Explore Instance Store Volumes

In Step 2, you launched instances into all three placement group types and confirmed enhanced networking is active on your Nitro-based instances.

Now you will launch a c5d.large instance to explore a completely different kind of storage. Unlike EBS volumes that persist independently of your instance, instance store volumes are physically attached NVMe SSDs that live and die with the instance. Understanding when data disappears is one of the most frequently tested SAA-C03 topics.

In this step, get ready to:
  • Launch a c5d.large instance with an NVMe instance store volume into your cluster placement group.
  • Format, mount, and write data to the ephemeral instance store.
  • Compare instance store vs EBS trade-offs for the exam.
Launch a c5d.large instance into the cluster placement group

The c5d.large instance type is identical to the c5.large you already launched, except it includes NVMe-based local SSD storage. For instance types with NVMe instance store volumes, all supported volumes are automatically attached at launch.

  • In the EC2 Console, click Launch instances.
  • Enter InstanceStore-1 in the Name field.
  • Under Instance type, search for and select c5d.large.
  • Use the same settings: Amazon Linux 2023, same key pair, same VPC/subnet/security group, Auto-assign public IP enabled.
  • Under Advanced details, select cluster-pg for the Placement group.
  • Click Launch instance.

Why c5d instead of c5?

The c5d family includes NVMe instance store volumes that are automatically attached at launch. You cannot attach instance store volumes after an instance is running. The d suffix is how AWS indicates local storage is included.

  • Click View all instances to return to the instances list.
  • Wait 30-60 seconds and click the refresh icon until InstanceStore-1 shows the running state.
  • Select the InstanceStore-1 instance by clicking its checkbox.
  • In the Details tab at the bottom of the page, find the Public IPv4 address field.
  • Copy the public IP address.
  • SSH into the new instance by running:
ssh -i [[PEMPATH="path to your .pem key file"]] ec2-user@[[INSTANCE_STORE_IP="public IP of InstanceStore-1"]]
  • Once connected, identify the instance store volume by running:
lsblk
  • You should see two NVMe devices in the output. nvme0n1 is your root EBS volume (8 GB with partitions). nvme1n1 is your instance store volume (approximately 46.6 GB) with no mount point.

Only seeing one NVMe device?

If you only see nvme0n1 in the lsblk output, confirm that you launched a c5d.large (with the d) and not a c5.large. The d suffix indicates local NVMe storage is included.

Help me troubleshoot why my c5d instance is not showing an instance store volume in lsblk

Format and mount the instance store volume

The instance store volume arrives raw and unformatted. Before you can write files to it, you need to create a filesystem and mount it to a directory.

  • Format the instance store volume as XFS by running:
sudo mkfs.xfs /dev/nvme1n1
  • Create a mount point directory and mount the volume by running:
sudo mkdir /mnt/instance-store
sudo mount /dev/nvme1n1 /mnt/instance-store
  • Write a test file and verify it exists by running:
sudo sh -c 'echo "Instance store is working" > /mnt/instance-store/test.txt'
cat /mnt/instance-store/test.txt
  • You should see Instance store is working printed in your terminal. This confirms the volume is formatted, mounted, and writable.

What are the instance store persistence rules?

This is one of the most heavily tested SAA-C03 topics. Data on an instance store volume persists when the instance is rebooted.

Data does NOT persist when the instance is stopped, hibernated, or terminated. Every block on the volume is cryptographically erased when the instance stops or terminates.

Instance store volumes can only be attached at launch. You cannot attach one to a running instance after the fact.

🙋‍♀️ Seeing a permission denied error?

Make sure you include sudo before each command. The /mnt directory requires root permissions to create subdirectories and write files.

Help me fix permission errors when mounting my instance store volume

Compare instance store with EBS

Now that you have both storage types on one instance, you can see exactly how they differ. Understanding these trade-offs is essential for SAA-C03 questions about storage selection.

  • Run lsblk again to see both volumes side by side:
lsblk
  • You should now see nvme0n1 (your root EBS volume with partitions and a mount point at /) and nvme1n1 (your instance store volume mounted at /mnt/instance-store).
  • Exit the SSH session by running:
exit
  • Back in the EC2 console, click Instance types in the left sidebar.
  • Search for c5d.large in the search bar and select it.
  • Click the Storage tab.
  • You should see the Instance Storage (GB) total size, disk count, disk type (NVMe SSD), and encryption support listed for c5d.large.

What are the EBS vs instance store exam trade-offs?

Instance store gives you high IOPS, no extra cost (included in the instance price), and extremely low latency. The trade-off is zero persistence. If the instance stops or terminates, your data is gone.

EBS is persistent, detachable, and snapshotable. You can stop an instance and your EBS data survives. You can detach a volume and reattach it to a different instance. The trade-off is additional cost and slightly higher latency over the network.

On the exam, instance store is the answer for temporary data like caches, buffers, and scratch data. EBS is the answer when data must survive instance lifecycle events.

You now have a hands-on understanding of how instance store volumes work. Next up, you will benchmark network throughput between your cluster placement group instances using iperf3 to see enhanced networking performance in action.

Benchmark Network Throughput with iperf3

You now have instances spread across all three placement group types. The big question for the SAA-C03 exam is: do cluster placement groups actually deliver better network performance? Time to find out with real numbers.

In this step, you will install iperf3 on your two cluster instances and run a network throughput benchmark between them. Then you will observe the corresponding traffic spike in CloudWatch metrics.

In this step, get ready to:
  • Install iperf3 on Cluster-1 and Cluster-2.
  • Run a 30-second network throughput benchmark with 4 parallel streams.
  • Observe CloudWatch NetworkIn/NetworkOut metrics for the benchmark traffic spike.
Install iperf3 and run the benchmark

iperf3 is a standard network testing tool that measures throughput between two endpoints. One instance acts as a server (listener), and the other acts as a client that pushes traffic toward it.

  • SSH into your Cluster-1 instance and install iperf3 by running this command:
sudo dnf install -y iperf3
  • Start the iperf3 server on Cluster-1 by running:
iperf3 -s

What does this command do?

The -s flag tells iperf3 to run in server mode. It listens on port 5201 by default, waiting for a client to connect and send test traffic.

Cluster-1 is now listening. Leave that SSH session open and switch to Cluster-2.

  • Open a new terminal window or tab and SSH into your Cluster-2 instance.
  • Install iperf3 on Cluster-2 by running:
sudo dnf install -y iperf3
  • Run the iperf3 client, connecting to Cluster-1's private IP address:
iperf3 -c [[CLUSTER1_PRIVATE_IP="Cluster-1 private IPv4 address"]] -t 30 -P 4

What does this command do?

The -c flag runs iperf3 in client mode, connecting to the server at the private IP you provide. -t 30 runs the test for 30 seconds. -P 4 uses 4 parallel streams to maximize throughput.

Use the private IP (not the public one) because both instances are in the same VPC. Traffic stays inside the AWS network.

💡 Find the private IP quickly

You can find Cluster-1's private IP in the EC2 console under the instance's Details tab, in the Private IPv4 address field. Alternatively, run aws ec2 describe-instances and look for the PrivateIpAddress value.

The test runs for 30 seconds. You will see interval reports every second, followed by a summary showing aggregate throughput across all 4 streams.

Connection refused or timeout?

If you see a connection error, your security group may not allow traffic on port 5201 between instances. Add an inbound rule to your security group allowing TCP port 5201 from the security group's own ID (self-referencing rule).

Also confirm iperf3 is still running on Cluster-1. If you accidentally closed that terminal, SSH back in and run iperf3 -s again.

Help me troubleshoot my iperf3 connection between EC2 instances in a cluster placement group.

Interpret the benchmark results

Once the 30-second test finishes, iperf3 displays a summary. Look at the last few lines showing the aggregate sender and receiver throughput across all 4 streams.

What throughput should I expect?

The c5.large instance type has a baseline bandwidth of 0.75 Gbps and can burst up to 10 Gbps. Instances with 16 vCPUs or fewer can burst beyond their baseline using network I/O credits for 5 to 60 minutes.

The cluster placement group places both instances on the same high-bisection bandwidth segment. This enables higher single-flow throughput compared to instances placed randomly across the AZ. Your results will vary based on burst credit availability and concurrent activity.

  • Note down the aggregate throughput from the iperf3 summary line (the "SUM" row at the bottom of the output).
  • Stop the iperf3 server on Cluster-1 by pressing Ctrl+C in that SSH session.

Why does cluster placement boost throughput?

Cluster placement groups pack instances onto the same underlying rack segment with high-bisection bandwidth interconnects. Network packets travel fewer hops between instances, reducing latency and increasing achievable throughput.

This is why cluster placement groups cannot span multiple Availability Zones. The physical proximity that delivers performance gains requires instances to share the same rack infrastructure within a single AZ.

Observe CloudWatch network metrics

CloudWatch captures network traffic metrics for every EC2 instance automatically. The iperf3 benchmark pushed significant traffic through both instances, so you should see a clear spike in the metrics.

  • In the AWS Management Console, navigate to the CloudWatch service.
  • In the left sidebar, click Metrics, then All metrics.
  • Click EC2, then Per-Instance Metrics.
  • Search for your Cluster-1 instance ID.
  • Select the checkboxes for NetworkIn and NetworkOut.
  • Repeat for Cluster-2's instance ID.

You should see a traffic spike on the graph corresponding to the time you ran the iperf3 test. Cluster-1 shows high NetworkIn (it received the traffic). Cluster-2 shows high NetworkOut (it sent the traffic).

How does CloudWatch report network metrics?

CloudWatch reports NetworkIn and NetworkOut in bytes, not bits. To compare with iperf3 output (which reports in Gbps), you need to convert: multiply bytes by 8 to get bits, then divide by the interval duration in seconds.

With basic monitoring, CloudWatch collects data at 5-minute granularity. Your 30-second iperf3 burst is averaged across a 5-minute window, so the peak shown on the graph will appear lower than the actual throughput during those 30 seconds.

🙋‍♀️ Don't see the traffic spike yet?

CloudWatch basic monitoring has a 5-minute collection interval. If you just finished the benchmark, wait 5-10 minutes for the data point to appear. Refresh the metrics graph after waiting.

Also confirm you are looking at the correct instance IDs. The instance ID shown in the EC2 console must match the one selected in CloudWatch.

Help me find my EC2 network metrics in CloudWatch after running an iperf3 benchmark.

You have now measured real network throughput between instances in a cluster placement group and confirmed the results in CloudWatch. Next up, you will clean up all resources to stop incurring charges.

Clean Up Resources

You've successfully benchmarked network throughput between cluster placement group instances and observed the results in CloudWatch.

Now it's time to clean up all resources to stop incurring charges. The c5.large and c5d.large instances cost $0.085-$0.096 per hour each, so leaving them running would add up quickly.

In this step, get ready to:
  • Terminate all five EC2 instances across the three placement groups.
  • Delete all three placement groups once empty.
  • Verify no lingering resources remain in the console.
Terminate all five instances

Before you can delete placement groups, all instances inside them must be terminated first. You'll terminate all five instances in a single command.

  • First, gather all five instance IDs. Run this command to list your running instances:
aws ec2 describe-instances --filters "Name=instance-state-name,Values=running" --query "Reservations[].Instances[].[InstanceId, Tags[?Key=='Name'].Value | [0]]" --output table

What does this command do?

This queries all running instances and displays their instance IDs alongside their Name tags. You'll need the five instance IDs (for Cluster-1, Cluster-2, InstanceStore-1, Spread-1, and Partition-1) to terminate them.

  • Copy the five instance IDs from the output.
  • Terminate all five instances by running this command with your instance IDs:
aws ec2 terminate-instances --instance-ids [[INSTANCE_ID_1="your Cluster-1 instance ID"]] [[INSTANCE_ID_2="your Cluster-2 instance ID"]] [[INSTANCE_ID_3="your InstanceStore-1 instance ID"]] [[INSTANCE_ID_4="your Spread-1 instance ID"]] [[INSTANCE_ID_5="your Partition-1 instance ID"]]

What does this command do?

The aws ec2 terminate-instances command sends a termination request to all listed instances. Each instance will transition through shutting-down to terminated state.

The root EBS volumes will be deleted automatically because DeleteOnTermination defaults to true for root volumes. The instance store on InstanceStore-1 is already ephemeral and disappears immediately.

  • Wait for all instances to reach the terminated state by running:
aws ec2 wait instance-terminated --instance-ids [[INSTANCE_ID_1="your Cluster-1 instance ID"]] [[INSTANCE_ID_2="your Cluster-2 instance ID"]] [[INSTANCE_ID_3="your InstanceStore-1 instance ID"]] [[INSTANCE_ID_4="your Spread-1 instance ID"]] [[INSTANCE_ID_5="your Partition-1 instance ID"]]

What does this command do?

The wait instance-terminated command pauses your terminal until every listed instance has reached the terminated state. This ensures the placement groups are empty before you try to delete them.

  • Once the command completes (it returns with no output), confirm the instances are terminated by running:
aws ec2 describe-instances --instance-ids [[INSTANCE_ID_1="your Cluster-1 instance ID"]] [[INSTANCE_ID_2="your Cluster-2 instance ID"]] [[INSTANCE_ID_3="your InstanceStore-1 instance ID"]] [[INSTANCE_ID_4="your Spread-1 instance ID"]] [[INSTANCE_ID_5="your Partition-1 instance ID"]] --query "Reservations[].Instances[].[Tags[?Key=='Name'].Value | [0], State.Name]" --output table

You should see all five instances listed with the state terminated.

Instances still showing as shutting-down?

Termination can take a minute or two. Run the wait instance-terminated command again and it will block until all instances finish terminating.

If an instance appears stuck, check whether it has termination protection enabled in the console under Instance Settings > Change Termination Protection.

Help me troubleshoot why my EC2 instances are not terminating.

Delete all three placement groups

Placement groups cannot be deleted while they contain running instances. Now that all instances are terminated, you can safely remove the groups.

  • Delete the cluster placement group by running:
aws ec2 delete-placement-group --group-name cluster-pg
  • Delete the spread placement group by running:
aws ec2 delete-placement-group --group-name spread-pg
  • Delete the partition placement group by running:
aws ec2 delete-placement-group --group-name partition-pg
  • Verify all placement groups are deleted by running:
aws ec2 describe-placement-groups

You should see an empty PlacementGroups array in the output, confirming all three groups are gone.

Seeing an InvalidPlacementGroup.InUse error?

This means an instance in the group has not fully terminated yet. Run aws ec2 wait instance-terminated again with your instance IDs, then retry the delete command.

Help me fix the InvalidPlacementGroup.InUse error when deleting my placement group.

Verify no lingering resources in the console

As a final check, confirm visually that no running instances or orphaned EBS volumes remain in your account.

  • In the AWS Management Console, navigate to EC2 > Instances.
  • Confirm no instances show a running or stopped state. All five should show terminated.
  • Navigate to EC2 > Elastic Block Store > Volumes.
  • Confirm no unexpected volumes remain in the available state. Root volumes should have been deleted automatically with their instances because DeleteOnTermination is set to true by default.

Why check for orphaned EBS volumes?

EBS volumes cost approximately $0.08 per GB per month. If a root volume somehow had DeleteOnTermination set to false, it would persist after termination and silently accrue charges. Always verify after cleanup.

🙋‍♀️ See an orphaned volume in the available state?

Select the volume, click Actions > Delete volume to remove it. Check the volume's tags or creation time to confirm it belongs to this project before deleting.

Help me identify and delete orphaned EBS volumes in my account.

Secret mission

Move an Instance Between Placement Groups

On the SAA-C03 exam, you will be asked about moving instances between placement groups. Can you stop a cluster instance, relocate it to the spread group, and discover what happens when you try to move a running instance? This exercise cements the movement rules that appear on exam day.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses c5.large and c5d.large instances billed at $0.085-$0.096/hr each, so leaving them running will accumulate charges.

Cost warning

You have five EC2 instances that cost $0.085-$0.096 per hour each. If all five run for an additional hour, that is roughly $0.45-$0.48 in charges. Terminate them promptly to avoid unnecessary spend.

Resources you used:

  • EC2 instances: Cluster-1, Cluster-2, InstanceStore-1, Spread-1, Partition-1 (c5.large and c5d.large, billed per second while running).
  • Placement groups: cluster-pg, spread-pg, partition-pg (no cost, but should be deleted to clean up).
  • EBS root volumes: attached to each instance, automatically deleted on termination by default.

Keep everything running

No action needed. Choose this if you are still actively experimenting with placement groups or plan to continue benchmarking within the next hour.

  • Your five instances will continue incurring charges at $0.085-$0.096/hr each.
  • Placement groups have no ongoing cost.
  • Remember to come back and terminate everything when you are done.

Pause - I'll come back to this later

Stop all instances to halt compute charges. EBS root volumes will still incur storage charges at approximately $0.08/GB-month, but compute billing stops immediately.

  • In your terminal, stop all running instances by running:
aws ec2 stop-instances --instance-ids $(aws ec2 describe-instances --filters "Name=instance-state-name,Values=running" "Name=instance-type,Values=c5.large,c5d.large" --query "Reservations[].Instances[].InstanceId" --output text)
  • Verify all instances show stopped state by running:
aws ec2 describe-instances --filters "Name=instance-type,Values=c5.large,c5d.large" --query "Reservations[].Instances[].[Tags[?Key=='Name'].Value | [0], State.Name]" --output table

What about instance store data?

Stopping the c5d.large instance (InstanceStore-1) will permanently erase all data on the instance store volume at /mnt/instance-store. Instance store data does not persist when an instance is stopped. The EBS root volume data is preserved.

Delete - I don't want to use this again

Remove all project resources to stop all charges. This is the recommended option once you have finished the project.

  • Terminate all five instances by running:
aws ec2 terminate-instances --instance-ids $(aws ec2 describe-instances --filters "Name=instance-type,Values=c5.large,c5d.large" "Name=instance-state-name,Values=running,stopped" --query "Reservations[].Instances[].InstanceId" --output text)
  • Wait for all instances to reach the terminated state. This typically takes 1-2 minutes. Confirm by running:
aws ec2 describe-instances --filters "Name=instance-type,Values=c5.large,c5d.large" --query "Reservations[].Instances[].[Tags[?Key=='Name'].Value | [0], State.Name]" --output table
  • Once all instances are terminated, delete each placement group by running:
aws ec2 delete-placement-group --group-name cluster-pg
aws ec2 delete-placement-group --group-name spread-pg
aws ec2 delete-placement-group --group-name partition-pg
  • Verify all placement groups are deleted by running:
aws ec2 describe-placement-groups

This should return an empty list. If any group still appears, an instance in that group has not fully terminated yet. Wait another minute and retry the delete command.

What about EBS volumes?

The EBS root volumes attached to each instance are configured with DeleteOnTermination=true by default. They are automatically deleted when the instance terminates. No manual volume cleanup is needed.

Nice Work!

Nice Work!

You just built a multi-instance lab environment that demonstrates advanced EC2 placement, networking, and storage concepts tested on the SAA-C03 exam. You now have hands-on experience with every placement group type, enhanced networking verification, instance store behavior, and network benchmarking.

Here's what you learned:

  • Created and configured all three EC2 placement group types (cluster, spread, partition) and verified their constraints, including spread's 7-instance-per-AZ limit and cluster's single-AZ restriction.
  • Verified enhanced networking (ENA) on Nitro-based instances using ethtool and the AWS CLI, and explored ephemeral NVMe instance store volumes on a c5d.large including formatting, mounting, and understanding persistence rules versus EBS.
  • Benchmarked network throughput with iperf3 between instances in a cluster placement group and observed corresponding CloudWatch NetworkIn/NetworkOut metrics confirming the traffic spike.
  • Secret Mission: Moved an instance between placement groups using modify-instance-placement, observed stop-state requirements, and documented exam-critical movement rules.

Ready to quiz yourself?