Asked  7 Months ago    Answers:  5   Viewed   24 times

My setup is as follows:

  1. user types on the browser
  2. request goes to AWS CloudFront, which redirects HTTP to HTTPS, and forwards the request to the AWS Elastic LoadBalancer (
  3. LoadBalancer forwards the request to the EC2 instance running PHP Laravel framework
  4. EC2 responds normally
  5. user views the page correctly at with everything else transparent to him

All this is perfectly what I want, HOWEVER .....

  • If the user navigates to any button on the page, the url on the browser will become (it should stay
  • If I go to view page source, all the links to any button on the page has the base url of (it should be

The reason is because EC2 see the request coming from the load balancer so it assumes the base url is and generates all links accordingly.

How do make EC2 see the base url as ?



This behavior likely results from the fact that by default CloudFront sets the Host: HTTP request header to the origin hostname, in this case The application then presumably generates links based on that hostname.

If, instead, you configure CloudFront to whitelist that header for forwarding to the origin, the Host header sent by the browser ( will be sent on to the application by CloudFront, so the application should behave more like you'd expect and use that value when generating the links. With this, CloudFront still uses the origin domain name to do the DNS lookup needed in order to establish the TCP connection to the origin (the ELB in this case), but stops injecting that hostname into the HTTP request headers.

You'll find the host header under cache behavior settings -> cache based on selected request headers -> whitelist.

Wednesday, March 31, 2021
answered 7 Months ago

The other SO question you referenced is spot on. Double/Triple check the following

  • You need to attach only public subnets to your ELB, making sure that the availability zones those subnets are aligned with the availability zones of the private subnets that your instances are in.
  • Make sure that the security group of your instances allows access from the security group of your load balancer
  • The load balancer security group should have an egress rule allowing the health check to reach the instance
  • Make sure that your health check is working locally on the instance. For example, if your health check in the ELB is HTTP:8080/health_check, on the instance you can curl x.x.x.x:8080/health_check (where x.x.x.x is the private IP of the instance) and get a 200 response code.
  • The public subnet routing table should route to the internet gateway attached to your VPC.
  • The private subnet routing table should route to a NAT instance or gateway in a public subnet
Saturday, July 31, 2021
answered 3 Months ago

The problem was that I had the origin set up in CloudFront not to forward Query Strings so when S3 got the request it would redirect properly without the query params. You can find this setting in CloudFront > Behaviors > Forward Query Strings.

Sunday, August 15, 2021
Dave B
answered 2 Months ago

We had the same problem.

In our setup, an AWS Application ELB has a target group of 4 EC2 instances. On each of the EC2 instances, there is an Apache2 which forwards to a Tomcat.

The ELB has a default connection KeepAlive of 60 seconds. Apache2 has a default connection KeepAlive of 5 seconds. If the 5 seconds are over, the Apache2 closes its connection and resets the connection with the ELB. However, if a request comes in at precisely the right time, the ELB will accept it, decide which host to forward it to, and in that moment, the Apache closes the connection. This will result in said 502 error code.

The solution is: When you have cascading proxies/LBs, either align their KeepAlive timeouts, or - preferrably - even make them a little longer the further down the line you get.

We set the ELB timeout to 60 seconds and the Apache2 timeout to 120 seconds. Problem gone.

Thursday, September 9, 2021
answered 1 Month ago

If you enable ELB Cross-Zone Load Balancing, d1 will get 20% of the traffic.

Here's what happen without enabling Cross-Zone Load Balancing: D1 would get nearly 50% of the traffic. This is why Amazon recommends adding the same amount of instances from each AZ to your ELB.

The following excerpt is extracted from Overview of Elastic Load Balancing:

Incoming traffic is load balanced equally across all Availability Zones enabled for your load balancer, so it is important to have approximately equivalent numbers of instances in each zone. For example, if you have ten instances in Availability Zone us-east-1a and two instances in us-east-1b, the traffic will still be equally distributed between the two Availability Zones. As a result, the two instances in us-east-1b will have to serve the same amount of traffic as the ten instances in us-east-1a. As a best practice, we recommend you keep an equivalent or nearly equivalent number of instances in each of your Availability Zones. So in the example, rather than having ten instances in us-east-1a and two in us-east-1b, you could distribute your instances so that you have six instances in each Availability Zone.

Saturday, October 9, 2021
answered 1 Week ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :