Need help using AWS Route 53, CloudFront, and S3 to use my Domain Name with SSL instead of S3 link name.

Daniel Greer
Daniel Greer used Ask the Experts™
I'd like to have a subdomain or something similar(CNAME?) of a domain that I own redirected to an Amazon S3 htm file without the user seeing the name of the S3 file in the address bar when the user is redirected. (Godaddy called this "masking"). all while the subdomain address shows SSL Encryption.

i.e. I would like: 

to redirect to: 

I've attempted:
Creating a custom bucket in S3 that is the same name as my domain name, then going to Route 53 to get the naming servers, and changing the nameservers for in Godaddy to Route 53 nameservers so I can point Route 53 to S3 files.

This didn't work for me. So I...

Looked at setting up CloudFront to serve HTTPS requests to my Amazon S3 buckets...
I've been instructed to to this:
"- Since your files in bucket "v-tours" reside inside folder "Canton Museaum of Art/Salon Style 2/Tablet & Web Files", you should use this as value for 'Origin Path'.

In step 5, you should choose 'redirect HTTP to HTTPS' so that HTTP requests from client will be redirected to HTTPS by CloudFront.

As you are using custom domain " ", you must use this value for 'Alternate Domain Names (CNAMEs)'. Also, kindly install a custom certificate on CloudFront for your domain.

Additionally, instead of using CNAME record, I would recommend you to use A(Alias) record to point your subdomain to CloudFront. Alias records are special records provided by Amazon. DNS queries to A(Alias) records are free of cost. There are various benefits of using Alias records like they can be used on naked domain name. To read more about Alias records, please refer [2].

After making this configuation, you will be able to achieve your aim."

Here are my results:
Here's a link to screenshots of my settings in a zip:

Please check my settings...I'll explain each Image:

AWS CloudFront Settings 1 - Settings chosen based on following your instructions exactly

AWS CloudFront Settings 2 - The end of the origin path...based on following your instructions exactly

AWS CloudFront Settings 2a - Alternate beginning of origin path (since this seems to be appended to the origin domain name, it seemed that duplicating the beginning of the origin path would be redundant and incorrect.)

AWS CloudFront Settings 2b - Alternate end to origin path (since i need the CloudFront link and its CNAME to point to the 'index.htm' file specifically, and I didn't see another place to do this.

AWS CloudFront Settings 3 - End of origin ID (I already know now that I could have put a simple name to this, and I cannot change it once created)

AWS CloudFront Settings 3a - My suggestion for an alternate Origin ID name (I like this much better)

AWS CloudFront Settings 4 - I left these settings at their default

AWS CloudFront Settings 5 - I entered the name that I control in Route 53 (Is it correct that I can leave the default NS in GoDaddy as is, and simply validate the DNS at GoDaddy when creating a certificate in AWS CM?). I used the Wildcard SSL certificate(* created in AWS CM. All other settings remain at default.

AWS CloudFront Settings 6 - Bottom of page...left default

Error Code 1 - This is what happened when testing the direct cloudfront link with my alternate suggestions (I see now that i was wrong somewhere)

Error Code 2 - I received this after changing the beginning of the origin path to the value you suggested. I see that the key isn't displaying the path as it should be. The Key shows: " Museaum of Art/Salon Style 2/Tablet & Web Files/index.htm/", but I actually entered: " "

Error Code 3 - This is the error code I receive when entering in the origin path exactly as suggested: " "

SSL Certificates - Validated via DNS in Route 53 since the NS are still currently forwarded there.

Wrong Origin Path - This shows that the origin path is duplicated when I don't alter your suggested Origin Path like i did in the "AWS CloudFront Settings 2a" image.

I didn't receive a reply, so I continued troubleshooting on my own. Here are my results:

Link to error images:

I have now tried:

Origin Domain name:
(based on endpoints found here: )

I've also tried that with different combinations of Origin Paths...

Origin Path:
A. /Canton+Museaum+of+Art/Salon+Style+2/Tablet+%26+Web+Files
B. /Canton+Museaum+of+Art/Salon+Style+2/Tablet+%26+Web+Files/index.htm
C. /
D. /
E. /s3://v-tours/Canton Museaum of Art/Salon Style 2/Tablet & Web Files
F. /s3://v-tours/Canton Museaum of Art/Salon Style 2/Tablet & Web Files/index.htm (this is the link I get when I click "copy path" - shown in "copy path 1" image)

I've also:

Set the Default Root Object in General Settings to: "index.htm"
Enabled "Static Web Hosting" in the properties of the "v-tours" bucket
Set the Index document to "index.htm" in Static Web Hosting settings
Created a CloudFront Distribution without a CNAME (this gives me an "Access Denied" error)

I found some suggestions from this forum here: 

All of these methods have produced nothing but errors, and one test configuration actually just downloaded a blank file labelled "download" after CloudFront link was placed in address bar. going on??

...I then saw in the stack overflow forum linked above that I may have needed to Cloudfront Cache Invalidation Request every time i tried a new link...I see it explained here:

The problem is, that I wouldn't even know which link path accurately points to the directory I'm trying to invalidate!

I'm simply trying to get this link of a domain that I own and can control with Route53 (or GoDaddy, since it was bought there, and now I'm just using Route53 Name Servers): 

to redirect to: 

With SSL, and without showing the end user the long AWS directory.

Please help me to effectively do this.
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Fractional CTO
Distinguished Expert 2018
If your files are small, avoid S3 as using S3 tends to be over complex, compared to just dropping a file into a directory on your Webserver.

Tip: Always avoid using whitespace in your file names. Use a dash character, rather than any whitespace character.

Tip: Remove the "&" char (%26) because it appears you've embedded an "&" in a file name, which will cause all manner of confusion + possible break referencing the file at all, because "&" chars are reserved for query strings... At least it appears you're using an "&" in your file name... so if you are remove it or oddities will abound.

Likely you're project will be far easier if you just reference the S3 link.

Start by Pre Signing Your File so the file can be accessed publicly.

Get this working, then move on to obfuscating the S3 URLs, if required.

The simple way will be to run a download script on your site, so something like where your download script does a lookup on asset + converts it to an S3 link + returns the object.

Again, if you can host files on your Website, you'll be done with all this in a few seconds.

Obfuscating S3 URLs... will take a good bit of time... details how to write your download script. details how to use the CNAME strategy you're working toward now.


Thank you SO much David! Yes...obfuscating the s3 URL's, and figuring out how to do exactly what I wanted to do certainly took MUCH more time than I felt was necessary. My website is with Bluehost, and when hosting the files there, the virtual tour is considerably more sluggish. Because of this...I persevered and finally made this work by creating a CloudFront Distribution that pointed to my s3 file, and then created a CNAME for that Distribution. I'm happy with this solution since it should make sure that the virtual tour runs smoothly from wherever it's requested from.

I thank you very much for this new information that you've provided, and will look into pre-signing files for future projects, and possibly writing a download script(although I don't want the user to actually download the entire tour correct? Maybe I'm missing something)

Here is a list tips that came from my mistakes in the hope that they may help someone with this type of problem in the future....

1. Make sure the default CloudFront Distribution link works before messing with CNAME domains or aliases

2. Try using "0" cache settings in Cloudfront in both the "behaviors" and "custom error response" settings to keep cache's clear while testing, then change cache values back to default once it works.

3. Try putting the index.htm or index.html file in default bucket directory, and leave the Origin Path blank when attempting to make this work for the first time.

4. Cloudfront WILL NOT accept spaces in your S3 bucket if your directory is a long one, you may have to recreate it without spaces. (David, you are absolutely right about this!)

5. Here is a list of AWS Origin Domain Name endpoints for use in CloudFront(the Website endpoint for my bucket worked for me):

6. Your "Origin Path" in CloudFront does not include your bucket name or "index.htm" / "index.html" if you...

7. Tell Cloudfront the exact file you want it to read in s3 in your General Settings under "Default Root Object"(i.e. - index.html), Also do this in your bucket properties under "Static Web Hosting"(this may be unnecessary, but it's currently working for me)

8. It may take cloudfront a while to populate your CNAME domain have to wait...then type the root of the CNAME into the "name" box before CNAME will show in ALIAS drop-down menu

9. Make sure Route 53 forwards to Cloudfront with "A - Ipv4" and ALIAS, then select same CNAME from dropdown menu(like I said you may have to wait for CNAME in CloudFront to populate here)

10. If another company such as GoDaddy or Bluehost(anyone other than Route 53) controls your domain name then forget Route 53 was mentioned, you must match a subdomain with your CloudFront CNAME there(unless you change nameservers to Route 53 nameservers)

11. You have to create your own certificate in AWS Certificate Manager to secure your CNAME. You can't use the CloudFront Distribution Certificate for your CNAME.

12. This link might help you if you're getting error codes:

13. If you're getting "Access Denied" errors, follow Step 2 in this link to make your bucket public: (David, maybe Pre-signing files is a better option here)

14. I am fully aware that this doesn't cover everything, but it covers many critical things I missed. Watch CloudFront Tutorial Videos to visually see some of these things done right...Youtube is your friend!
David FavorFractional CTO
Distinguished Expert 2018

13. Yes, pre-signing files is likely the most... let's see... seamless access method, from an end user point of view.

Also this will simplify all your coding, else you'll have to pass along S3 access credentials with every access... which will likely leave you balled up in a fetal position... whimpering... in some dark corner.

Pre-Signing is your friend.
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

David FavorFractional CTO
Distinguished Expert 2018

Aside: BlueHost... use to be a fantastic company, same as HostGator, till both were gobbled up by EIG.

Tip: Friends don't let friends EIG...

You might find leasing your own hardware from OVH solves all your performance problems.

Check out their pricing.

Also, consider where you're business is going. If your client base + income is growing, best to escape BlueHost now, while getting out is easy.


lol...thank you David. I'll look into Pre-signing more and OVH.


Thank you again David for all of your help!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial