Configuring Internet-Facing NLB to Route Traffic to Internal ALB with Context Path-Based Routing

0

I am running two distinct applications, each with context paths '/app1' and '/app2,' on Amazon EC2 instances that do not have public IP addresses. To manage incoming traffic, I have set up an internal Application Load Balancer (ALB) that performs context path-based routing across multiple target groups. Other than the above mentioned context path, I don't have any application running on root context path "/".

When I SSH into one of the EC2 instances and make a CURL request using the ALB's DNS name, everything works as expected. However, I am now seeking guidance on how to configure an Internet-facing Network Load Balancer (NLB) to effectively route traffic to this internal ALB.

My goal is to make these applications accessible via the internet by directing traffic through the NLB while preserving the context path-based routing performed by the internal ALB. Any assistance on the configuration steps and best practices for achieving this would be greatly appreciated.

1 Answer
0

Hello.

Since you can set ALB as the target of NLB, I think you should set NLB to public.
https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-type

Please refer to the following document for the setting method.
https://repost.aws/knowledge-center/alb-static-ip

profile picture
EXPERT
answered 7 months ago
  • My NLB is internet facing so by default it will make it public. I have created target group named "alb-tg" with ALB as target type. Same target group I am passing as target for the NLB. But for the health configuration inside "alb-tg", I need to pass either "/app1" or "/app2" for health check path to route traffic from NLB to ALB. If I pass "/" under health check path then it's not working.

  • Yes, as you know, you cannot register multiple health check passes, so you need to register either "/app1" or "/app2". Another method is to create a health check path on the application side and make it pass the ELB health check. For example, if you create a path called "/health" on the application endpoint and a GET request is made to that path, requests will be sent to "/app1" and "/app2", and if there is a normal response, the status will be How about creating an application for the "/health" path to return code 200?

  • Yes, as you know, you cannot register multiple health check passes, so you need to register either "/app1" or "/app2".

    I agree but there should be alternative and a stable way to check all the microservices are healthy. Isn't it?

    Another method is to create a health check path on the application side and make it pass the ELB health check. For example, if you create a path called "/health" on the application endpoint and a GET request is made to that path, requests will be sent to "/app1" and "/app2", and if there is a normal response, the status will be How about creating an application for the "/health" path to return code 200?

    Sorry didn't understand fully. If we have HTTP GET "/health" endpoint set for all the applications still context path set for the app will be appended as prefix. Ex. "/app1/health", "/app2/health". As there are no app running with root context path "/" we can't set health-check path to "/health"

  • Rather than creating "/health" under "/app1" or "/app2", it feels like adding a new health check application as "/health". This means creating a health check application that can react to health checks from the load balancer, and adding an application that returns status code 200 if "/app1" and "/app2" are normal.

  • Got your point. But is it viable to implement in this way. What if microservices grow in future? Do we have any official article from AWS on how to system design microservices architecture with the use of ALB and NLB?

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions