How to use Cloudfront only for statics and improve SEO by 301 the rest of requests to your site

Adrian Angel Sanz Melchor
AWS Tip
Published in
4 min readApr 20, 2022

--

The problem

We make use of cloudfront in a different way that a lot of people does, we don’t host a static site on S3 and then use cloudfront to serve it. We have a full CMS under cloudfront to serve only static files. However we came across the issue that google was indexing our Cloudfront distribution domain, so we needed to fix that, but using an alternative name was not a solution, since we make some dark magic to embed all static files with the domain name of the cloudfront distribution… Then a coworker told me about using Nginx to check if the request came from Cloudfront, and if it’s not a static file then redirect to the correct domain, but that’s kinda obscure… Then I though about behaviors, and that seemed like a good way to start!

Hands on!

So we are going to make use of two elements in Cloudfront:

  • Behaviors: which defines paths with glob patterns, which if they match they could behave different than other paths. All distributions have a default one that catches all the requests that don’t match others behaviors (we will take advantage of this)
  • Cloudfront functions: simple functions in (I think) JS, that can accomplish different tasks on requests.

The goal is that, every request that does not match any behavior we configure, falls in the default one, which will trigger the function and redirect with a 301 to the correct domain.

I will also drop this diagram with 3 scenarios, the first one is the usual flow followed when you enter the page via domain, the second one is what happens when you access via cloudfront domain, the third one is the same as the second one, but this time we have the fix implemented!

Cloudfront functions

You have different functions for different event types:

  • Viewer request <- this one is the one we are interested in
  • Viewer response
  • Origin request
  • Origin response

Here’s an image to help you understand each event type:

Full doc on: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-cloudfront-trigger-events.html

We will configure a viewer request, there are tons of examples online, but I’ll make use of this snippet:

NOTE: this function will always return a 301, because the logic of checking if it’s a static file or not, it’s handled with behaviors, you could modify this snippet and it would be more powerful than the simple glob pattern, but for us this works like a charm and it’s easier since you won’t require much JS knowledge

Change the newurl to your domain, then you can test the function, and publish it:

Testing the function
Publish the function so it will be available

That’s all, now you have the function configured, tested, and published!

Behaviors configurations

So, we will create different behaviors with more or less the default configuration, we will use a custom origin and redirect to HTTPS. The default cache policy is good for us. I have the next ones configured:

I’m only interested in this file extensions, but you can add whichever extensions or paths you need.

On the default behavior we will configure the previously created function on viewer request:

After that save your changes and test it!

A request to a JS file
Request to the main site

And just as we wanted we redirect every request that’s not a static file to the real domain, avoiding that google indexes the cloudfront distribution domain.

That’s all folks ❤

--

--

Just a spanish DevOps who likes sharing useful knowledge, working proudly @ Cipher