I am thinking of using CloudFront distribution as CDN to server my images, css and js. I have a CloudFront distribution setup to point to the same directory in the server where my code is, just changing the subdomain to cdn so it'd be cdn.domain.com.

My problem is, this CDN subdomain would sever the HTML and php links too which I don't want it to do. I just want to use Cloudfront images, css and js.

Can you please point me to proper ways to do this? Is there a way to do this within the cloudfront panel?

I think we can server 404 page from htaccess once the the call gets to origin server but I am looking for a better option that would actually prevent the request from reaching the origin server.


CloudFront is great for serving dynamic html. It's faster for users (especially distant users) even if the page isn't cached as it uses Amazon's backbone instead of the public internet, which is optimised for this job. It protects your server against layer 4 (TCP) and layer 7 (http) attacks. Using a single domain is faster if you use http/2, which CloudFront supports, as http/2 lets you send resources that are required to render the page even before the client knows it needs them.

Set your TTL to 0 for HTML, and obviously higher for static resources.

Have a look at something like this Re:Invent session for more information, or the excellent documentation.

  • Really? Is there a web server that implements HTTP/2 push yet? – Michael Hampton Feb 17 '17 at 3:09
  • CloudFlare, which I use in front of my own websites. They use Nginx and release many of their changes, so I wouldn't be surprised to see support trickle out to base Nginx at some point. I had a quick go at enabling it on one of my websites but ran out of time and patience. blog.cloudflare.com/announcing-support-for-http-2-server-push-2 – Tim Feb 17 '17 at 4:03

Create an empty bucket in S3. The name doesn't matter. Add this as a second origin to the CloudFront distribution. Reconfigure the default cache behavior to send all requests to the bucket.

Then, create new cache behaviors for the path patterns that you want CloudFront to serve from your server, pointing to your custom origin. Examples of the path patterns would be /*.css, /*.js, and /*.png. The * wildcard matches any characters in the path, including additional slashes, so these files will be served by CloudFront, anything else gets the "Access Denied" XML message from the dummy bucket.

Bonus points: if you configure the dummy bucket for web site hosting and use the web site endpoint hostname (instead of selecting the bucket from the drop-down) when creating the new S3 origin, you can configure a default error page for the bucket and display that HTML instead of access denied... or you can configure the bucket to redirect any arriving request back to your non-cdn domain using S3 redirect routing rules.

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.