Answers: <p>Given that the Cloudfront is configured to receive external traffic on 443 and send to port 3000, and that the LB responds to a netcat socket connect the problem is on the application server</p>
  <p>The application that is on a server in the backend group for the LB is not running correctly.  Maybe it is responding really slowly.  This is what a 504 usually suggests.  If it was a security group then that would be 502 bad gateway, if the backend group was missing instances then that would be 503 service unavailable.</p>
  <p>As the server is able to be a member of the backend group the health check http path must be working correctly on the server and talking back to the LB.</p>
  <p>Look in your application server logs for 200 from the healthcheck and for any trace of the 504 requests.</p>
  <p>There is probably an issue in the application server configuration or a bug in the under lying software</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-01-07T18:53:21.507Z
Answers: 2023-01-07T18:53:21.507Z
Answers: Vorsprung
Body: <p>I am aware that it is straightforward to use <code>AWS CloudFront</code> with an AWS <strong>Application</strong> Load Balancer (Layer 7) origin (using a certificate in each for E2E encryption). However, is it possible to use <code>AWS CloudFront</code> (with certificate) and an AWS <strong>Network</strong> Load Balancer (Layer 4) origin to distribute HTTP over non-standard ports (in this case, TCP 4000 and TCP 3000)?</p>
  <p>I have implemented CloudFront with a Network Load Balancer origin. When queried, a 504 is generated by CloudFront (TCP 443 &gt; TCP 3000), which suggests a timeout.</p>
  <p>I have confirmed that there are no issues with the security group and network load balancer configuration using <code>nc</code> (for example, <code>nc -zv lb-rswvin-XXXXX.elb.XXXXX.amazonaws.com 4000</code> returns <code>Connection to lb-rswvin-XXXXX.elb.XXXXX.amazonaws.com (X.X.X.X) 4000 port [tcp/*] succeeded!</code>)</p>
  <p>I am open to alternative solutions/suggestions (e.g. a dedicated EC2 instance acting as a reverse proxy) but prefer to use a native AWS service/feature.</p>
  <p>All infrastructure was deployed using IaC (Terraform).</p>
  
Tags: <amazon-web-services><terraform><amazon-cloudfront>
Title: Does AWS CloudFront work with a Network Load Balancer?
UserDisplayName: BigotesDeGato
ThreadText: # Does AWS CloudFront work with a Network Load Balancer?
  
  (Asked by: username_0 on 2023-01-03)
  
  I am aware that it is straightforward to use `AWS CloudFront` with an AWS **Application** Load Balancer (Layer 7) origin (using a certificate in each for E2E encryption). However, is it possible to use `AWS CloudFront` (with certificate) and an AWS **Network** Load Balancer (Layer 4) origin to distribute HTTP over non-standard ports (in this case, TCP 4000 and TCP 3000)?
  
  I have implemented CloudFront with a Network Load Balancer origin. When queried, a 504 is generated by CloudFront (TCP 443 > TCP 3000), which suggests a timeout.
  
  I have confirmed that there are no issues with the security group and network load balancer configuration using `nc` (for example, `nc -zv lb-rswvin-XXXXX.elb.XXXXX.amazonaws.com 4000` returns `Connection to lb-rswvin-XXXXX.elb.XXXXX.amazonaws.com (X.X.X.X) 4000 port [tcp/*] succeeded!`)
  
  I am open to alternative solutions/suggestions (e.g. a dedicated EC2 instance acting as a reverse proxy) but prefer to use a native AWS service/feature.
  
  All infrastructure was deployed using IaC (Terraform).
  
  **Tags:** amazon-web-services, terraform, amazon-cloudfront
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-01-07. Score: 2 | Accepted answer
  
  Given that the Cloudfront is configured to receive external traffic on 443 and send to port 3000, and that the LB responds to a netcat socket connect the problem is on the application server
  
  The application that is on a server in the backend group for the LB is not running correctly. Maybe it is responding really slowly. This is what a 504 usually suggests. If it was a security group then that would be 502 bad gateway, if the backend group was missing instances then that would be 503 service unavailable.
  
  As the server is able to be a member of the backend group the health check http path must be working correctly on the server and talking back to the LB.
  
  Look in your application server logs for 200 from the healthcheck and for any trace of the 504 requests.
  
  There is probably an issue in the application server configuration or a bug in the under lying software
  
  
  ---
  
  