Networking plays an important role in connecting the components of infrastructure. AWS networking feature works with various types of workloads and provides security, availability, and manageability. Now as most of the IT companies are working on cloud environments for cost reduction, high availability, data security, we are getting some interesting networking features as services. We can manage these quite easily too. Among those services is Elastic Network Interface (ENI) which we get by default when we create an EC2 instance on AWS and can be seen while the instance is being created. It may surprise many of us that the security group is attached to this elastic network interface.
What is a elastic network interface ?
An elastic network interface is a logical networking component that connects computers and servers over the internet without the conventional physical cabling and other hardware, it is a component in a VPC that represents a virtual network card. We can use ENIs to deploy high availability clusters and perform low-cost failover and fine-grained network management.
ENIs are further classified into two types:
- Primary ENIs: Gets created with the instance. The lifecycle of a primary ENI is the same as of the instance to which this ENI is attached. We can not detach the primary ENI from its instance.
- Secondary ENIs: Can be created separately. We can attach or detach the secondary ENI from an instance.
ENI consists of the following
- A primary private IP address.
- One or more secondary private IP addresses.
- One elastic IP address per private IP addresses.
- One public IP address, which can be auto-assigned only to the primary elastic network interface eth0.
- One or more security groups.
- A MAC address.
Features of ENIs
- In addition to the primary ENI that gets created with the instance, we can also attach multiple secondary ENIs to the instance. But the secondary ENI must reside within the same zone and VPC, though it can belong to different security groups.
- When we detach a secondary ENI from an instance and attach it to another instance, the attributes of the ENI remain unchanged and the network traffic is redirected to the new instance.
- ENIs can be migrated among instances. When we attach a secondary ENI to an instance, services on the instance are not affected, and we do not need to restart the instance.
- Low-cost failover: We can detach ENI from a failed instance and attach it to a backup instance, traffic will be redirected to the backup instance. This allows quick recovery of services.
- Network management: We can configure multiple ENIs for an instance. For example, one ENI can be used for internal management and another ENI for internet business access to isolate management data from business data. Specific Security group rules can be configured for each ENI based on the source IP addresses, protocols, and ports. For example, Primary ENI eth0 handles the backend with more restrictive control and Secondary ENI eth1 handles the public-facing traffic.
- Configuration of multiple private IP addresses for a single instance: If multiple applications are managed on an instance, we can assign multiple secondary private IP addresses to an ENI so that each application will have an independent IP address.
Now we are going to see one of the use cases of ENIs which I found to be very useful to create a dual-homed environment for our web, application, and database servers. This allows us to have public-facing applications like web servers in a public subnet but lock down SSH access down to a private subnet on a secondary network interface.
In the diagram above, the subnet on the left is the public subnet, which communicates with the internet over the internet gateway for the VPC. The subnet on the right is the private management subnet, which allows the on-premises network to handle authentication and simply extends that network into the cloud. The instance’s first ENI would be attached to a public subnet, routing 0.0.0.0/ (all traffic) to the VPC’s Internet Gateway. The second ENI would be attached to the private subnet, with 0.0.0.0 routed to the VPN Gateway connected to the corporate network. A private network would be used for SSH access, management, logging, and so forth. Traffic on port 80 is allowed through the first ENI and traffic from the private subnet on port 22 is allowed through the second ENI.
So in this blog, I have covered the introductory part of AWS Elastic Network Interfaces. In the next blog, I will be explaining the Network Management diagram (above) in a much detailed and in step-by-step manner. It will help one to create the whole setup in their own environment. If you guys have any ideas or suggestions around my approach, please comment in the comment section. I would really appreciate your suggestions and feedback. Thanks for reading.
Opstree is an End to End DevOps solution provider