Understanding the Elastic Network Interface (ENI) is essential for grasping AWS networking. This is because everything launched within a VPC (like EC2 instances) must have an ENI. While you might not think about them often, knowing they exist is incredibly helpful for troubleshooting and verifying behavior. Let's dive into some specific examples.
What is an ENI?
First, let's quickly review what an ENI is.
An elastic network interface is a logical networking component in a VPC that represents a virtual network card. You can create and configure network interfaces and attach them to instances that you launch in the same Availability Zone.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html
Essentially, it's a virtual network card. It's most commonly discussed in the context of being attached to EC2 instances. In most cases, its lifecycle matches that of the EC2 instance, so you rarely need to think about it.
Where ENIs are Useful
Consider load balancers like an Application Load Balancer (ALB). You can't see their underlying infrastructure (the instances) from the console. However, as mentioned earlier, anything launched in a VPC has an ENI. This means you can see the ENIs attached to the load balancer's underlying instances in the console.
By looking here, you can determine how many instances the load balancer is running and which Availability Zones (AZs) they are deployed in. It might not be a common task, but if you're changing the subnets for your load balancer, you can watch these ENIs to confirm the replacement process.
Let's look at another example. Some services have special VPC connection settings. Amazon Quick Sight is one of them. You need Quick Sight permissions to check its VPC connection settings, but you can see all the relevant information just by looking at the ENI.
Connectivity issues are common with these types of inter-service connections, so remembering that you can see valuable information on the ENI side is useful.
To summarize, the great thing about ENIs is that they allow you to indirectly observe resources that aren't directly visible in the console.
Application: Accessing the Internet from AWS CloudShell in a VPC
This might feel a bit like a "hack," but it's an idea I had during a recent troubleshooting session. CloudShell can be launched within a VPC. It can access the internet if it's in a private subnet that has a route to a NAT Gateway in a public subnet.
Your AWS CloudShell environment can only connect to the internet if it is in a private VPC subnet.
https://docs.aws.amazon.com/cloudshell/latest/userguide/using-cshell-in-vpc.html
This is because a public IP is not automatically assigned to its ENI.
Recently, I was troubleshooting and launched CloudShell in a public subnet. I needed to access the internet from this CloudShell session, and that's when I remembered the ENI. I thought, "If it doesn't have a public IP, why not just attach one?" I allocated an Elastic IP (EIP) and attached it to the CloudShell's ENI. It worked perfectly, and I was able to connect to the internet.
Summary
By looking at ENIs, you can start to see things that were previously invisible. Knowing that "everything launched in a VPC has an ENI" makes you stronger at network troubleshooting.
Remember: Mastering ENI is mastering your VPC network.
Top comments (0)