Explore EC2 Enhanced Networking

Create and manage ENIs, verify ENA, and build all three placement group types.

Introduction

30 Second Summary

When you stream a movie or make a video call, data travels through network cards that connect your device to the internet. In the cloud, virtual machines use virtual network cards too. The faster and smarter those cards are, the better your applications perform.

In this project, you will explore the full hierarchy of EC2 networking features by creating network interfaces, verifying enhanced networking, and building placement groups. You will come away with hands-on experience for every networking concept tested on the AWS Solutions Architect Associate (SAA-C03) exam.

What You'll Build

A hands-on exploration of AWS EC2 networking features through the Console, covering ENI failover, Enhanced Networking verification, ENA Express settings, and Placement Groups for instance placement strategies.

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

A secondary ENI created, attached, detached, and reattached between EC2 instances to demonstrate failover.
Verified ENA enhanced networking on a Nitro-based instance, with ENA Express settings explored in the Console.
All three placement group types (Cluster, Spread, Partition) created with instances launched into each.
Secret Mission: Design architecture recommendations matching the right networking and placement group strategy to real-world workload scenarios.

Are there any prerequisites?

You need an AWS account with free tier access and basic familiarity with launching EC2 instances. All work is done in the AWS Management Console. No CLI usage is required.

Launch Your Base Environment

Before you can explore EC2 networking features, you need a controlled environment to work in.

In this step, you will create a VPC with a public subnet, then launch two EC2 instances that you will use throughout the rest of the project to test networking features like ENI failover and placement groups.

In this step, get ready to:

Create a VPC and public subnet with an Internet Gateway.
Launch two t3.micro instances in the same Availability Zone.
Verify both instances are running and note the Availability Zone.

Create a VPC and subnet

A VPC (Virtual Private Cloud) is your own isolated network within AWS.

You will create one with a public subnet so your instances can reach the internet and you can SSH into them later.

Sign in to the AWS Management Console.
In the search bar at the top, type VPC and select VPC from the results.
Click Create VPC.
Under Resources to create, select VPC only.
In the Name tag field, enter NetworkingLab-VPC.
In the IPv4 CIDR block field, enter 10.0.0.0/16.
Leave all other settings at their defaults and click Create VPC.

You should see a green success banner confirming your VPC was created.

Now create a public subnet inside this VPC.

In the left sidebar, click Subnets.
Click Create subnet.
In the VPC ID dropdown, select NetworkingLab-VPC.
In the Subnet name field, enter NetworkingLab-Public-Subnet.
Select any Availability Zone from the dropdown (for example, us-east-1a). Note this value down because you will need it later.
In the IPv4 subnet CIDR block field, enter 10.0.1.0/24.
Click Create subnet.

Next, enable auto-assign public IPv4 on this subnet so instances receive public IP addresses automatically.

Select the checkbox next to NetworkingLab-Public-Subnet.
Click Actions, then select Edit subnet settings.
Check the box for Enable auto-assign public IPv4 address.
Click Save.

Now create and attach an Internet Gateway so traffic can reach the internet.

In the left sidebar, click Internet gateways.
Click Create internet gateway.
In the Name tag field, enter NetworkingLab-IGW.
Click Create internet gateway.
On the next screen, click Actions, then select Attach to VPC.
Select NetworkingLab-VPC from the dropdown and click Attach internet gateway.

Finally, update the route table so your subnet routes internet-bound traffic through the Internet Gateway.

In the left sidebar, click Route tables.
Select the route table associated with NetworkingLab-VPC (it was created automatically with the VPC).
Click the Routes tab at the bottom of the page.
Click Edit routes.
Click Add route.
In the Destination field, enter 0.0.0.0/0.
In the Target dropdown, select Internet Gateway, then select NetworkingLab-IGW.
Click Save changes.

What is an Internet Gateway?

An Internet Gateway is the bridge between your VPC and the public internet. Without it, your instances would be completely isolated from the outside world.

The route table entry 0.0.0.0/0 means "all internet-bound traffic." By pointing it at the Internet Gateway, you are telling AWS to send any traffic destined for the internet through that gateway.

Don't see your VPC in the dropdown?

Make sure you are in the same AWS Region where you created the VPC. Check the region selector in the top-right corner of the Console.

help me find my VPC in the AWS Console

Launch two t3.micro instances

Now you will launch two EC2 instances inside your public subnet. These instances will serve as your testing environment for ENI attachment, enhanced networking verification, and placement groups.

