Columbus, Ohio

URL Redirects on Amazon Web Services with CloudFront and S3

Redirecting URLs on Amazon Web Services comes in a number of flavors depending on what you are trying to achieve
Redirect URLs on Amazon Web Services using CloudFront and S3

Redirects are most commonly performed by the web server sending back a HTTP 301 Location: https://example.com/path/to/page header. The most common approach is to run an Apache server and create ModRewrite rules in an Apache config file or in an .htaccess file. Even if you do not have Apache, for decades Nginx, Lighttpd, and many other web servers have provided redirection options. Some, like Apache, Nginx and Lighttpd support regular expressions which can parse paths and pass these parts of the URL to the destination URL. URL redirection is a very powerful tool that every web software developer will use throughout their career.

How does URL Redirection work on Amazon Web Services? Continue reading to find out, this page is a guide for someone who is familiar with AWS but does not know how to redirect a page, path of pages, or full web site.

Website Redirection on AWS

Redirects on AWS S3

Redirection using provided AWS tools is not as obvious as editing a .htaccess file on a server. Configuring a webpage redirect on AWS is simple, but it is not a straight forward as the documentation implies. Today we are going to clear up the confusion by explaining the options that you have. Some important facts first:

  1. Redirects are handled through an S3 Website which is a special entry point to an S3 bucket.
  2. I highly advise putting CloudFront in front of your S3 Website (See the tips and reasons why at the bottom of this page)
  3. All options discussed are considered serverless, you will not have servers or resources to manage once you set this up.
  4. Redirects do not work if CloudFront goes directly to the S3 bucket (bypassing the S3 Website)

The AWS Redirection Options

On AWS you have 3 options (not including developing your own Lambda functions and/or hosting your own EC2 instances). These options are Redirecting by using…

  • Entire S3 Website (S3 Static Website)
  • JSON redirect rules
  • Specific objects

Note that all three methods rely on both S3 storage as well as the S3 Static Website feature.

AWS Redirection Limitations

Redirection using AWS has some limitations, but for 90% of the situations you should not have an issue. Here is a simple table to outline the limitations of the Json rules and specific object methods.

Entire S3 WebsiteJSON rulesSpecific objects
Redirect entire website to anotherperfect solutionyesno
Redirect specific URLsnoyesyes*
Redirect folders and all contentsnoyesno
Redirect rewritingnonono
Set HTTP Status Code (other then 301)noyesno
Regular expression rewritingnonono
AWS Serverless URL Redirection limitation options

*Redirecting specific URLs requires an object in S3. If you are redirecting a path that ends with a / such as a folder), you will not be able to redirect the folder with the slash with the specific objects method.

The ability to rewrite URLs with regular expressions (regex) is not provided by AWS in a serverless capacity (unless you write your own lambda function). Only the JSON rules method can change the HTTP Status code and protocol (e.g. http to https).

What is a S3 Static Website?

A S3 Static Website is feature in S3 that puts a simple web server in front of your S3 bucket to serve content from S3. Remember S3 directly is meant to handle specific types of requests and methods for uploading, deleting, etc.. For those who have herd of WebDAV, its similar in that S3 is meant to be a mechanism for developers and applications to use, not the general public. It just so happens that S3 can host files directly, but this is where the limitations come in and why the S3 Static Website feature exists, to add a bit more functionality such as sending back specific HTTP headers like “Cache-Control” as well as fully supporting normal HTTP/1.1 which includes keep alive connections as well as byte range request support. This is less important with an entire site that is redirecting paths, but very important if you plan on serving static assets from S3 though CloudFront.

Why use CloudFront for an S3 Website

You will want to put CloudFront in front of your S3 website. Here are the primary reasons why:

  • HTTPS Support (S3 Website does not have Certificates Manger integration)
  • Caching in CloudFront at edge locations
  • Take advantage of edge locations (minimize traffic to the s3 bucket’s data center).
  • HTTP/2 and HTTP/3 support
  • Using your own host name (if you use S3 Website directly, the bucket name needs to match your hostname exactly)
  • Leverage the “Behaviors” and “Origins” features in CloudFront. Think if CloudFront as not only a CDN but also a proxy that can route traffic based on paths.

Tips setting up CloudFront for an S3 Website

I will be expanding this over time, but these are some tips I have setting up CloudFront for S3.

  • Make sure you setup caching in the behaviors. This will make CloudFront just a touch faster providing the redirects. In most cases you are only redirecting part of your CloudFront distribution, make sure you have caching setup for static assets which would include S3 Website Redirects.
  • Make sure paths match that you request in the browser with the path in S3. This is is not a requirement but you will thank me later when trying to match what you see in the web browser with the path in S3.
  • Don’t feel obligated to put everything in one S3 bucket. If you have a path in /hotwheels/* that has thousands of URLs you want to rewrite, and another path /matchbox/* that has thousands more, if it makes your life easier to have two (2) s3 buckets then do it. Your CloudFormations will thank me.
  • Maximize using CloudFront “Behaviors”. Paths such as /hotwheels/* can be mapped to an S3 Website while the rest of your site maps to a Elastic Load Balancer and/or API Gateway. Use the power in CloudFront’s Behaviors to set specific “Path patterns”.
  • Make sure CloudFront Behaviors have the “Compress objects automatically” set to “yes”. This enables gzip/deflate and Brotli compression support. If you have an SVG or CSS files on your site, they will be transported over the web compressed which can save significant bandwidth and more importantly, allow your website to load faster.

In coming posts I will give examples how to Redirect Entire Website, how to write JSON redirect rules in the AWS Console, and Redirect Specific objects using the AWS CLI as well as in NodeJS code.


Learn more about AWS and Redirects:

Leave a Reply

Your email address will not be published.

Join My Newsletter

Get the latest news and educational posts directly in your inbox!