Essentially, ENI are virtual network cards that you can connect to your EC2 instances. They are used to enable network connection for your instances, and with more than one of them connected to your instance, it can communicate on two different subnets.
What are resilient network interfaces?
You are already using them if you are running on the EC2 standard interface,
eth0, is linked to an ENI that was created when you started the instance and is used to handle all traffic sent and received from the instance.
However, you are not limited to just one network interface ̵1; by connecting a secondary network interface, you can connect your EC2 instance to two networks at once, which can be very useful when designing your network architecture. You can use them to host load balancers, proxy servers and NAT servers on one EC2 instance and direct traffic from one subnet to another.
ENI has security groups, just like EC2 instances, which act as a built-in firewall. You can use these rather than a Linux firewall like
iptables, to handle inter-subnet traffic.
A common case for ENIs is the creation of management networks. This allows you to have public applications as web servers in a public subnet but locks SSH access down to a private subnet in a secondary network interface. In this scenario, you would connect with a VPN to the private management subnet and then manage your servers as usual.
In this diagram, the subnet on the left is the public subnet, which communicates with the Internet via the Internet Gateway for VPC. The subnet on the right is the private management network, which can only be accessed in this example via the AWS Direct Connect gateway, which allows the local network to handle authentication, and simply extends that network to the cloud. You can also use AWS Client VPN, which runs a VPN server that can be accessed with private key information.
ENI is also often used as the primary network interfaces for Docker containers launched on ECS with Fargate. This allows Fargate tasks to handle complex networks, set up firewalls in place with security teams and launch into private subnets.
According to AWS, ENI’s has the following attributes:
- A primary private IPv4 address from the IPv4 address range of your VPC
- One or more secondary private IPv4 addresses from the IPv4 address range of your VPC
- One elastic IP address (IPv4) per private IPv4 address
- A public IPv4 address
- One or more IPv6 addresses
- One or more security groups
- A MAC address
- A flag for source / destination
- A description
ENIs are completely free to use, although they are not exempt from the standard AWS fees.
Implement cheap failures with ENIs
Because ENIs can have their association dynamically assigned, they are typically used to implement failover in network design. If you are running a service that needs high availability, you can run two servers, a primary server and a standby server. If the primary server fails for any reason, the service can be switched to the standby server.
ENIs can fulfill this pattern quite easily – simply start two servers, create a secondary ENI instance to be used as a switch and connect it to the primary server, optionally with an elastic IP. When you need to switch to standby, you simply have to switch ENI (whether manually or with a script).
But ENIs are not the best way to do that in AWS’s ecosystem. AWS supports automatic scaling, which can be used to achieve the same effect in a more cost-effective way. Instead of paying extra for redundancy, you would instead run many smaller servers in an automatic scaling fleet. If one of the cases falls down, it is not so much. A new server can be spun up quickly to handle the reduction in traffic.
It is easy to switch ENI manually to the standby instance, but automating the failover process is a pulp more complicated. You must set a CloudWatch alarm on the primary instance to fire when the instance drops (possibly sending a message during the process), subscribe to an SNS message queue and trigger a Lambda function that will run the queue and handle the unloading and reassembly process with AWS SDK. It is feasible, but we strongly recommend that you investigate Route 53 DNS failover rather than this.
If you want to automate the process, you can follow this guide from AWS on how to connect a CloudWatch alarm to Lambda.