AWS Elastic Network Interfaces (ENIs) are a new feature of the AWS Cloud that allow you to create and manage virtual network interfaces in the AWS Cloud. ENIs let you create and manage multiple virtual network interfaces in the same AWS account, which can be used to isolate different parts of your application or data from each other. You can use ENIs to create a private network within your AWS account for testing or development purposes, or to connect different parts of your application or data infrastructure together. You can also use ENIs to connect your on-premises networks with the AWS Cloud. To get started with ENIs, first create an Amazon VPC. Then, add an ENI instance type to your VPC. You can use either an existing EC2 instance type or a new instance type that is specifically designed for ENI usage. After you add the ENI instance type, you need to configure it by setting up its networking settings. Once you have configured the networking settings for your ENI instance, you can start creating virtual network interfaces using the Amazon Virtual Private Cloud (VPC) Manager console. You can then use these virtual network interfaces to isolate different parts of your application or data from each other. ..

Essentially, ENIs are virtual network cards you can attach to your EC2 instances. They are used to enable network connectivity for your instances, and having more than one of them connected to your instance allows it to communicate on two different subnets.

What Are Elastic Network Interfaces?

You’re already using them if you’re running on EC2—the default interface, eth0, is attached to an ENI that was created when you launched the instance, and is used to handle all traffic sent and received from the instance.

You’re not limited to just one network interface though—attaching a secondary network interface allows you to 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 an EC2 instance, routing traffic from one subnet to another.

ENIs have 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 manage inter-subnet traffic.

A common use case for ENIs is the creation of management networks. This allows you 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 this scenario, you would connect using a VPN to the private management subnet, then administrate your servers as usual.

In this diagram, 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 can only be accessed in this example by the AWS Direct Connect gateway, which allows the on-premises network to handle authentication, and simply extends that network into the cloud. You could also use AWS Client VPN, which will run a VPN server that can be accessed with private key credentials.

ENIs are also often used as the primary network interfaces for Docker containers launched on ECS using Fargate. This allows Fargate tasks to handle complex networking, set firewalls in place using security groups, and be launched into private subnets.

According to AWS, ENIs have 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 One public IPv4 address One or more IPv6 addresses One or more security groups A MAC address A source/destination check flag A description

ENIs are entirely free to use, though they are not exempt from the standard AWS data charges.

Implementing Cheap Failover With ENIs

Because ENIs can have their association dynamically assigned, they’re commonly used to implement failover in network design. If you’re 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 over to the standby server.

ENIs can fulfill this pattern quite easily—simply launch two servers, create a secondary ENI instance to use as the switch, and associate it to the primary server, optionally with an elastic IP. Whenever you need to swap to the standby instance, you simply have to swap the ENI over (albeit manually, or with a script).

However, ENIs aren’t the best way to go about this in AWS’s ecosystem. AWS supports auto-scaling, which can be used to achieve the same effect in a more cost effective manner. Rather than paying extra for redundancy, you would instead run many smaller servers in a auto-scaling fleet. If one of the instances goes down, it isn’t a big deal. A new server can be spun up quickly to handle the drop in traffic.

While manually switching the ENI over to the standby instance is easy, automating the failover process is a lot more complicated. You’ll have to set up a CloudWatch alarm on the primary instance to fire when the instance goes down (optionally sending you a message in the process), subscribe it to an SNS message queue, and trigger a Lambda function that will run off that queue and handle the detaching and reattaching process using the AWS SDK. It’s doable, but we highly recommend looking into using Route 53 DNS failover rather than this.

If you do want to automate the process, you can follow this guide from AWS on how to link a CloudWatch alarm to Lambda.