Are multiple ENIs ever required for AWS EC2 instances?

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?

Solution 1:

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.

Solution 2:

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.