Search code examples
amazon-web-servicesrabbitmqnode-amqplib

amqplib & AWS MQ: Socket closed abruptly during opening handshake


So the current issue I have is that before I was able to connect properly to my rabbitMQ cluster that was hosted on AWS MQ. After I changed its IP visibility to private I had to create some configuration to access the cluster from outside the VPC.

Current example of how the cluster is accessed:

mq.example.com -> Load balancer (w/target group to cluster host IP & TLS port 5671) in public VPC -> Cluster in private VPC.

I've done the same thing for the web console. Now the web console works perfectly, so the issue isn't necessarily with the load balancing or a certificate issue. I then checked out if the issue could be with the code I wrote, but that is also not the case since sometimes from inside the services it connects, but sometimes it then doesn't. It throws the error: "Socket closed abruptly during opening handshake".

I think I believe where the issue may arise from, however I don't really have a proper view on how to solve it. I believe the issue has to do with the fact that the service has go through the load balancer first before it can connect to the rabbit cluster. I just don't know what to do about it and most documentation on amqplib is obscure as it is. I haven't found any (documented) similar issue with AWS MQ & a load balancer.

So my question, specifically is: How would I be able to resolve the fact that sometimes my services connect and don't connect to the cluster when they go through the load balancer?

Good to know: I use AWS MQ for rabbit, amqplib for the client connection, amqps as the protocol, web console works with the same setup but services don't.


Solution

  • For people who run into this issue later on I have found a solution:

    When creating a Network Load Balancer to route traffic to your cluster you have to assign it a target group. Make sure to NOT DO THIS: Do not register both port 5671 (amqps) and 443 (web console) to the same target group. During routing issues will arise like this.

    Instead do the following:

    Create two target groups on aws EC2:

    TG1: Register: TLS - 443 (web console) TG2: Register: TLS - 5671 (amqps)

    Your NLB that is configured to simple routing & alias for IPV4 connections then needs the following listeners:

    Listener 1: TLS - 443 and assign it to TG1 Listener 2: TLS - 5671 and assign it to TG2

    This should then make sure whenever you connect there is no confusion for the microservice you're trying to connect to the cluster.

    You can then connect to your web console with your subdomain: eg. webconsole.example.com

    and to your services: eg. amqps://cluster.example.com:5671 as host (how your host is formatted depends on the library you're using for the clientside)