By using AWS re:Post, you agree to the Terms of Use
/Network Load Balancer/

Questions tagged with Network Load Balancer

Sort by most recent
  • 1
  • 90 / page

Browse through the questions and answers listed below or filter and sort to narrow down your results.

Horizontal Scaling concerns, SSL issue with NLB

note: I'm new to scaling and firstly seeking advice on the best practices for horizontal scaling **I have the following setup:** *EC2 Instances <-> ASG(created from Launch template) -> TG <-> ALB <-> TG <-> NLB* Traffic flows through NLB to ALB and finally to EC2 instances configured via ASG. note: I'm assuming the above setup is the best one to go with horizontal scaling, if not please let me know. the above setup works fine for HTTP whereas when I try to configure HTTPS, I don't see options to do so. Issue1: Target Group(TG) doesn’t allow to create one with Load Balancer type with TLS port: 443 but allows only TCP: port 80, **Question1: **how else should I redirect HTTPS traffic to ALB? note: I need NLB because ALB doesn't provide Static IPs **Question2:** wrt Static IPs: NLB doesn't allow <2 AZs which means I need to have 2 Static IPs linked to my domain? any inputs would be really helpful! **Update1:** I've configured like below: In ALB listeners: HTTP(80) gets redirected to HTTPS HTTPS(443) gets forwarded to ASG In NLB listeners: HTTP(80) gets forwarded to ALB note: ALB's public URL is added to my domain(sample-alb.domain.com) NLB's public URL is added to my domain(sample-nlb.domain.com) SSL works fine if the user enters by hitting sample-alb.domain.com whereas if the user enters by hitting sample-nlb.domain.com, it always fails with "ERR_CERT_INVALID" any inputs on why this fails? **Update2:** I've got the answer to my Issue1/Question1 on how to redirect HTTPS traffic to ALB from here: https://docs.aws.amazon.com/elasticloadbalancing/latest/network/application-load-balancer-target.html#configure-application-load-balancer-target > **Listeners and routing** > For Listeners, the default is a listener that accepts TCP traffic on port 80. Only TCP listeners can forward traffic to an Application Load Balancer target group. Keep the listener protocol set to TCP, but you can modify the port as required. > > This setup allows you to use HTTPS listeners on the Application Load Balancer to terminate the TLS protocol. so, I created a TG with TCP port 80 and listener to NLB, which redirects to ALB. (say for ex my NLB's public URL is 'nlb34323.amazonaws.com') now, when I hit my NLB's public URL with 'http://nlb34323.amazonaws.com', it does get redirected to 'https://nlb34323.amazonaws.com', but eventually fails with a timeout error. note: whereas when I hit ALB's public URL, it is working fine does it have anything to do with TLS termination as mentioned in the above documentation: > This setup allows you to use HTTPS listeners on the Application Load Balancer to terminate the TLS protocol. what am I doing wrong here?
2
answers
0
votes
6
views
Saru
asked 23 days ago

Unexpected URI while testing API gateway to NLB

I have a Private Link setup that points at an NLB that further has routes setup to an EC2 instance that provides my HTTP end point. I am trying to setup an API gateway to use the private link. I tried setting this up as proxy. This allows me to test an endpoint without authorization, and provide both path and query parameters. This is the log of the output I am seeing. ``` Execution log for request e114f111-f6b5-413d-9592-ec1ecb72d848 Mon Mar 07 19:38:02 UTC 2022 : Starting execution for request: e114f111-f6b5-413d-9592-ec1ecb72d848 Mon Mar 07 19:38:02 UTC 2022 : HTTP Method: GET, Resource Path: /api/falcfunnelsession/getInvestorResponse Mon Mar 07 19:38:02 UTC 2022 : Method request path: {proxy=api/falcfunnelsession/getInvestorResponse} Mon Mar 07 19:38:02 UTC 2022 : Method request query string: {sessionUUID=7a0e0113-05ab-4382-bed8-f91e9bc3ef3c} Mon Mar 07 19:38:02 UTC 2022 : Method request headers: {} Mon Mar 07 19:38:02 UTC 2022 : Method request body before transformations: Mon Mar 07 19:38:02 UTC 2022 : Endpoint request URI: https://funnel-backend-103-nlb-bc34d52397cf6529.elb.us-east-2.amazonaws.com?sessionUUID=7a0e0113-05ab-4382-bed8-f91e9bc3ef3c Mon Mar 07 19:38:02 UTC 2022 : Endpoint request headers: {x-amzn-apigateway-api-id=8v1qbgdlb8, User-Agent=AmazonAPIGateway_8v1qbgdlb8, Host=funnel-backend-103-nlb-bc34d52397cf6529.elb.us-east-2.amazonaws.com} Mon Mar 07 19:38:02 UTC 2022 : Endpoint request body after transformations: Mon Mar 07 19:38:02 UTC 2022 : Sending request to https://funnel-backend-103-nlb-bc34d52397cf6529.elb.us-east-2.amazonaws.com?sessionUUID=7a0e0113-05ab-4382-bed8-f91e9bc3ef3c Mon Mar 07 19:38:07 UTC 2022 : Execution failed due to configuration error: There was an internal error while executing your request Mon Mar 07 19:38:07 UTC 2022 : Method completed with status: 500 ``` The following path and query are as expected ``` Mon Mar 07 19:38:02 UTC 2022 : HTTP Method: GET, Resource Path: /api/falcfunnelsession/getInvestorResponse Mon Mar 07 19:38:02 UTC 2022 : Method request path: {proxy=api/falcfunnelsession/getInvestorResponse} Mon Mar 07 19:38:02 UTC 2022 : Method request query string: {sessionUUID=7a0e0113-05ab-4382-bed8-f91e9bc3ef3c} ``` However the URI request seems to leave out the path. ``` Mon Mar 07 19:38:02 UTC 2022 : Endpoint request URI: https://funnel-backend-103-nlb-bc34d52397cf6529.elb.us-east-2.amazonaws.com?sessionUUID=7a0e0113-05ab-4382-bed8-f91e9bc3ef3c ``` Wondering is there is something I am doing wrong here. thanks!
2
answers
0
votes
4
views
AWS-User-9282743
asked 2 months ago

Network Load Balancer stickiness seems to fail sometimes

We have a SignalR javascript client connecting to .net core hub, hosted in AWS. Both client and server use version 6. More than one backend server may exist, so there is an internet facing Network Load Balancer forwarding the traffic to the backend servers. The NLB is configured with these options: - Stickiness - Preserve client IP addresses Most of the time, everything works great: the negotiation and the connection upgrade. Sometimes, however, something strange happens: the negotiation fails (error in WebSocket transport), then the client tries again with another transport (SSE). This transport also fails and, while retrying, the client hits the other host, starting the negotiation again. Finally, the connection succeeds. All this process takes no more than 5 seconds. This was happening in our clients, from outside, so we set up an isolated environment to debug this situation, with the NLB and 2 backend hosts. This is internal, so no one else is connecting, for sure, so there is no chance hosts are overloaded. We are completely sure our IP does not change while the test is being done. We enabled client and server debug logs, shown below. This still happens sometimes, no matter the host that we hit on the first attempt. We know that we can configure the client to skip the negotiation, but that will make us lose about 10% of our clients, because we will be limited to use the WebSockets transport. From the logs, IP stickiness seems to be failing somehow... What is misconfigured in our setup? How can the negotiation fail if just one client is connecting and the IP does not change? What else can we configure in the AWS NLB to ensure the IP stickiness? Thanks in advance! **When the connection succeeds at the first attempt** ``` Client logs Debug: Starting connection with transfer format 'Text'. Debug: Sending negotiation request: https://<server>... Debug: Selecting transport 'WebSockets'. Trace: (WebSockets transport) Connecting. Information: WebSocket connected to wss://<server>... Debug: The HttpConnection connected successfully. Server logs [DBG] New connection r3Gv5PrBgTA2T6lijqwTrA created. [DBG] Sending negotiation response. [DBG] Establishing new connection. [DBG] Socket opened using Sub-Protocol: 'null'. [DBG] OnConnectedAsync started. [DBG] Found protocol implementation for requested protocol: json. [DBG] Completed connection handshake. Using HubProtocol 'json'. ``` **When the connection fails at the first attempt** ``` Client logs Debug: Starting connection with transfer format 'Text'. Debug: Sending negotiation request: https://<server>... Debug: Selecting transport 'WebSockets'. Trace: (WebSockets transport) Connecting. WebSocket connection to 'wss://<server>...' failed: Information: (WebSockets transport) There was an error with the transport. Error: Failed to start the transport 'WebSockets': Error: WebSocket failed to connect. The connection could not be found on the server, either the endpoint may not be a SignalR endpoint, the connection ID is not present on the server, or there is a proxy blocking WebSockets. If you have multiple servers check that sticky sessions are enabled. Debug: Selecting transport 'ServerSentEvents'. Debug: Sending negotiation request: https://<server>... Trace: (SSE transport) Connecting. Information: SSE connected to https://<server>... Debug: The HttpConnection connected successfully. Trace: (SSE transport) sending data. String data of length 32. POST https://<server>... 404 (Not Found) Debug: HttpConnection.stopConnection(undefined) called while in state Disconnecting. Error: Connection disconnected with error 'Error: No Connection with that ID: Status code '404''. Debug: Starting connection with transfer format 'Text'. Debug: Sending negotiation request: https://<server>... Debug: Selecting transport 'WebSockets'. Trace: (WebSockets transport) Connecting. Information: WebSocket connected to wss://<server>... Debug: The HttpConnection connected successfully. Server logs (server 1) [DBG] New connection _cm5IaOtqY7tD7suKOb08Q created. [DBG] Sending negotiation response. (1) [DBG] New connection GuXhVydEzL-8xXcSxibysA created. [DBG] Sending negotiation response. (2) [DBG] Establishing new connection. [DBG] OnConnectedAsync started. [DBG] Failed connection handshake. (server 2) [DBG] New connection RjoZW-BKBNMOa2UBW9yo-g created. [DBG] Sending negotiation response. [DBG] Establishing new connection. [DBG] Socket opened using Sub-Protocol: 'null'. [DBG] OnConnectedAsync started. [DBG] Found protocol implementation for requested protocol: json. [DBG] Completed connection handshake. Using HubProtocol 'json'. ```
1
answers
0
votes
1
views
cburaca
asked 3 months ago
  • 1
  • 90 / page