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
  • 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!


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


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

1 Answer 1


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.

  • 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!! May 26, 2017 at 4: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? May 26, 2017 at 5: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... May 26, 2017 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? May 26, 2017 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. May 27, 2017 at 5:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.