Master Elastic Network Interfaces

Build a multi-ENI architecture and simulate failover on AWS.

Introduction

30 Second Summary

Imagine your website's server goes down. Instead of scrambling to update DNS records and waiting for changes to propagate, what if you could instantly move your server's network identity to a backup machine? That's exactly what Elastic Network Interfaces let you do in AWS.

In this project, you will create, attach, detach, and move Elastic Network Interfaces between EC2 instances. You will simulate a real failover scenario and configure Source/Destination Check, covering every ENI concept tested on the SAA-C03 exam.

What You'll Build

A hands-on ENI lab environment in AWS that demonstrates failover, multi-homed instances, and Source/Destination Check configuration across two EC2 instances.

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

A standalone secondary ENI with an Elastic IP attached, moved between instances to prove that IP and MAC address persist across failovers.
A demonstrated ENI failover scenario where traffic seamlessly shifts from a primary server to a standby server with no DNS or route table changes.
Configured Source/Destination Check settings and a clear understanding of when and why to disable them for NAT instances, firewalls, and routing appliances.
Secret Mission: Configure a working NAT instance using a secondary ENI with Source/Destination Check disabled, routing private subnet traffic to the internet.

Are there any prerequisites?

You need an AWS account with console access and basic familiarity with VPC and EC2 instance creation. If you have launched an instance and created a VPC before, you are ready to go.

Create Your Lab Environment

Before you can explore how Elastic Network Interfaces work, you need a network to work in. Every ENI lives inside a VPC and attaches to instances within a specific Availability Zone.

In this step, you will build a custom VPC with a public subnet, a private subnet, and all the networking plumbing that connects them to the internet. Then you will launch two EC2 instances and observe the primary ENIs that AWS creates for them automatically.

In this step, get ready to:

Create a custom VPC with public and private subnets, an Internet Gateway, and a route table.
Launch two EC2 instances (PrimaryServer and StandbyServer) in the public subnet.
Identify the primary ENIs on each instance and note their attributes.

Create the VPC and networking infrastructure

Your lab needs a dedicated VPC so your ENI experiments stay isolated from any other resources in your AWS account. You will also create two subnets in the same Availability Zone, which is a requirement for attaching ENIs to instances later.

Sign into the AWS Management Console.
Type VPC in the top search bar and select VPC from the results.
Click Create VPC.
Select VPC only (not "VPC and more").
Enter ENI-Lab-VPC in the Name tag field.
Enter 10.0.0.0/16 in the IPv4 CIDR block field.
Click Create VPC.

Why VPC only?

The "VPC and more" option auto-creates subnets, route tables, and gateways for you. Building each resource manually gives you a deeper understanding of how they connect, which is exactly what the SAA-C03 tests.

Now enable DNS hostnames on your new VPC so instances can resolve public DNS names.

Select ENI-Lab-VPC in the VPC list.
Click Actions, then Edit VPC settings.
Check the box for Enable DNS hostnames.
Click Save.

Next, create the public subnet.

In the left sidebar, click Subnets.
Click Create subnet.
Select ENI-Lab-VPC from the VPC ID dropdown.
Enter ENI-Lab-Public-Subnet in the Subnet name field.
Choose an Availability Zone (for example, us-east-1a). Remember which one you pick.
Enter 10.0.1.0/24 in the IPv4 subnet CIDR block field.
Click Create subnet.

Now create the private subnet in the same Availability Zone.

Click Create subnet again.
Select ENI-Lab-VPC from the VPC ID dropdown.
Enter ENI-Lab-Private-Subnet in the Subnet name field.
Select the same Availability Zone you used for the public subnet.
Enter 10.0.2.0/24 in the IPv4 subnet CIDR block field.
Click Create subnet.

Why the same Availability Zone?

ENIs can only attach to instances in the same Availability Zone. By placing both subnets in the same AZ, you ensure that any ENI you create can be attached to any instance in your lab.

Your subnets exist, but nothing can reach the internet yet. Create an Internet Gateway and attach it to your VPC.

In the left sidebar, click Internet gateways.
Click Create internet gateway.
Enter ENI-Lab-IGW in the Name tag field.
Click Create internet gateway.
On the confirmation page, click Actions, then Attach to VPC.
Select ENI-Lab-VPC and click Attach internet gateway.

Now create a route table that sends internet-bound traffic through the Internet Gateway, and associate it with your public subnet.

In the left sidebar, click Route tables.
Click Create route table.
Enter ENI-Lab-Public-RT in the Name field.
Select ENI-Lab-VPC from the VPC dropdown.
Click Create route table.
On the route table details page, click the Routes tab.
Click Edit routes.
Click Add route.
Enter 0.0.0.0/0 in the Destination field.
In the Target dropdown, select Internet Gateway, then select ENI-Lab-IGW.
Click Save changes.

Associate this route table with your public subnet.

Click the Subnet associations tab.
Click Edit subnet associations.
Check the box next to ENI-Lab-Public-Subnet.
Click Save associations.

Finally, create a security group for your lab instances.

In the left sidebar, click Security groups (under the Security section).
Click Create security group.
Enter ENI-Lab-SG in the Security group name field.
Enter Security group for ENI lab instances in the Description field.
Select ENI-Lab-VPC from the VPC dropdown.

Add two inbound rules.

Under Inbound rules, click Add rule.
Set Type to SSH. Leave Source as 0.0.0.0/0.
Click Add rule again.
Set Type to HTTP. Leave Source as 0.0.0.0/0.
Click Create security group.

What is a Security Group?

A Security Group acts as a virtual firewall for your instances. It controls inbound and outbound traffic at the ENI level.

This is an important exam concept: security groups attach to ENIs, not directly to instances. An instance with multiple ENIs can have different security groups on each one.

Don't see ENI-Lab-VPC in a dropdown?

Make sure you are working in the same AWS Region where you created the VPC. Check the Region selector in the top-right corner of the console. If you switched Regions accidentally, your VPC will not appear.

Help me troubleshoot why my VPC isn't showing up in the dropdown.

Launch two EC2 instances in the public subnet

You need two instances to demonstrate ENI failover later. PrimaryServer will host your secondary ENI first, and StandbyServer will receive it when you simulate a failover.

Type EC2 in the top search bar and select EC2 from the results.
Click Launch instance.
Enter PrimaryServer in the Name field.
Under Application and OS Images, select Amazon Linux 2023 AMI (it should be the default).
Under Instance type, select t2.micro (free tier eligible).
Under Key pair, select an existing key pair or click Create new key pair and follow the prompts.

Configure the network settings for PrimaryServer.

Under Network settings, click Edit.
Select ENI-Lab-VPC from the VPC dropdown.
Select ENI-Lab-Public-Subnet from the Subnet dropdown.
Set Auto-assign public IP to Enable.
Under Firewall (security groups), select Select existing security group.
Choose ENI-Lab-SG from the list.
Click Launch instance.

Now repeat the process for StandbyServer.

Click Launch instance again from the EC2 dashboard.
Enter StandbyServer in the Name field.
Select Amazon Linux 2023 AMI and t2.micro instance type.
Select the same key pair you used for PrimaryServer.
Under Network settings, click Edit.
Select ENI-Lab-VPC, ENI-Lab-Public-Subnet, and set Auto-assign public IP to Enable.
Select Select existing security group and choose ENI-Lab-SG.
Click Launch instance.

Navigate to Instances in the EC2 left sidebar.
Wait until both PrimaryServer and StandbyServer show Running in the Instance state column. This may take 1-2 minutes.

Why t2.micro?

The t2.micro instance type supports a maximum of 2 ENIs with 2 IPv4 addresses per ENI. This is perfect for the lab because you will attach exactly one secondary ENI to demonstrate failover.

Instance stuck in Pending state?

If an instance does not reach Running after a few minutes, check that you selected the correct subnet (ENI-Lab-Public-Subnet) and that the subnet is in an Availability Zone that supports t2.micro. Try terminating the instance and relaunching it in a different AZ if needed.

Help me figure out why my EC2 instance is not starting.

Observe the primary ENIs on each instance

Every EC2 instance gets a primary ENI (device index 0) automatically when it launches. This primary ENI cannot be detached. Understanding its attributes is essential for the SAA-C03 because questions often test whether you know which properties belong to the ENI versus the instance itself.

In the EC2 left sidebar, scroll down to Network & Security and click Network Interfaces.
You should see two ENIs listed. These are the primary ENIs for PrimaryServer and StandbyServer.
Click on one of the ENI IDs (starts with eni-) to view its details.

Review the following attributes on the ENI details page.

Note the Private IPv4 address. It comes from the 10.0.1.0/24 range of your public subnet.
Note the MAC address. This is unique to the ENI and persists even when the ENI moves between instances.
Check Security groups. You should see ENI-Lab-SG listed.
Check Source/dest. check. It should show true (enabled by default).
Under Attachment details, note the Device index is 0 and Delete on termination is true.

What are these ENI attributes?

Each ENI carries its own private IP, public IP (if assigned), MAC address, security groups, and Source/Destination Check flag. These attributes belong to the ENI, not to the instance.

When an ENI moves to a different instance, all of these attributes follow it. This is the mechanism that makes failover work without DNS changes.

Click the back arrow and repeat the review for the second ENI.
Confirm it also shows device index 0, a private IP from 10.0.1.0/24, ENI-Lab-SG as the security group, and Source/dest check enabled.

Why can't I detach a primary ENI?

The primary ENI (device index 0) is permanently bound to the instance that created it. AWS uses it as the anchor for the instance's core networking identity. You can only modify its attributes, not detach it.

Secondary ENIs (device index 1 and above) are the ones you can freely attach and detach. You will create one of those in the next step.

Your lab environment is ready. You have a VPC, two subnets, an Internet Gateway, a route table, a security group, and two running instances. Next up, you will create a standalone ENI and see what makes it different from the primary ENIs that AWS attached automatically.

Create and Examine a Standalone ENI

Your lab environment is ready with two EC2 instances running in the public subnet. Now it's time to create an ENI that exists independently of any instance.

So far, the ENIs you've observed were automatically created by AWS when you launched your instances. Those are primary ENIs and they're permanently bound to their instance. In this step, you'll create a standalone secondary ENI that can be freely attached, detached, and moved between instances.

In this step, get ready to:

Create a standalone ENI in your public subnet and examine its attributes.
Allocate an Elastic IP and associate it directly with the ENI.
Understand why Elastic IPs follow ENIs, not instances.

Create a new network interface

You'll create a standalone ENI in the same subnet as your instances. This ENI will exist in an "available" state, ready to be attached to any instance in the same Availability Zone.

In the AWS Console, navigate to EC2.
In the left sidebar under Network & Security, click Network Interfaces.
Click Create network interface.
Enter Secondary-Management-ENI in the Description field.
In the Subnet dropdown, select your ENI-Lab-Public-Subnet (10.0.1.0/24).
Leave Private IPv4 address set to Auto-assign. AWS will assign a private IP from the subnet's range.
In the Security groups section, select ENI-Lab-SG.
Click Create network interface.

You should see a success banner confirming the network interface was created.

Why create an ENI separately from an instance?

A standalone ENI exists independently of any instance's lifecycle. You can pre-configure it with an IP address, security groups, and an Elastic IP, then move it between instances as needed.

This is the foundation of low-budget high-availability architectures. If your primary instance fails, you detach the ENI and reattach it to a standby instance. All traffic follows the ENI to its new home.

Examine the ENI's attributes

Your new ENI already has several attributes assigned by AWS, even though it's not attached to anything yet. Understanding each attribute is critical for the SAA-C03 exam.

Click on your newly created ENI's ID to open its details page.
Look at the Status field. It should show available, meaning the ENI is not attached to any instance.
Find the Primary private IPv4 address. This is an IP from the 10.0.1.0/24 range, automatically assigned by AWS.
Note the MAC address. This address persists for the lifetime of the ENI, even when it's moved between instances.
Check the Security groups section. You should see ENI-Lab-SG listed.
Find Source/dest. check. Confirm it shows true (enabled by default).

How is this different from a primary ENI?

A primary ENI (eth0) is created automatically when an instance launches and cannot be detached. This standalone ENI you just created exists independently and can be attached to any instance in the same Availability Zone.

On the exam, remember: security groups attach to ENIs, not directly to instances. An instance with multiple ENIs can have different security groups on each interface. This is how you separate management traffic from application traffic.

Note this for the exam

ENIs can only be attached within the same Availability Zone. You cannot move an ENI across AZs. This is why you created the ENI in the same subnet (and therefore same AZ) as your instances.

Allocate and associate an Elastic IP with the ENI

A key SAA-C03 concept is that Elastic IP addresses can be associated directly with ENIs, not just with instances. When the ENI moves to a different instance, the Elastic IP moves with it.

In the left sidebar under Network & Security, click Elastic IPs.
Click Allocate Elastic IP address.
Leave the default settings (Amazon's pool of IPv4 addresses) and click Allocate.

You should see a success message with your new Elastic IP address displayed.

Select your newly allocated Elastic IP address.
Click Actions, then Associate Elastic IP address.
In the Resource type field, select Network interface.
In the Network interface dropdown, select your Secondary-Management-ENI.
The Private IP address field should auto-populate with the ENI's private IPv4. Leave it selected.
Click Associate.

You should see a confirmation that the Elastic IP is now associated with the network interface.

Navigate back to Network Interfaces and select your Secondary-Management-ENI.
In the details panel, confirm the Elastic IP address field now shows your allocated IP.

Why does the Elastic IP follow the ENI?

Elastic IPs associate with a specific private IP address on an ENI. They don't associate with an instance directly. When you detach and reattach the ENI to a different instance, the Elastic IP automatically comes along.

This means you can fail over a public-facing service to a standby instance with no DNS changes and no route table updates. Traffic hitting the Elastic IP simply arrives at whichever instance currently holds the ENI.

Don't see your ENI in the association dropdown?

Make sure you selected Network interface as the resource type, not Instance. The dropdown only shows ENIs when the correct resource type is selected.

Also confirm that the ENI is in the same Region you're currently viewing in the console.

help me associate my Elastic IP with my network interface

Your standalone ENI is fully configured with a private IP, security group, and Elastic IP. In the next step, you'll attach it to PrimaryServer and explore how hot, warm, and cold attachments work.

Attach the ENI and Explore Attachment Types

You have a standalone ENI sitting in your subnet with an Elastic IP attached to it. Right now it is doing nothing because it is not connected to any instance.

In this step, you will attach the ENI to PrimaryServer while it is running. This is called a "hot attach" and it is the foundation for failover architectures where you move a network interface to a standby instance without downtime.

In this step, get ready to:

Attach the secondary ENI to PrimaryServer as a hot attach.
Verify PrimaryServer shows two network interfaces with the Elastic IP visible.
Understand the key ENI constraints tested on the SAA-C03 exam.

Attach the secondary ENI to PrimaryServer

Attaching an ENI to a running instance is called a hot attach. AWS also supports warm attach (to a stopped instance) and cold attach (at launch time). The SAA-C03 expects you to know all three.

Navigate to EC2 > Network Interfaces in the left sidebar.
Select the checkbox next to Secondary-Management-ENI.
Click Actions, then select Attach.
In the Instance dropdown, select PrimaryServer.
Click Attach.

The ENI is now assigned device index 1 (eth1) and its status changes from "available" to "in-use".

What are hot, warm, and cold attaches?

A hot attach means the instance is running. A warm attach means the instance is stopped. A cold attach means you specify the ENI at launch time.

Hot attach is the most operationally useful because it lets you add or move network interfaces without stopping workloads. This is what makes ENI-based failover possible with near-zero downtime.

Don't see PrimaryServer in the dropdown?

The instance must be in the same Availability Zone as the ENI. Confirm both PrimaryServer and the ENI are in ENI-Lab-Public-Subnet. Also check that PrimaryServer is in the "running" or "stopped" state.

If you still cannot attach, confirm PrimaryServer is a t2.micro with only one ENI currently attached. The maximum for t2.micro is 2 ENIs.

Why can't I attach my ENI to PrimaryServer?

Verify the attachment on PrimaryServer

Navigate to EC2 > Instances in the left sidebar.
Select PrimaryServer.
Click the Networking tab in the details panel below.

You should see two network interfaces listed in the Network interfaces section. The primary ENI is at device index 0 (eth0) and cannot be detached. Your secondary ENI is at device index 1 (eth1) and is detachable.

Scroll down to the Elastic IP addresses section within the Networking tab.
Confirm that ENI-Lab-EIP now appears associated with PrimaryServer through the secondary ENI.

Why does the Elastic IP appear on PrimaryServer now?

Elastic IPs associate with a private IPv4 address on an ENI, not directly with an instance. When you attach the ENI to an instance, the Elastic IP comes along for the ride.

This is the mechanism that makes ENI failover powerful. When you move the ENI to a different instance later, the Elastic IP moves with it automatically.

Understand the key ENI constraints for the SAA-C03

Now that you have a working multi-ENI instance, let's cover the constraints the exam tests. These are easy marks if you memorize them.

ENI constraints tested on the SAA-C03

Same Availability Zone only. You cannot attach an ENI to an instance in a different AZ. This is why both your instances and the ENI are in ENI-Lab-Public-Subnet.
Primary ENI is non-detachable. The ENI at device index 0 (eth0) cannot be removed from an instance. Only secondary ENIs (device index 1+) can be detached.
ENI limit depends on instance type. A t2.micro supports a maximum of 2 ENIs with 2 IPv4 addresses per ENI. Larger instance types support more.
Asymmetric routing risk. Attaching multiple ENIs from the same subnet to one instance can cause asymmetric routing. AWS recommends using secondary private IPs on the primary ENI instead.
No bandwidth increase from multiple ENIs. NIC teaming is not supported. Maximum network throughput is determined by the instance type, not the number of ENIs attached.

Exam question pattern to watch for

The SAA-C03 loves offering "attach more ENIs to increase bandwidth" as a distractor answer. Always eliminate this option. Network throughput is set by the instance type and Enhanced Networking (ENA), not by ENI count.

Your PrimaryServer is now dual-homed with two network interfaces, each with its own private IP and security group associations. Next up, you will simulate a failover by moving this secondary ENI to StandbyServer and proving that all its attributes follow it.

Simulate ENI Failover to Standby Instance

In the previous step, you attached a secondary ENI to PrimaryServer and confirmed the Elastic IP appeared on the instance.

Now comes the most powerful use case for ENIs on the SAA-C03 exam: failover. Imagine PrimaryServer goes down and you need traffic to instantly reach StandbyServer instead. Because ENI attributes (private IP, Elastic IP, MAC address, security groups) persist when the interface moves between instances, you can redirect traffic without touching DNS records or route tables.

In this step, get ready to:

Detach the secondary ENI from PrimaryServer and observe its attributes persist.
Reattach the ENI to StandbyServer, simulating a failover event.
Verify that the Elastic IP and all ENI attributes now appear on StandbyServer.

Detach the secondary ENI from PrimaryServer

In a real failover scenario, you would script this detach/reattach operation to happen automatically when a health check fails. For this lab, you will perform it manually to see exactly what happens at each stage.

In the AWS Console, navigate to EC2 > Network Interfaces in the left sidebar.
Select the checkbox next to Secondary-Management-ENI.
Click Actions, then select Detach.
Confirm the detach when prompted.

Wait a few seconds for the status to update. The ENI's Status column should change to available.

With the ENI still selected, check the Details tab at the bottom of the page.
Confirm that the following attributes are still present: private IPv4 address, MAC address, ENI-Lab-SG security group, and the associated Elastic IP (ENI-Lab-EIP).

Why do the attributes persist?

An ENI is an independent resource in your VPC. Its attributes (private IP, Elastic IP, MAC address, security groups) belong to the interface itself, not to the instance it was attached to.

This is what makes ENI-based failover possible. The ENI carries its entire network identity with it wherever it goes.

ENI status still shows in-use?

The detach operation can take a few seconds. Refresh the Network Interfaces list by clicking the refresh icon in the top right. If it still shows in-use after 30 seconds, confirm you selected the correct ENI (the one with description Secondary-Management-ENI) and not the primary ENI, which cannot be detached.

Help me detach my secondary ENI from PrimaryServer

Attach the ENI to StandbyServer

The ENI is now floating freely in your VPC with its full network identity intact. Time to attach it to StandbyServer and complete the failover.

With Secondary-Management-ENI still selected in the Network Interfaces list, click Actions.
Select Attach.
In the Instance field, search for and select StandbyServer.
Click Attach.

The ENI is assigned device index 1 (eth1) on StandbyServer. This is another hot attach, since StandbyServer is running.

What just happened to your traffic?

Any traffic that was hitting the Elastic IP now routes to StandbyServer. No DNS changes were needed. No route table updates were required.

This is the foundation of low-budget high-availability architectures on the SAA-C03 exam. Instead of paying for an Elastic Load Balancer, you can script an ENI move to redirect traffic to a standby instance within seconds.

Attach option is greyed out?

Make sure the ENI status shows available. If it still shows detaching, wait and refresh. Also confirm StandbyServer is in the same Availability Zone as the ENI. ENIs cannot be attached across Availability Zones.

Help me attach my ENI to StandbyServer

Verify the failover on StandbyServer

The final step is confirming that StandbyServer now owns the full network identity that previously belonged to PrimaryServer's secondary interface.

Navigate to EC2 > Instances in the left sidebar.
Select StandbyServer.
Click the Networking tab in the instance details panel at the bottom.

You should see two network interfaces listed: the primary ENI (device index 0) and Secondary-Management-ENI (device index 1).

Confirm that the Elastic IP (ENI-Lab-EIP) now appears in the Elastic IP addresses section of StandbyServer's Networking tab.
Select PrimaryServer and check its Networking tab to confirm it now shows only one network interface (the primary ENI at device index 0).

What does this prove for the SAA-C03 exam?

You just demonstrated that ENI attributes (private IP, Elastic IP, MAC address, security groups) persist across detach and reattach operations. This is the core mechanism behind ENI-based failover.

On the exam, look for scenarios involving rapid failover for databases, NAT instances, or critical services. The correct answer often involves moving an ENI (with its Elastic IP) to a standby instance rather than reconfiguring DNS or updating route tables.

You have proven that an ENI carries its full network identity between instances. Next up, you will modify ENI attributes like security groups and Source/Destination Check to understand how they control traffic flow at the interface level.

Modify ENI Attributes and Configure Source/Destination Check

In the last step, you proved that an ENI carries its attributes across instances during a failover. Now it's time to explore what you can actually change on an ENI after it's created.

One of the most powerful (and frequently tested) ENI features is that each interface can have its own independent security groups and network settings. You'll modify the secondary ENI's security groups, disable Source/Destination Check, and configure termination behavior to control the ENI's lifecycle.

In this step, get ready to:

Modify security groups on the secondary ENI independently from the instance's primary ENI.
Disable Source/Destination Check and understand when this is required for exam scenarios.
Update description and termination behavior to control the ENI's lifecycle.

Modify the security groups on the secondary ENI

Security groups attach to ENIs, not directly to instances. This means an instance with multiple ENIs can have completely different firewall rules on each interface.

In production architectures, you'd apply stricter rules to a management ENI (SSH only) while keeping the primary ENI open for HTTP/HTTPS traffic. Let's demonstrate this independence by modifying the secondary ENI's security groups.

Navigate to EC2 > Network Interfaces in the left sidebar.
Select Secondary-Management-ENI by clicking its checkbox.
Click Actions in the top menu bar.
Select Change security groups.
You'll see ENI-Lab-SG currently associated. You can add or remove security groups here.
Leave ENI-Lab-SG selected (since this is a demonstration of the capability) and click Save.

Why per-ENI security groups matter for the exam

The SAA-C03 tests whether you know that security groups are associated at the ENI level. If a question describes an instance needing different inbound rules for management traffic vs application traffic, the answer involves multiple ENIs with separate security groups.

For example, your primary ENI might allow HTTP (port 80) from the internet while your secondary management ENI allows SSH (port 22) only from your corporate IP range.

You should see a success banner confirming the security groups were updated on the ENI.

Disable Source/Destination Check on the secondary ENI

Source/Destination Check is enabled by default on every ENI. When enabled, the ENI silently drops any packet where the instance is neither the source nor the destination.

This is one of the most frequently tested ENI concepts on the SAA-C03. You must disable this check whenever an instance forwards traffic on behalf of other hosts.

With Secondary-Management-ENI still selected in the Network Interfaces list, click Actions.
Select Change source/dest. check.
Uncheck the Enable checkbox to disable Source/Destination Check.
Click Save.

Verify the change by selecting the ENI and checking its Details tab at the bottom of the page.
Look for the Source/dest. check field. It should now show Disabled.

When must you disable Source/Destination Check?

Disable this check whenever an instance acts as a traffic-forwarding appliance. This includes NAT instances, VPN endpoints, firewalls, proxy servers, and any routing appliance.

With the check enabled, AWS drops packets that don't have the instance as their source or destination. This is an anti-spoofing safeguard. Disabling it on standard workload instances is a security risk, so only disable it on instances that intentionally forward traffic.

Managed NAT Gateways handle this internally. You only need to disable it manually for NAT instances you configure yourself.

Exam scenario pattern

If an exam question describes packets being "silently dropped" through a NAT instance or routing appliance, Source/Destination Check is the first thing to verify. This is a classic SAA-C03 distractor where the answer is simply disabling this one setting.

Don't see the Change source/dest. check option?

Make sure you have the ENI selected (checkbox checked) before clicking Actions. If the option is greyed out, verify this is a user-created ENI and not a requester-managed ENI created by an AWS service.

Help me troubleshoot the source/dest check option not appearing

Modify description and termination behavior

Two more modifiable attributes round out the ENI configuration options the exam expects you to know. The description helps you identify ENIs at a glance, and termination behavior controls whether the ENI survives when its attached instance is terminated.

With Secondary-Management-ENI still selected, click Actions.
Select Change description.
Update the description to Failover-ENI-Management and click Save.

Select Secondary-Management-ENI again and click Actions.
Select Change termination behavior.
Ensure Delete on termination is set to No.
Click Save.

Verify both changes by selecting the ENI and checking the Details tab.
Confirm the description now reads Failover-ENI-Management and the termination behavior shows that the ENI will not be deleted on instance termination.

Why set Delete on termination to No?

For failover ENIs, you want the interface to persist independently of any single instance's lifecycle. If StandbyServer is terminated, the ENI survives and can be reattached to a replacement instance. This is what makes low-budget high-availability architectures work.

The primary ENI (eth0) always has Delete on termination set to Yes. It's created with the instance and destroyed with it. Secondary ENIs give you the choice.

What other ENI attributes can you modify?

The full list of modifiable attributes includes: description, security groups, delete on termination, source/destination check, and idle connection tracking timeout (for TCP established, UDP, and UDP stream connections). You've now modified all the attributes commonly tested on the SAA-C03.

You've now explored every modifiable ENI attribute that the SAA-C03 tests. Next up, you'll clean up all your lab resources to avoid any ongoing charges.

Secret mission

Build a Working NAT Instance with ENI

You've mastered creating, attaching, and moving ENIs between instances. Now put everything together by building a working NAT instance that routes internet traffic from a private subnet instance through your public instance. This combines Source/Destination Check, security groups, route tables, and ENI manipulation into one real-world scenario.

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 lab are free tier eligible, but Elastic IPs that are not associated with a running instance incur hourly charges.

Cost warning

Unassociated Elastic IPs cost $0.005 per hour. If you are done with this lab, release any allocated Elastic IPs immediately to avoid unexpected charges.

EC2 instances (t2.micro or t3.micro) are free tier eligible for the first 750 hours per month. Running instances beyond that threshold will incur charges.

Resources you used:

2 EC2 instances (PrimaryServer and StandbyServer) in the public subnet.
1 standalone secondary ENI (Secondary-Management-ENI).
1 Elastic IP address associated with the secondary ENI.
1 custom VPC with a public subnet, private subnet, Internet Gateway, and route tables.

Keep everything running

No action needed. Choose this if you are still actively experimenting with ENI configurations or plan to attempt the Secret Mission.

Make sure your Elastic IP is associated with a running instance to avoid charges.
Monitor your free tier usage in the AWS Billing Dashboard to stay within limits.

Pause - I'll come back to this later

Stop your instances to free up compute charges while keeping your VPC and ENI configuration intact.

Detach the secondary ENI from whichever instance it is currently attached to.
Stop both EC2 instances (PrimaryServer and StandbyServer) from the EC2 console.
Release the Elastic IP to avoid the $0.005/hour charge for unassociated Elastic IPs.
Your VPC, subnets, route tables, and Internet Gateway have no ongoing cost and can remain in place.

Delete - I don't want to use this again

Remove all project resources completely. This is recommended if you have finished the lab and the Secret Mission.

Detach the secondary ENI from whichever instance it is attached to, then delete the ENI.
Release the Elastic IP address from the EC2 > Elastic IPs console.
Terminate both EC2 instances (PrimaryServer and StandbyServer).
Delete the custom VPC from the VPC console. This also removes the associated subnets, route tables, and Internet Gateway.
Verify in the Network Interfaces console that no orphaned ENIs remain.

Nice Work!

You just built, manipulated, and mastered Elastic Network Interfaces from the ground up. You now have hands-on experience with every ENI concept tested on the SAA-C03 exam.

Here's what you accomplished:

Created and attached a standalone ENI with an Elastic IP, then simulated a failover by moving the ENI between instances, proving that IP, MAC address, and security groups persist across moves.
Configured Source/Destination Check on an ENI, understanding when and why to disable it for NAT instances, firewalls, and routing appliances.
Modified ENI attributes including security groups, termination behavior, and description, demonstrating how ENIs enable per-interface security and lifecycle control.
Built a working NAT instance using a secondary ENI with Source/Destination Check disabled, routing private subnet traffic to the internet.

Ready to quiz yourself?