In the search bar at the top, type EC2 and select EC2 from the results.
Click Launch instance.
In the Name field, enter NetworkingLab-Instance1.
Under Application and OS Images, confirm that Amazon Linux 2023 AMI is selected (it is the default).
Under Instance type, select t3.micro (free tier eligible).
Under Key pair, select an existing key pair or click Create new key pair and name it NetworkingLab-Key. Save the file when prompted.

Now configure the network settings to place this instance in your VPC.

Under Network settings, click Edit.
In the VPC dropdown, select NetworkingLab-VPC.
In the Subnet dropdown, select NetworkingLab-Public-Subnet.
Confirm that Auto-assign public IP is set to Enable.
Under Firewall (security groups), select Create security group.
In the Security group name field, enter NetworkingLab-SG.
Confirm the inbound rule allows SSH (port 22) with Source type set to My IP.
Leave all other settings at their defaults and click Launch instance.

You should see a success message confirming Instance1 is launching. Now launch the second instance.

Click Launch instance again from the EC2 dashboard.
In the Name field, enter NetworkingLab-Instance2.
Select Amazon Linux 2023 AMI and instance type t3.micro.
Select the same key pair you used for Instance1 (NetworkingLab-Key).
Under Network settings, click Edit.
Select NetworkingLab-VPC as the VPC and NetworkingLab-Public-Subnet as the subnet.
Under Firewall (security groups), select Select existing security group.
Choose NetworkingLab-SG from the list.
Click Launch instance.

Why the same subnet?

Both instances must be in the same subnet (and therefore the same Availability Zone) because ENI attachments only work within a single AZ. An ENI cannot be moved to a different subnet or a different AZ after creation.

Verify both instances are running

In the left sidebar, click Instances.
Wait until both NetworkingLab-Instance1 and NetworkingLab-Instance2 show Running in the Instance state column. This typically takes 30-60 seconds.
Click on NetworkingLab-Instance1 to open its details.
In the Details tab, find the Availability Zone field. Note this value down (for example, us-east-1a). You will need it when creating your ENI in the next step.
Confirm that both instances show 2/2 checks passed in the Status check column. This may take 1-2 minutes to complete.

Instances stuck in Pending?

If your instances stay in Pending for more than 2 minutes, click the refresh icon in the top-right of the instances table. If they still do not transition to Running, check that your VPC has the Internet Gateway attached and the route table is configured correctly.

help me troubleshoot my EC2 instances that are stuck in Pending state

Your base environment is ready. Next up, you will create a secondary ENI and move it between instances to simulate failover.

Create and Manage Elastic Network Interfaces (ENI)

Your two instances are running, but each one only has a single network interface. That means if one instance fails, any service relying on its private IP address goes down with it.

In this step, you will create a secondary Elastic Network Interface (ENI) and practice moving it between instances. This is how production systems achieve rapid failover without DNS changes or route table updates.

In this step, get ready to:

Create a secondary ENI with a custom security group and private IP address.
Attach the ENI to Instance1 and observe dual network interfaces.
Detach the ENI and reattach it to Instance2 to simulate failover.

Create a secondary ENI

An ENI is a logical networking component in a VPC that represents a virtual network card. Each ENI carries its own private IP address, security groups, and MAC address.

You will create a secondary ENI with its own security group so you can later move it between instances independently of their primary network interfaces.

First, create a new security group for the ENI:

In the AWS Console, navigate to EC2 using the search bar at the top.
In the left sidebar, scroll down to Network & Security and click Security Groups.
Click Create security group.
Enter Lab-ENI-SG in the Security group name field.
Enter Allow SSH and ICMP from VPC in the Description field.
In the VPC dropdown, select your NetworkingLab-VPC.
Under Inbound rules, click Add rule.
Set the first rule's Type to SSH and its Source to 10.0.0.0/16.
Click Add rule again.
Set the second rule's Type to All ICMP - IPv4 and its Source to 10.0.0.0/16.
Click Create security group.

Why a separate security group?

Security groups are attached to ENIs, not instances. When you move an ENI between instances, its security groups travel with it. By giving this ENI its own security group, you control exactly what traffic reaches whichever instance the ENI is currently attached to.

Now create the secondary ENI itself:

In the left sidebar under Network & Security, click Network Interfaces.
Click Create network interface.
Enter Lab-Secondary-ENI in the Description field.
In the Subnet dropdown, select the same public subnet your instances are in (10.0.1.0/24).
For Interface type, leave it set to ENA (the default).
Under Private IPv4 address, select Custom and enter 10.0.1.100.
In the Security groups section, select Lab-ENI-SG (the one you just created).
Click Create network interface.

You should see a success banner and your new ENI listed with the status Available.

Click on the ENI ID to view its details.
Observe the attributes: private IP (10.0.1.100), subnet, security group, MAC address, and source/destination check (enabled by default).

What is an ENI?

An ENI is a virtual network card for your EC2 instance. It carries attributes including a primary private IPv4 address, one or more secondary private IPv4 addresses, an Elastic IP per private IPv4, a public IPv4, IPv6 addresses, security groups, a MAC address, and a source/destination check flag.

The key rule for the SAA exam: an ENI is bound to a specific subnet and Availability Zone. It cannot be moved to a different subnet after creation.

Seeing an error when creating the ENI?

Make sure the subnet you selected matches the one your instances are in. If you get an IP conflict error, the address 10.0.1.100 may already be in use. Try 10.0.1.101 instead.

help me troubleshoot why my ENI creation failed in the EC2 Console

Attach the ENI to Instance1

Your ENI is created but not attached to any instance. It is sitting in an Available state, ready to be connected to a running instance.

In the Network Interfaces list, select the checkbox next to Lab-Secondary-ENI.
Click Actions, then select Attach.
In the Instance dropdown, select NetworkingLab-Instance1.
Click Attach.

The ENI status changes to In-use. The device index is 1, because the primary ENI always occupies device index 0.

Navigate to Instances in the left sidebar.
Select NetworkingLab-Instance1 and click the Networking tab in the details panel below.
Under Network interfaces, confirm you see two entries: the primary ENI and your Lab-Secondary-ENI with IP 10.0.1.100.

Why would an instance need two network interfaces?

Each ENI has its own private IP and security group. This lets you create dual-homed instances with separate management and production traffic, or run network appliances that need interfaces in different security zones.

Detach and reattach to Instance2 (failover simulation)

The real power of a secondary ENI is portability. When an instance fails, you can detach the ENI and reattach it to a healthy instance. The private IP, security groups, and MAC address all move with it.

In the left sidebar, click Network Interfaces under Network & Security.
Select the checkbox next to Lab-Secondary-ENI.
Click Actions, then select Detach.
In the confirmation dialog, click Detach.
Wait a few seconds until the ENI status returns to Available.

Now attach it to Instance2 to complete the failover:

With Lab-Secondary-ENI still selected, click Actions, then Attach.
In the Instance dropdown, select NetworkingLab-Instance2.
Click Attach.

The ENI status changes back to In-use, now associated with Instance2.

Navigate to Instances in the left sidebar.
Select NetworkingLab-Instance2 and click the Networking tab.
Confirm Lab-Secondary-ENI now appears under Network interfaces with IP 10.0.1.100 and security group Lab-ENI-SG.

What just happened?

You just simulated a failover. The private IP address 10.0.1.100, the MAC address, and the security group Lab-ENI-SG all moved from Instance1 to Instance2. No DNS changes or route table updates were needed.

This is exactly how production systems implement rapid failover for services like NAT instances or database endpoints. Any client pointing at 10.0.1.100 now reaches Instance2 instead of Instance1, automatically.

SAA exam tip: ENI attachment rules

A primary ENI cannot be detached from an instance. Only secondary ENIs can be detached and reattached. The target instance must be in the same Availability Zone as the ENI (since the ENI is bound to its subnet).

ENI attachment types are hot (instance is running), warm (instance is stopped), and cold (at launch). You just performed a hot attach to a running instance.

Can't attach the ENI to Instance2?

Make sure Instance2 is in the same Availability Zone as the ENI. Also verify the ENI status shows Available before attempting to attach. If it still shows In-use, the detach may not have completed yet. Wait a few seconds and refresh the page.

help me troubleshoot why I cannot attach my ENI to a different EC2 instance

You now have hands-on experience with the ENI failover pattern. Next up, you will explore how Enhanced Networking and ENA deliver higher performance through the network interfaces you just created.

Understand Enhanced Networking and ENA

You just proved that an ENI can move between instances, carrying its IP address and security groups with it. That covers the logical networking layer.

Now let's go deeper. Your instances are already using a performance feature called Enhanced Networking, and you may not even realize it. Enhanced Networking uses a technology called SR-IOV to give instances higher bandwidth, more packets per second, and lower latency without extra CPU usage.

In this step, get ready to:

Verify that ENA enhanced networking is enabled on your t3.micro instance.
Understand the two enhanced networking mechanisms: ENA vs Intel 82599 VF.
Compare network performance specifications across different instance types.

Verify your instance uses ENA

Your t3.micro instances are Nitro-based, which means they automatically use the Elastic Network Adapter (ENA) for enhanced networking. No configuration is needed. Let's confirm this in the Console.

In the EC2 Console, click Instances in the left sidebar.
Select NetworkingLab-Instance1 by clicking its name.
Click the Networking tab in the instance details panel below.
Under Network interfaces, find the Interface type column.

You should see ENA listed as the interface type for the primary network interface.

What does ENA mean here?

ENA stands for Elastic Network Adapter. It is the driver that provides enhanced networking on all Nitro-based (current generation) instances.

Enhanced networking uses SR-IOV (Single Root I/O Virtualization) to give instances direct access to network hardware. This means higher bandwidth (up to 100 Gbps on supported types), more packets per second, and lower latency with reduced CPU usage. There is no additional charge for enhanced networking.

What is SR-IOV?

SR-IOV lets a single physical network card present itself as multiple virtual devices to different instances. Each instance gets its own direct path to the hardware instead of sharing a virtualized one. Think of it like giving each apartment in a building its own front door to the street, instead of funneling everyone through a single lobby.

Enhanced networking cannot be toggled in the Console

You cannot enable or disable enhanced networking from the EC2 Console. It requires the AWS CLI. However, on Nitro-based instances like t3.micro, ENA is enabled by default and requires no action from you.

Understand the two enhanced networking mechanisms

AWS offers two different drivers for enhanced networking. Which one your instance uses depends entirely on its instance type generation.

ENA (Elastic Network Adapter) supports up to 100 Gbps. All Nitro-based (current generation) instances use ENA. Some Xen-based instances also support it: H1, I3, G3, m4.16xlarge, P2, P3, P3dn, and R4.
Intel 82599 VF supports up to 10 Gbps. This is the legacy driver used by older instance types: C3, C4, D2, I2, M4 (except m4.16xlarge), and R3.

How do I remember this for the SAA exam?

If a question mentions "enhanced networking" with modern instances, the answer is ENA. If you see older instance types like C3, C4, D2, I2, M4 (except m4.16xlarge), or R3, they use Intel 82599 VF.

The key distinction is speed. ENA gives you up to 100 Gbps. Intel 82599 VF tops out at 10 Gbps. Both use SR-IOV under the hood, and neither costs extra.

Review network performance in instance type details

The instance type you choose directly determines your maximum network throughput. Let's compare two instance types in the Console to see the difference.

In the EC2 Console left sidebar, click Instance Types (under the Instances section).
In the search/filter bar at the top, type t3.micro and press Enter.
Select t3.micro from the results by clicking its name.
Click the Networking tab in the details panel.

You should see the network performance listed as Low to Moderate. This is your t3.micro's maximum network throughput capability.

Clear the search bar and type c5n.18xlarge instead.
Select c5n.18xlarge and click the Networking tab.

This time you should see 100 Gigabit listed as the network performance. That is the full 100 Gbps that ENA can deliver on a high-end instance.

Why does instance type choice matter for networking?

Even though both t3.micro and c5n.18xlarge use ENA, the instance type sets the ceiling for actual throughput. A t3.micro gets "Low to Moderate" performance. A c5n.18xlarge gets the full 100 Gbps. The driver is the same, but the hardware allocation differs.

For the SAA exam, remember that choosing the right instance type is a key lever for network performance. Upgrading to ENA alone does not guarantee high throughput if the instance type is small.

Don't see Interface type in the Networking tab?

Make sure you are looking at the instance details (click the instance name), not the checkbox. The Networking tab is in the lower details panel that appears after you select an instance.

If you do not see the Instance Types page in the left sidebar, scroll down in the sidebar and look under the Instances heading.

Help me find the ENA interface type for my EC2 instance

You now understand the performance layer underneath your ENIs. Next, you will explore ENA Express, which uses a special protocol to push single-flow bandwidth even higher within the same Availability Zone.

Explore ENA Express

You now know that ENA gives your instances enhanced networking through SR-IOV. But what happens when even ENA's default bandwidth is not enough for a single network flow between two instances?

AWS built ENA Express to solve this exact problem. It boosts single-flow bandwidth from 5 Gbps to up to 25 Gbps between instances in the same Availability Zone. In this step, you will explore ENA Express settings in the Console and learn the exam triggers that signal when ENA Express is the correct answer.

In this step, get ready to:

Understand how ENA Express uses SRD technology to increase single-flow bandwidth.
View ENA Express settings on your instance's network interface in the Console.
Memorize the SAA exam triggers that point to ENA Express as the answer.

Understand what ENA Express does

Standard ENA limits a single network flow to about 5 Gbps between two instances. For workloads like distributed storage or live media encoding, that is not enough.

ENA Express uses AWS Scalable Reliable Datagram (SRD) technology to increase single-flow bandwidth from 5 Gbps to up to 25 Gbps between two instances in the same Availability Zone.

What is SRD?

SRD (Scalable Reliable Datagram) is the same underlying technology that powers EFA for HPC workloads. When used in ENA Express, SRD reduces tail latency and avoids congested network paths by intelligently routing packets.

Think of it as a smarter delivery route for your network traffic. Instead of always taking the same highway (which might be jammed), SRD finds alternate roads to get packets delivered faster.

There are important requirements for ENA Express to work:

Both the sending AND receiving instances must have ENA Express enabled.
Both instances must be in the same Availability Zone.
Both instances must be supported instance types (m6i.8xlarge and above, c6i.8xlarge and above, and similar large instances).
ENA Express does NOT work across Availability Zones or in Local Zones.
If either side lacks ENA Express support, traffic falls back to standard ENA automatically.

View ENA Express settings in the Console

Even though your t3.micro instances do not support ENA Express, you can still view the settings in the Console. This is useful for understanding where to find and configure ENA Express on production workloads.

In the AWS Console, navigate to EC2.
In the left sidebar, click Network Interfaces under the Network & Security section.
Find the primary network interface of NetworkingLab-Instance1. You can identify it by checking the Instance ID column or by looking for the interface attached at device index 0.
Select that network interface by clicking its checkbox.
Click the Actions dropdown at the top.
Select Manage ENA Express.

You should see two toggle settings in the dialog that appears.

What do these ENA Express settings mean?

ENA Express - Enables or disables ENA Express for TCP traffic on this network interface.
ENA Express UDP - Enables or disables ENA Express specifically for UDP traffic. This is a separate toggle because UDP has different reliability characteristics than TCP.

On your t3.micro instance, enabling these toggles would have no effect because the instance type is not supported. ENA Express requires larger instance types like m6i.8xlarge and above.

Click Cancel to close the dialog without making changes.

ENA Express settings are per-attachment

ENA Express settings apply to a network interface's attachment to an instance. If you detach the ENI, the ENA Express settings on that attachment cease to exist. You would need to re-enable ENA Express after reattaching the interface.

Learn the SAA exam scenarios for ENA Express

The SAA-C03 exam tests whether you can identify when ENA Express is the right solution. Here are the triggers to watch for in exam questions.

ENA Express is the answer when a question mentions:

"Reduce tail latency between instances in the same AZ."
"Increase single-flow bandwidth beyond 5 Gbps."
Distributed storage systems needing high single-flow throughput between instances.
Live media encoding with latency sensitivity between instances in one AZ.
Any workload where tail latency between two instances matters.

ENA Express is NOT the answer when:

Instances are in different Availability Zones.
The workload is in a Local Zone.
The question mentions HPC, MPI, or OS-bypass (those point to EFA instead).
Instance types are too small (must be m6i.8xlarge and above, c6i.8xlarge and above, or equivalent).

How does ENA Express differ from EFA?

Both ENA Express and EFA use AWS SRD technology, but they serve different purposes. ENA Express boosts standard TCP/UDP traffic between instances. EFA provides OS-bypass for tightly coupled parallel workloads like HPC and AI/ML training.

If the exam question mentions "single-flow bandwidth" or "tail latency" for standard applications, think ENA Express. If it mentions "MPI," "distributed training," or "OS-bypass," think EFA.

You have now explored every setting ENA Express offers in the Console and built a mental model for identifying it on the exam. Next up, you will learn about EFA and its OS-bypass capability for HPC and AI workloads.

Understand Elastic Fabric Adapter (EFA)

You now understand how ENA provides high-performance TCP/IP networking and how ENA Express boosts single-flow bandwidth using SRD.

Some workloads need even more than fast networking. AI/ML distributed training and High-Performance Computing (HPC) simulations require instances to communicate directly with network hardware, bypassing the operating system entirely. This is where Elastic Fabric Adapter (EFA) comes in.

In this step, get ready to:

Explore the three EFA interface types available in the AWS Console.
Understand how EFA differs from ENA and when to use each.
Build a mental decision tree for EFA-related SAA exam questions.

Explore EFA interface types in the Console

The AWS Console's Create Network Interface page reveals the complete EC2 networking hierarchy in a single dropdown. You will navigate there to see all three interface types without actually creating anything.

In the AWS Console, navigate to EC2 from the Services menu.
In the left sidebar, scroll down to Network & Security and click Network Interfaces.
Click Create network interface.
Click the Interface type dropdown to expand it.

You should see three options in the dropdown.

ENA - The standard high-performance NIC for TCP/IP networking. This is the default you have been using throughout this project.
EFA with ENA - Provides both traditional IP networking AND the EFA device for OS-bypass low-latency communication via SRD.
EFA-only - Provides only the EFA device for SRD-based inter-node transport. No IP addresses can be assigned, and it cannot be a primary NIC.

Click Cancel to exit without creating anything. EFA requires expensive instance types, so you will not create one in this project.

Why not create an EFA interface?

EFA-capable instances are expensive. For example, c5n.18xlarge costs around $3/hour. The Console dropdown gives you everything you need to understand the options without incurring any cost.

What is the networking hierarchy?

That single dropdown reveals the full EC2 networking stack. ENI is the logical NIC. Enhanced Networking via ENA uses SR-IOV to boost performance on that NIC. ENA Express adds SRD to increase single-flow bandwidth. EFA takes SRD further by providing OS-bypass for direct hardware communication.

Each level builds on the one below it. For the SAA exam, this hierarchy is the mental model you need.

Understand EFA vs. ENA

EFA is a network device specifically designed for AI/ML and HPC workloads. The key difference from ENA is how applications communicate with the network.

What is OS-bypass?

With standard networking (ENA), data travels from the application through the operating system kernel to the network hardware. With EFA, applications use the Libfabric API to communicate directly with the network hardware, completely bypassing the kernel.

This OS-bypass dramatically reduces latency for inter-node communication. It is the same principle that makes on-premises HPC clusters fast.

Here is how the three interface types compare:

ENA - Supports IP networking. Can be a primary NIC. Available on all Nitro-based instances. Handles traditional TCP/IP traffic.
EFA with ENA - Supports IP networking AND provides the EFA device. Requires specific instance types. Use this when your workload needs both standard networking and OS-bypass.
EFA-only - No IP networking at all. Cannot be a primary NIC. Provides only SRD-based inter-node transport. Use this for dedicated compute nodes that only need to talk to each other.

What libraries does EFA support?

EFA integrates with the Libfabric communication library. On top of that, it supports:

MPI (Open MPI 4.1+ and Intel MPI 2019 Update 5+) for traditional HPC workloads.
NCCL (NVIDIA Collective Communications Library) for AI/ML distributed training.
NIXL (NVIDIA) for disaggregated inference workloads.

EFA requires specific instance types that are designed for high-performance workloads. Examples include c5n.18xlarge, p4d, p5, and hpc6a instance families.

SAA exam EFA decision tree

EFA questions on the SAA-C03 exam follow a predictable pattern. Certain keywords in the question stem almost always point to EFA as the correct answer.

When does the exam answer involve EFA?

If the question mentions any of these keywords, think EFA combined with a cluster placement group:

"HPC" or "High-Performance Computing."
"MPI" or "Message Passing Interface."
"Tightly coupled" workloads.
"Inter-node communication."
"Distributed training" or "ML training across instances."
"On-premises HPC cluster migration" to AWS.

EFA is NOT the answer for standard web applications, databases, or loosely coupled workloads. Those use ENA.

EFA vs. ENA Express on the exam

Both EFA and ENA Express use SRD technology, but they solve different problems. ENA Express increases single-flow bandwidth between two instances in the same AZ. EFA provides OS-bypass for parallel computing frameworks like MPI and NCCL.

If the question says "single-flow bandwidth" or "tail latency," think ENA Express. If the question says "tightly coupled" or "OS-bypass," think EFA.

You now have a complete picture of EC2 networking, from basic ENIs all the way to EFA for HPC. Next up, you will put instances into placement groups to control where they physically sit in the data center.

Create and Test Placement Groups

You now understand the full EC2 networking stack, from ENIs to ENA to EFA. The next piece of the puzzle is where your instances sit physically in the data center.

Placement groups let you control instance placement strategy to optimize for low latency, high availability, or rack-awareness. In this step, you will create all three placement group types and launch instances into each one.

In this step, get ready to:

Create a Cluster placement group and verify it with a c5.large instance.
Create a Spread placement group with two instances on distinct hardware.
Create a Partition placement group with instances in separate partitions.

Create a Cluster placement group

A Cluster placement group packs all instances onto the same high-bisection bandwidth network segment in a single Availability Zone. This delivers the lowest possible latency and highest throughput between instances.

In the AWS Console, navigate to EC2.
In the left sidebar, scroll down to the Network & Security section and click Placement Groups.
Click Create placement group.
Enter Lab-Cluster-PG as the name.
Select Cluster as the placement strategy.
Click Create group.

You should see Lab-Cluster-PG appear in your Placement Groups list with a state of Available.

What are the rules for Cluster placement groups?

Cluster placement groups are constrained to a single AZ. Enhanced networking instances get up to 10 Gbps single-flow bandwidth inside the group (compared to 5 Gbps outside). Network traffic to the internet and over Direct Connect is limited to 5 Gbps.

