AWS allows you to attach multiple elastic network interfaces (ENIs) to an EC2 instance. Other than "making it look like an on-prem server", are there any cases where multiple ENIs are actually required?

I've considered the reasons one would do this in an on-prem environment, but none of these seem to apply to AWS:

  • Link aggregation
  • Link redundancy
  • Separate management interfaces
  • In-line IDS/IPS
  • In-line firewall

The AWS implied router always "sits" between each ENI and everything else, so it isn't possible to place another instance (running, say, a sniffer) in-line.

Amazon's own documentation isn't even clear on why you'd want multiple ENIs on an instance. It just says multiple interfaces are "useful when you want to:"

Create a management network.
Use network and security appliances in your VPC.
Create dual-homed instances with workloads/roles on distinct subnets.
Create a low-budget, high-availability solution.

But it doesn't explain why ENIs are required or even desirable for those use-cases. (It's obvious multiple ENIs would be required for dual-homed instances on different subnets, but it doesn't explain why you'd ever want a dual-homed instance in the first place).

The only use-case I can come up with is an instance running containers (i.e. Docker) and you want to map individual containers to host IP addresses in different subnets.

What are the use-cases for multiple ENIs, if any?

  • Network separation (not only for management), NIDS and firewalls all 3 applies. In fact since micro segmentation is someday, it should be considered much more in virtual networks. (And yes you can route to your own multi legged hosts) – eckes Sep 1 '17 at 0:20
  • @eckes Can you explain how NIDS and firewall instances require multiple ENIs? Having multiple ENIs mimicking on-prem (v)NICs seems to be a step away from microsegmentation. – user65237 Sep 1 '17 at 1:01
  • Works the same way as physical nics, you can route through hosts with multiple NICs. – eckes Sep 1 '17 at 9:46
  • The low-budget HA solution probably refers to Cluster Services which check for dedicated HA interfaces. – eckes Sep 1 '17 at 9:48
  • Yeah, that's what I figured. I don't see a technical reason that would require a separate interface, unless the software just arbitrarily requires it. – user65237 Sep 6 '17 at 23:22

Two great uses for ENI's:

  • You want to fail-over a public EIP. Have an instance on standby monitor keepalives and steal the interface if a primary goes down.

  • Inter-VPC routing, IE. Application firewall, IPS/IDS, VPN router, security gateway, etc.

  • 1
    These are indeed good use cases for ENIs, but the question was whether multiple ENIs attached to an instance are ever required. – user65237 Sep 22 '17 at 15:14
  • @BenPiper those are "Two great uses for [multiple] ENI's". You cannot attach an EIP to an Instances default ENI and then detach it. You cannot detach the default. You need a second EIP ENI to be able to swap around an EIP with it. It's very convenient because moving the ENI is faster than re-associating the EIP. Also, it doesn't make sense to have more than one ENI in a VPC, but if you're running multiple VPCs, and you have router/firewall instances, then it makes sense to keep a separate interface per participating VPC. – Daryl Metzler Sep 25 '17 at 13:58
  • If the instance couldn't be terminated, then yes, you wouldn't be able to detach the primary ENI. When you say it's faster to move the ENI than to reassociate an EIP, are you referring to the web console or doing it programmatically? – user65237 Sep 26 '17 at 21:41
  • > If the instance couldn't be terminated, then yes, you wouldn't be able to detach the primary ENI. No, that's true either way. And as far as whether you're using the console or api, they're equivalent. There's a pretty long delay after re associating an EIP before the traffic rolls over (its probably only a few seconds), compared to an ENI, where it seems almost instant. Don't quote me as a source on that though. I haven't profiled it to the millisecond or anything. – Daryl Metzler Sep 27 '17 at 6:07

The use cases are software that demand to have one "outside/Internet" interface and one "inside/private" interface or when doing that makes the software/OS easier to configure, which is lots of firewall/proxy appliances . I personally have used them with the Cisco CSR and netscaler marketplace AMIs as you end up with config that looks like the config I'm used to seeing outside of aws.(I also ended up adding a second Internal interface doing this on one of our webservers when debugging as it meant that when doing a packet capture on this internal interface I could see the traffic between it and it's downstream dependencies (DB, LDAP) without having to filter out the traffic to and from the internet which simplified both doing the capture and gave me more meaningful SNMP metrics from the OS.


AWS has built in resiliency for outages with it's ENIs. However there may be instances were you want to have multiple ENIs on a server.

For instance, a message transfer agent (MTA) server with multiple outbound IP addresses may want to run multiple ENIs on a server so that it can handle more mail sending without being hit into spammer flags.

As @Nath pointed out, you may also want multiple ENIs to operate your server as a firewall, and have a bridge between two interfaces to perform some packet inspections.

There isn't ever any 'need' to have multiple ENIs on an instance in terms of usability from AWS, however there may be times where you 'need' multiple ENIs to perform a task of your bidding.

Hope that helps!


You can launch an instance with an interface in a private subnet. You could later attach an ENI in a public subnet in order to allow traffic to it inbound from the Internet. You would need 2 ENIs to make that happen.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy