Elastic Network Interfaces in the Virtual Private Cloud | Hacker News Reader

Elastic Network Interfaces in the Virtual Private Cloud

aws.typepad.com

36 pointsjeffbarr9 comments

I'm curious what the technology behind it is. There have been some standards based things recently (VXLAN) as well as some non-standards based (OTV, F5 DCI).

It sounds like VXLAN. VXLAN in short is encapsulating a L2 packet inside a UDP-VXLAN packet and then using multicast to route the packet to multiple switches. The same concepts of subnets still exist, it's just hacking together multiple L2 domains by multicasting between configured switches. The VXLAN header allows for identification between the different networks to specify which actual VLAN it should be mapped to. What's interesting is there are more potential VXLANs than multicast addresses so there is not a mapping between multicast address and VXLAN. As well, the actual VLAN the messages are sent to don't need to match on the other side of the VXLAN.

This is all of course assuming Amazon didn't homebrew their own L2 over L3 extension protocol. VXLAN shows promise, so it would be cool, but it is layered with multicast and broadcast complexities.

They're now allowing multiple vNICs, but they look like basically the same implementation that VPC has been using for a while; it definitely predates VXLAN. When it comes to networking, EC2 does nothing the industry-standard way.

Not sure why you would say VXLAN is any more standards-based than OTV. They're both IETF drafts. Unlike VMware with VXLAN, Cisco seems serious about completing the standardization process.

OTV draft 03 is available here: https://datatracker.ietf.org/doc/draft-hasmit-otv/

VMware submitted the initial VXLAN draft right before VMworld, and AFAIK there's been no activity since. https://datatracker.ietf.org/doc/draft-mahalingam-dutt-dcops...

Amazon out-innovating the competition again. My money is on this being an implementation of Microsoft Research's VL2, given James Hamilton was a co-author of this (http://research.microsoft.com/pubs/80693/vl2-sigcomm09-final...)

ENI seems like it would be simple to implement without VL2. Why do you think it's related?

That was an excellent read. Thanks!

Amazing. Another huge reason to go into VPC with AWS.

Their use cases they list are all good and valid (at least two apply to me personally). Additionally, this should enable some decent HA options, along the exact same lines as VIPs (except not as fast, most likely).

I'm looking forward to going to work tomorrow to play around with how long it takes after hot swapping ENIs for traffic to flow to the new instance, since for managing servers purely in AWS, this looks to be a beautiful option for server-level HA with a hot-standby.

Unfortunately, this does add even more domain knowledge necessary to jump into VPC (which is already a very non-trivial affair for those who aren't very familiar with sysadmin work/networking in general).

I'd have to say this sounds like my favorite feature launched this year behind VPC.

I love that Amazon continues to explode our previous model of computing. The entire ecosystem of PaaS providers that are built on top of AWS benefit from these advances and Amazon wins by continuing to be the platform to build a PaaS on top of.

While I'm sure it's not their aim, the AWS console and associated web interfaces are functional but have pretty terrible user experience. It's as if AWS has found this perfect customer fit... build awesome tech, build an interface just-barely-good-enough to administer it... foster the ecosystem of providers that make your tech easier to use... rake in the cash because at the end of the day everyone is running on AWS regardless of who charges their card.

the number of TLAs in that post is a little OTT.

Reply on news.ycombinator.com