Best practice is to launch all instances in one request using the same instance type. Burstable types (T2, T3) are NOT supported in cluster placement groups.

Now you will launch an instance into this cluster placement group to verify it works. Since T3 burstable instances are not supported in cluster placement groups, you will use a c5.large instance briefly.

Cost warning

A c5.large instance costs approximately $0.085/hour. You will launch it only to verify the placement group works, then terminate it immediately. The total cost should be about $0.01 or less.

Navigate to Instances in the left sidebar and click Launch instances.
Enter ClusterPG-Test as the instance name.
Select Amazon Linux 2023 AMI.
For instance type, select c5.large.
Select your existing key pair.
Under Network settings, click Edit.
Select your NetworkingLab-VPC and your public subnet.
Expand the Advanced details section at the bottom.
Find the Placement group name dropdown and select Lab-Cluster-PG.
Click Launch instance.

Wait for the instance to reach Running status. This confirms your cluster placement group is working correctly.

Select the ClusterPG-Test instance.
Click Instance state and select Terminate instance.
Confirm the termination.

Why terminate immediately?

The c5.large is not free-tier eligible. By terminating it right away, you limit the cost to a fraction of a cent. The placement group itself has no charge and remains available for future use.

Instance failed to launch?

If you see an InsufficientInstanceCapacity error, that means your AZ does not have c5.large capacity right now. Try launching again, or wait a minute and retry. This is a temporary capacity issue, not a configuration problem.

If you accidentally selected a t3 instance type, you will see a validation error because burstable instance types are not supported in cluster placement groups.

Help me troubleshoot my cluster placement group launch

Create a Spread placement group

A Spread placement group places each instance on distinct hardware with its own network connection and power source. This maximizes fault isolation for small numbers of critical instances.

Navigate back to Placement Groups in the left sidebar.
Click Create placement group.
Enter Lab-Spread-PG as the name.
Select Spread as the placement strategy.
For Spread level, select Rack.
Click Create group.

What are the rules for Spread placement groups?

Each instance lands on a separate physical rack with independent network and power. The maximum is 7 running instances per AZ per group. Spread groups can span multiple AZs, making them ideal for small numbers of critical instances that must survive hardware failures independently.

Now launch two t3.micro instances into this spread placement group.

Navigate to Instances and click Launch instances.
Enter SpreadPG-Instance as the instance name.
Select Amazon Linux 2023 AMI.
Keep instance type as t3.micro.
Set Number of instances to 2.
Select your existing key pair.
Under Network settings, click Edit and select your NetworkingLab-VPC and public subnet.
Expand Advanced details.
In the Placement group name dropdown, select Lab-Spread-PG.
Click Launch instance.

Wait for both instances to reach Running status.
Select one of the SpreadPG-Instance instances and click the Details tab at the bottom.
Scroll to find Placement group. Confirm it shows Lab-Spread-PG.

Both instances are now running on separate racks. If one rack loses power or network, the other instance remains unaffected.

Don't see the placement group in instance details?

Make sure you are looking at the Details tab (not Networking or Security). The placement group field is in the lower portion of the Details tab. If the field is empty, the instance was not launched into a placement group. Check that you selected Lab-Spread-PG under Advanced details before launching.

Help me verify my spread placement group instances

Create a Partition placement group

A Partition placement group divides instances into logical partitions, each on separate racks. This gives you rack-awareness without the 7-instance-per-AZ limit of spread groups.

Navigate back to Placement Groups in the left sidebar.
Click Create placement group.
Enter Lab-Partition-PG as the name.
Select Partition as the placement strategy.
Set the Number of partitions to 3.
Click Create group.

What are the rules for Partition placement groups?

You can have a maximum of 7 partitions per AZ. Each partition has its own set of racks, so a rack failure affects only one partition. There is no limit on instances per partition (only your account limits apply).

Partition groups can span multiple AZs. They are ideal for distributed data systems like HDFS, HBase, Cassandra, and Kafka where you want rack-awareness for data replication.

Now launch two instances into different partitions to see how partition assignment works.

Navigate to Instances and click Launch instances.
Enter PartitionPG-Instance1 as the instance name.
Select Amazon Linux 2023 AMI and keep instance type as t3.micro.
Select your existing key pair.
Under Network settings, click Edit and select your NetworkingLab-VPC and public subnet.
Expand Advanced details.
In the Placement group name dropdown, select Lab-Partition-PG.
In the Target partition dropdown, select 1.
Click Launch instance.

Now launch a second instance into Partition 2.

Click Launch instances again.
Enter PartitionPG-Instance2 as the instance name.
Select Amazon Linux 2023 AMI and keep instance type as t3.micro.
Select your existing key pair.
Under Network settings, click Edit and select your NetworkingLab-VPC and public subnet.
Expand Advanced details.
In the Placement group name dropdown, select Lab-Partition-PG.
In the Target partition dropdown, select 2.
Click Launch instance.

Wait for both instances to reach Running status.
Select PartitionPG-Instance1 and click the Details tab.
Scroll down and confirm Placement group shows Lab-Partition-PG and the Partition number shows 1.
Select PartitionPG-Instance2 and verify its partition number is 2.

Your two instances are now in separate partitions on separate racks. In a real Kafka or Cassandra cluster, you would configure the application to place replicas in different partitions. A single rack failure would only affect one partition's instances.

Don't see a partition number in instance details?

Verify you selected a specific partition number (1 or 2) in the Target partition dropdown before launching. If you left it as "Auto," AWS assigns the partition automatically. You can still see the assigned partition in the Details tab, but it may not be the number you expected.

Help me verify my partition placement group assignments

SAA exam tip: choosing placement groups

If the question mentions "lowest latency," "HPC," or "tightly coupled," the answer is Cluster. If it mentions "critical instances" that must "survive hardware failures independently" with fewer than 7 per AZ, think Spread. If it mentions "rack-awareness," "HDFS," "Cassandra," "Kafka," or large numbers of instances, the answer is Partition.

You now have hands-on experience with all three placement group types. Combined with your ENI, ENA, ENA Express, and EFA knowledge from earlier steps, you have a complete picture of EC2 networking for the SAA-C03 exam.

Secret mission

Design Architecture Recommendations

You've explored every EC2 networking feature hands-on. Now put your knowledge to the test as a Solutions Architect. Given three real-world workload scenarios, determine the correct networking feature and placement group strategy for each.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Most resources in this project are free tier eligible or carry no charge, so there is no immediate cost pressure.

Resources you used:

2 t3.micro EC2 instances (free tier eligible, covered by 750 hours/month).
1 secondary ENI (no charge).
3 placement groups: Cluster, Spread, Partition (no charge).
1 VPC with public subnet, route table, and internet gateway (no charge).
Brief c5.large instance for Cluster placement group test (should already be terminated).

Keep everything running

No action needed. Choose this if you want to continue experimenting with ENI attachments, placement groups, or networking settings.

Your t3.micro instances are covered by the AWS Free Tier (750 hours/month shared across all t3.micro instances in your account).
ENIs, placement groups, and VPC resources carry no ongoing charges.
Confirm the c5.large instance from Step 6 has been terminated. If it is still running, terminate it immediately to avoid charges.

Pause - I'll come back to this later

Stop your instances to preserve the environment without compute charges. Your ENI, placement groups, and VPC remain intact.

Go to EC2 > Instances.
Select both "NetworkingLab-Instance1" and "NetworkingLab-Instance2".
Click Instance state > Stop instance.
Confirm the stop action. Stopped instances do not incur compute charges, but any attached EBS volumes still incur minimal storage charges.
Your secondary ENI, placement groups, and VPC will remain available when you start the instances again.

Delete - I don't want to use this again

Remove all project resources and return your account to zero running resources from this lab.

Go to EC2 > Instances. Select both instances, click Instance state > Terminate instance.
Go to EC2 > Network Interfaces. Select "Lab-Secondary-ENI" and click Actions > Delete.
Go to EC2 > Placement Groups. Delete "Lab-Cluster-PG", "Lab-Spread-PG", and "Lab-Partition-PG" one at a time.
Go to VPC > Internet Gateways. Detach and then delete the internet gateway you created.
Go to VPC > Subnets. Delete the public subnet you created.
Go to VPC > Route Tables. Delete the custom route table associated with your VPC (the main route table deletes automatically with the VPC).
Go to VPC > Your VPCs. Select the VPC you created and click Actions > Delete VPC.
Delete any security groups you created for this project (the default security group for the VPC deletes with the VPC).

That's a Wrap!

Congratulations! You just built hands-on experience with every EC2 networking concept tested on the SAA-C03 exam.

You've learned how to:

Created, attached, detached, and reattached an ENI to simulate failover, demonstrating how private IPs, security groups, and MAC addresses travel with the interface.
Verified Enhanced Networking with ENA on a Nitro-based instance and understood the full networking hierarchy from ENI to ENA to ENA Express to EFA.
Created all three placement group types (Cluster, Spread, Partition) and launched instances into each to understand instance placement strategies for high-performance architectures.
Designed architecture recommendations matching the right networking feature and placement group strategy to real-world workload scenarios.

Ready to quiz yourself?