I understand from the documentation with the use of Netflix Zuul & Eureka (maybe Ribbon too) you can build an active load balancer. I have always used AWS ELB, ALB (ECS for container management) with R53.
Apart from the vendor portability, Is there any advantage of using Netflix approach than using AWS provided ALB/ELB? Is there any use case you have to use Netflix OSS rather than out of the box AWS ELBs?
The load balancer does not manage client-side resiliency, such as retries, backoffs, service registry and routing. Netflix OSS offers middle-tier load balancing and several resiliency features. You would find similar features in AWS AppMesh and AWS Cloud Map. The load balacer is just the endpoint that can route clients to functions, containers or instances. Using a load balancer and service meshes (from Netflis OSS and/or AWS) certainly contribute to application reliability.
The Netflix OSS stack can work with ALB and ELB etc. For example you still need some sort of API Gateway (what Zuul allows you to implement) to protect your routes even when working with ALB or ELB. Ribbon and Eureka can be used for Service Discovery in addition (or you could simply hardcode the routes to your other microservices in the Zuul config and not bother with standing up a Eureka server). So you can use Zuul as a container which shares the same ALB as your other microservices in ECS, and have all requests from your front-end hit the route to Zuul first, and then based off of the request have Zuul decide which microservice route to proxy the request to. If you aren't using ECS or containers, this same architectural pattern works just fine for EC2 VMs as well.
