2

I have been checking things up & down on Google & AWS Documentation but can't seem to nail this one.

I have an EC2 instance setup with a domain being served via a virtual host and I need to use a CDN for the contents on the site, mainly images ie website assets.

EC2 Details of the instance

  • t2.micro
  • LAMPP
  • Virtual Host Set Up
  • DNS: Route 53
  • No ELB
  • EBS
  • SSL

Cloudfront Distribution Details

  • Origin: example.com
  • Delivery Method: Web

What I tried to do is use the domain name in the origin and the Cloudfront domain was now redirecting to the origin domain name along with fetching assets by https.

I haven't found any impact on the site speed, pinged from different geo locations thus I have come to doubt whether this was done correctly.

The part which I need to resolve is which of the below path is correct for setting up Cloudfront with EC2:

  1. Use EC2 instance DNS for 'Origin Domain Name' and add the directory name in the 'Origin Path' for the virtual host
  2. Only add the domain name in the 'Origin Domain Name'

Thanks for the help!

Edit

Attaching Route 53 Details

  • A Record => Name: www.example.com, Value: IP ADDRESS & Routing Policy: Simple
  • A Record => Name: example.com, Alias: Yes & Alias Target: www.example.com

Edit02

Updated AWS Setup AWS Setup between EC2, Route 53 & CloudFront

ServerInsights
  • 51
  • 2
  • 6

1 Answers1

0

In DNS, example.com needs to be an A record with Alias set to Yes, pointing to the CloudFront endpoint.

This means example.com no longer points to your origin server, so you have to use a different name as the origin host. One option is to use the EC2 public DNS name for the instance.

By default, CloudFront will set the origin domain name in the Host: header when sending the request to the instance. You can override this in Cache Behavior by whitelisting the Host header, so that example.com is sent inside the request to the origin, even though the DNS entry used to actually find the origin differs.

If $ dig example.com doesn't return a large number of IP addresses, then you aren't currently actually using CloudFront.

HTTP responses that come back from CloudFront will also contain extra headers, including X-Amz-Cf-id, X-Cache, Via, and sometimes Age.

Michael - sqlbot
  • 22,658
  • 2
  • 63
  • 86
  • I was able to confirm that CloudFront isn't being used by running the dig command. Added an A record to point to the CloudFront endpoint and added the EC2 public DNS to custom origin in CloudFront. I may have to wait I guess to see some effect and will report the results in case any one else faces the same issue. @Michael - sqlbot Thanks for your suggestions!! – ServerInsights May 26 '17 at 04:32
  • This didn't work broke the connection to the site :-(. I had to revert back to how it was, @Michael - sqlbot something I am misunderstanding here? – ServerInsights May 26 '17 at 05:10
  • In DNS, the `example.com` has an A record with a TTL. Make a note of that value -- it's time in seconds -- and make a note of the current time. Add the two together., e.g. if it's 07:00 now and TTL is 3600, your new value is 1 hour in the future at 08:00. Next, change the TTL to a small value, such as 15, and save changes. Then, don't change anything else until after the future time calculated above. This will make future testing less error-prone and should not otherwise impact the site... – Michael - sqlbot May 26 '17 at 10:56
  • In what sense did the connection break? Did you get a certain specifig error? If you are using SSL on EC2, where did you get the certificate you are using there? – Michael - sqlbot May 26 '17 at 10:59
  • Good tip about TTL! The error was from CloudFront and was just a generic couldn't connect. I have edited the question with the architecture and setup that I have placed as per your suggestions, with the _CloudFront Domain Name & example.com_ giving the same error. – ServerInsights May 27 '17 at 05:11
  • www.example.com is working though as it points to the server's IP. – ServerInsights May 27 '17 at 05:12
  • And oh, yes, SSL used was purchased from Godaddy. – ServerInsights May 27 '17 at 07:25
  • The generic "couldn't connect" in CloudFront is deliberately vague but it often means SSL trouble. See, for example, [CloudFront Distribution with ELB origin HTTP 502 (Bad Gateway)](https://serverfault.com/a/779723/153161) and [cloudfront fail to request objects in behavior](https://stackoverflow.com/a/35258911/1695906) and [CloudFront wasn't able to connect to the origin](https://stackoverflow.com/a/38841070/1695906). – Michael - sqlbot May 27 '17 at 16:28