7

I plan to host a GitLab instance on AWS. My only problem is the frontend loadbalancer.

For git work we need HTTPS and SSH, both using the same host name.

  • The Application Load Balancer (ALB) supports HTTPS termination with ACM certificates (which we need) but no TCP forwarding for SSH.
  • The Network Load Balancer (NLB) supports TCP forwarding, but it isn't a good choice for HTTPS.
  • There is the option of using the Classic Load Balancer, since it supports HTTP, HTTPS and TCP listeners, but should I really use that in 2021? And it also does not support HTTP/2 (would be a nice to have)

I also thought about cascading an ALB behind an NLB: Network Load Balancer listens to TCP 22, 80 and 443, forwarding 22 to GitLab and the other two to an ALB which does the HTTPS termination (and the HTTP to HTTPS redirect) But that would require a complicated setup with a Lambda to update the ALB's IPs in the NLB's Target Groups, as described here: https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/

Is there an elegant solution or do I have to use a Classic Loadbalancer?

NerdyMcNerd
  • 174
  • 1
  • 7
  • 1
    Is it necessary to use a Load Balancer in the first place? If you’re only running one instance you might as well use an Elastic IP, set up a DNS record directly to that IP and be good to go (e.g. using a Let’s Encrypt certificate). – rauberdaniel Mar 11 '21 at 12:50
  • 1
    I also taught about directly exposing the Instance and do everything there. But that does not meet my Boss's security expectations. – NerdyMcNerd Mar 11 '21 at 12:54
  • 1
    You can actually do TLS-Termination for a TCP endpoint with an NLB, so you could set up the ELB with a TLS-Listener on Port 443, that sends traffic to port 80 of GitLab and another listener on port 22 that forwards the traffic to gitlab. – Maurice Mar 11 '21 at 13:17
  • Maybe you can create a very small instance for jump server in the public subnet, and protect it with a security group, so when you need to log into the server, you update the IP in the security group to yours, start the instance and do whatever you plan to do. – Random Dude Mar 15 '21 at 12:23

1 Answers1

8

After some further reading and trying I came to the conclusion that I'll use a Classic Loadbalancer.

Reasons:

  • Classic Loadbalancers are not officially deprecated
  • AWS states in their Documentation that Support for HTTP(S) and TCP is one of the reasons to choose a Classic Loadbalancer
  • Using a Network Loadbalancer for HTTP(S) termination and TCP is possible, but Network loadbanalcers do not support Security Groups (which is an explicit requirement in my case)

Edit:

AWS just announced that they now support ALB as a target for an NLB. With this feature, the setup with cascading the two loadbalancers, with the NLB forwarding HTTP/HTTPS to the ALB is the preferable one.

Here is the Announcment on AWS Blog: https://aws.amazon.com/de/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/

NerdyMcNerd
  • 174
  • 1
  • 7
  • For the edit (AWS blog 27 SEP 2021: ALB as a target for an NLB for HTTP/HTTPS), is there yet still a limitation preventing also ElasticBeanStalk as http-targets for the ALB, in this configuration (NLB -> ALB -> ElasticBeanStalk), so the ALB does the HTTPS termination/cert? – bk-se May 19 '22 at 17:21