Elastic Network Interfaces (ENIs) — Master Multi-NIC Architecture & NAT Instance Demo | AWS Lab 2026

Introduction

Here’s something that caught me off guard during my first year as an AWS architect: I spent three hours debugging why a firewall appliance wasn’t routing traffic correctly, only to discover someone had forgotten to disable the Source/Destination check on the ENI. Three hours. Coffee-fueled frustration. All because of a single checkbox.

That incident taught me something important — Elastic Network Interfaces aren’t just “network cards for EC2.” They’re the backbone of every serious AWS networking architecture, and misunderstanding them will cost you time, money, and probably some sleep.

This lab teaches you what ENIs actually do, how to manipulate them, and why they matter when you’re building anything beyond a single-instance hobby project. You’ll attach secondary ENIs, move them between instances, configure a NAT instance, and understand the infamous Source/Destination check that trips up even experienced engineers.

Who should work through this lab? Anyone moving beyond basic EC2 deployments. If you’re planning to work with network appliances, high-availability architectures, or multi-homed instances, this is foundational knowledge. DevOps engineers preparing for AWS certifications will find this particularly valuable — ENI questions appear regularly on the Solutions Architect and SysOps exams.

Common beginner mistakes I see constantly:

• Assuming ENIs are permanently bound to instances (they’re not — that’s the whole point)
• Forgetting that ENIs are AZ-specific resources
• Leaving Source/Destination checks enabled on NAT instances
• Not understanding that security groups attach to ENIs, not directly to instances

Let’s fix those knowledge gaps.

Lab Overview

By the end of this lab, you’ll have hands-on experience with the following:

What you’ll build: A working NAT instance architecture where a private subnet routes outbound internet traffic through an EC2 instance acting as a network gateway. You’ll create secondary ENIs, move them between instances, and validate traffic flow.

Skills you’ll gain:

• Creating and managing standalone ENIs in the AWS Console
• Attaching and detaching ENIs from running instances
• Configuring Source/Destination checks for network appliances
• Setting up basic NAT functionality using EC2
• Validating network connectivity and troubleshooting routing issues

Where this knowledge becomes critical:

• High availability: Failover architectures often move ENIs (and their IPs) to standby instances
• Network appliances: Firewalls, load balancers, and intrusion detection systems require multi-NIC configurations
• NAT instances: Cost-effective alternative to NAT Gateways for dev/test environments
• Licensing: Some software licenses bind to MAC addresses, which persist with ENIs

Prerequisites

Before starting, confirm you have:

• An AWS account with console access
• An existing VPC with at least one public subnet and one private subnet (both in the same Availability Zone)
• Two EC2 instances — one in the public subnet, one in the private subnet
• IAM permissions for EC2 and VPC operations (the AmazonEC2FullAccess managed policy works, though it’s broader than necessary)
• Basic familiarity with EC2 instance launching and VPC concepts
• SSH access configured for both instances

If you completed the previous labs in this series, your environment should already meet these requirements.

Step-by-Step Hands-On Lab

Step 1: Navigate to Network Interfaces

What to do: Open the EC2 Console, then select Network Interfaces from the left navigation panel under the Network & Security section.

Why this matters: Network Interfaces is where ENIs live as standalone resources. Most engineers only see ENIs through the instance details page, but managing them directly gives you much more control.

What you should see: A list of existing ENIs. You’ll notice each of your EC2 instances already has a primary ENI attached — AWS creates these automatically during instance launch.

Console path: EC2 Dashboard → Network & Security → Network Interfaces

Step 2: Create a Secondary ENI

What to do: Click Create network interface. Configure it with these settings:

• Description: Secondary-ENI-Lab
• Subnet: Select your public subnet (must match the AZ of the instance you’ll attach it to)
• Private IPv4 address: Leave as “Auto-assign” for now
• Security groups: Select the same security group your public instance uses

Click Create network interface.

Why this matters: You’re creating an ENI as an independent resource. This ENI can be attached to any instance in the same AZ, detached, moved, and reattached — all while preserving its private IP, MAC address, and security group associations.

What you should see: The new ENI appears in the list with status “available” and no attached instance.

Common misconfiguration: Selecting a subnet in a different AZ than your target instance. ENIs cannot cross Availability Zones. If you try to attach it later, you’ll get an error about AZ mismatch.

Step 3: Attach the ENI to Your Public Instance

What to do: Select your new ENI, click Actions → Attach. Choose your public subnet EC2 instance from the dropdown.

Why this matters: Your instance now has two network interfaces — like a server with two physical NICs. Each interface has its own private IP, MAC address, and security group rules.

What you should see: The ENI status changes to “in-use” and shows the attached instance ID.

Step 4: Verify the Secondary IP Inside the Instance

What to do: SSH into your public instance and run:

ip addr

What you should see: Two network interfaces listed (typically eth0 and eth1), each with its own private IP address.

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
    inet 10.0.1.50/24 ...
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
    inet 10.0.1.75/24 ...

Why this matters: The operating system sees both interfaces. For most use cases, the primary interface handles traffic, but you can configure routing policies to use specific interfaces for specific destinations.

Run this command to see the route table:

ip route

Step 5: Detach the ENI

What to do: In the EC2 Console, select your secondary ENI, click Actions → Detach, then confirm.

Why this matters: This demonstrates ENI mobility. The instance continues running with its primary ENI — no reboot required. The secondary ENI returns to “available” status, ready for reattachment.

Common mistake: Trying to detach the primary ENI. AWS won’t let you — the primary ENI is permanently bound to the instance lifecycle. Only secondary ENIs can be detached from running instances.

Step 6: Attach the ENI to a Different Instance

What to do: With the same ENI selected, click Actions → Attach and choose a different instance in the same AZ.

What you should see: The ENI now shows attached to the new instance. If you SSH into that instance and run ip addr, you’ll see the secondary interface with the same private IP it had before.

Why this matters: The IP address followed the ENI, not the instance. This is how failover architectures work — move the ENI to a standby instance, and traffic continues flowing to the same IP.

Step 7: Disable Source/Destination Check

What to do: Select your ENI attached to the instance that will become your NAT instance. Click Actions → Change source/dest. check. Uncheck Enable and save.

Why this matters: By default, EC2 drops traffic where the instance isn’t the source or destination. NAT instances forward traffic on behalf of other instances — they need this check disabled or they’ll silently drop forwarded packets.

Console path: Network Interfaces → Select ENI → Actions → Change source/dest. check

This single setting has caused more troubleshooting sessions than I can count. If your NAT or routing appliance isn’t working, check this first.

⚠️ Production Warning: Never disable Source/Destination checks on regular application instances. Only network appliances — NAT instances, firewalls, proxies, and load balancers — should have this disabled. Disabling it on application servers creates security blind spots and breaks AWS’s built-in anti-spoofing protection.

Step 8: Configure the NAT Instance

What to do: SSH into your public instance (which will act as the NAT instance) and enable IP forwarding:

sudo sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf

Then configure iptables for NAT:

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT

Why this matters: IP forwarding allows the kernel to route packets between interfaces. The iptables rules perform NAT translation so private instances can reach the internet through this instance’s public IP.

Step 9: Update Route Tables

What to do: Go to VPC Console → Route Tables. Select the route table associated with your private subnet. Add a route:

• Destination: 0.0.0.0/0
• Target: Select your NAT instance (or its primary ENI)

Why this matters: This tells instances in the private subnet to send internet-bound traffic to your NAT instance instead of trying to reach an internet gateway directly (which they can’t, since they’re private).

Step 10: Test Outbound Connectivity

What to do: SSH into your private subnet instance (you’ll need to jump through the public instance or use Session Manager). Run:

curl ifconfig.me

What you should see: The public IP of your NAT instance — not the private instance’s own IP (which doesn’t exist publicly).

Also verify:

ping 8.8.8.8
curl -I https://aws.amazon.com

Real Lab Experiences: Architect Insights

Let me share some battle scars from production environments.

The silent failure: An engineer configured a NAT instance perfectly — forwarding enabled, iptables rules applied, route tables updated. Nothing worked. After an hour of packet captures, we discovered the Source/Destination check was still enabled. The packets were being dropped before they ever reached the kernel. No errors, no logs, just silence.

Security group confusion: ENIs have security groups, not instances. When an instance has multiple ENIs, each can have different security groups. I’ve seen engineers add rules to the wrong ENI’s security group and wonder why traffic still fails.

AZ mismatch disasters: During a failover test, the standby instance was in a different AZ than the primary. The ENI attachment failed, and automatic failover didn’t work. Always verify your ENIs and target instances share the same Availability Zone.

Advice for juniors: Before touching production ENIs, understand that detaching an ENI drops all active connections using that interface. Plan maintenance windows accordingly.

Validation and Testing

Confirm your setup works with these commands on the private instance:

# Verify outbound internet access
curl -s ifconfig.me
# Should return the NAT instance's public IP

# Check DNS resolution
nslookup aws.amazon.com

# Verify routing
ip route
# Should show default route pointing to NAT instance's internal IP

On the NAT instance, verify packet forwarding:

sudo iptables -L -v -n
# Check packet counters are incrementing on FORWARD chain

Troubleshooting Guide

ENI attachment fails with AZ error:
The ENI and target instance must be in the same Availability Zone. Check both resources and create a new ENI in the correct AZ if necessary.

NAT traffic not flowing:
Run this checklist in order:

1. Source/Destination check disabled on NAT instance ENI?
2. IP forwarding enabled? (cat /proc/sys/net/ipv4/ip_forward should return 1)
3. iptables rules applied? (sudo iptables -t nat -L)
4. Private subnet route table points to NAT instance?
5. Security groups allow required traffic?

Can’t reach metadata service:

curl http://169.254.169.254/latest/meta-data/

If this fails, check that your route table isn’t sending link-local traffic to the NAT instance. Also verify IMDSv2 settings — if IMDSv2 is enforced (which is now the AWS default for new instances), you’ll need token-based access:

TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/

Misconfigured IMDSv2 can break automation scripts and diagnostic tools that expect the older IMDSv1 behavior.

Debugging with AWS CLI:

aws ec2 describe-network-interfaces --network-interface-ids eni-xxxxx

Check the SourceDestCheck field — should be false for NAT instances.

AWS Interview Questions: Elastic Network Interfaces

These questions come up regularly in AWS Solutions Architect, SysOps, and DevOps Engineer interviews. I’ve asked variations of these when hiring, and I’ve been asked them myself.

Q1: What is an Elastic Network Interface, and how does it differ from a physical NIC?

An ENI is a virtual network interface that you can attach to EC2 instances. Unlike physical NICs, ENIs exist as independent AWS resources — you can create them separately, move them between instances, and they persist even after the attached instance terminates. Each ENI retains its private IP address, MAC address, security group associations, and Elastic IP (if assigned) throughout its lifecycle. This portability enables failover architectures where the same IP can move to a standby instance within seconds.

Q2: Can you attach multiple ENIs to a single EC2 instance? What are the limitations?

Yes, you can attach multiple ENIs to an instance, but the maximum number depends on the instance type. Larger instances support more ENIs — a t3.micro supports only 2 ENIs, while an m5.24xlarge supports 15. All ENIs attached to an instance must be in subnets within the same Availability Zone. The primary ENI cannot be detached from a running instance, but secondary ENIs can be attached and detached without stopping the instance.

Q3: Explain the Source/Destination check and when you would disable it.

By default, EC2 performs Source/Destination checking on all ENIs, dropping any traffic where the instance isn’t the packet’s source or destination. You disable this check when the instance needs to forward traffic for other hosts — specifically for NAT instances, firewalls, VPN endpoints, proxy servers, and any network appliance that routes traffic. Without disabling this check, forwarded packets get silently dropped at the hypervisor level before reaching your instance’s network stack.

Q4: How would you implement high availability using ENIs?

Create a secondary ENI with an Elastic IP attached, and configure your application to use that ENI’s IP address. When the primary instance fails, detach the ENI and attach it to a standby instance in the same AZ. The IP address moves with the ENI, so clients continue connecting to the same address without DNS changes. For cross-AZ failover, you’d need to use Elastic IPs with DNS updates or Route 53 health checks instead, since ENIs cannot move between AZs.

Q5: What happens to an ENI when you terminate the instance it’s attached to?

It depends on how the ENI was created. ENIs created automatically during instance launch (the primary ENI) get deleted when the instance terminates. ENIs you create manually and attach as secondary interfaces persist after instance termination — they return to “available” status and retain all their attributes. This behavior is controlled by the “Delete on termination” attribute, which you can modify.

Q6: A junior engineer asks why their NAT instance isn’t working. Walk through your troubleshooting approach.

First, verify Source/Destination check is disabled on the NAT instance’s ENI — this catches about 60% of NAT issues I’ve seen. Second, confirm IP forwarding is enabled at the OS level (cat /proc/sys/net/ipv4/ip_forward should return 1). Third, check iptables has the MASQUERADE rule on the NAT table. Fourth, verify the private subnet’s route table has 0.0.0.0/0 pointing to the NAT instance. Fifth, confirm security groups allow the required traffic on both the NAT instance and the private instances. Work through these systematically — rushing leads to missed steps.

Frequently Asked Questions (FAQs)

Security: Apply least-privilege security groups to each ENI. Don’t share security groups between public-facing and internal ENIs unless necessary. Tag ENIs clearly to identify their purpose.

Reliability: For production NAT, use NAT Gateway instead of NAT instances — it’s managed, highly available, and scales automatically. Use NAT instances only for dev/test or when you need custom packet inspection.

Cost optimization: NAT instances can be cheaper than NAT Gateways for low-traffic environments. Use smaller instance types (t3.micro) for development. Remember that NAT Gateway charges per GB processed.

Operational excellence: Document which ENIs can be moved for failover. Test ENI failover procedures during maintenance windows, not during incidents.

Tagging strategy:

Name: prod-nat-primary-eni
Environment: production
Purpose: nat-gateway
Failover-Group: nat-cluster-1

Conclusion and Next Steps

You’ve now worked hands-on with Elastic Network Interfaces — creating them independently, attaching and moving them between instances, and configuring a working NAT instance. You understand why Source/Destination checks matter and how ENIs enable multi-NIC architectures.

This knowledge applies directly to production AWS work: high-availability failovers, network appliance deployments, and cost-effective NAT configurations all rely on ENI manipulation. When you encounter a routing issue in production, you now have the mental model to troubleshoot it systematically.

Next up: Lab 2.4 takes you into Network ACLs (NACLs), the stateless subnet-level firewall that complements security groups. You’ll learn how NACLs and security groups interact, configure explicit deny rules, and understand when to use each.

Related post: {link to Lab 2.4 — Network ACLs (NACLs) Deep Dive}

External Reference: AWS ENI Documentation

This lab is part of the AWS VPC Networking series on thedevopstooling.com. Work through the complete series to build production-ready networking skills.