Say Goodbye to Ugly Error Pages with Cloudfront 👋
Tags: aws, cloudfront, cloud, cdn
Published: 2023-11-05 18:25:37

Who has never found themselves in the middle of surfing the internet when faced with an ugly error page ? These kind of pages are the default error pages of web servers like Apache or Nginx.

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/aouvkh26653n7od4xfct.png)

More recently, you may also come across the Cloudfront default errors :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uxzj8vsnm5cw9mh7c1qd.png)

Nothing could be worse in terms of user experience, could it? These generic error pages can be frustrating, uninformative, and can make users question the reliability of a website. In the world of DevOps, where continuous deployment and high availability are key objectives, the last thing you want is to present your users with a subpar experience during moments of downtime or unexpected errors.

In a modern website architecture using a Content Delivery Network, the CDN is the last component capable of catching underlying errors and saving the day :

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v9xsp2h2kk5izc624z3k.png)

Let's configure AWS Cloudfront to catch errors from underlying components (and even an error in Cloudfront itself) !

We're going to do this in just a few steps :

1.  Create a pretty HTML error page
2.  Deploy the error page with AWS S3 static website hosting
3.  Add S3 static website as Cloudfront origin
4.  Set up Cloudfront error pages

Create a pretty HTML error page
-------------------------------

Let's ask ChatGPT to create a nice error page for us 😏

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7zg7gh166joo63nnvbbo.png)

Deploy the error page with AWS S3 static website hosting
--------------------------------------------------------

Amazon S3, Amazon Web Services' object storage service, offers a really simple way to deploy static HTML pages which we are going to use. To make this simpler, we're going to do it via click ops on the AWS console.

Create a public S3 bucket with public access :

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3rpiooill42gbsw58iwg.png)

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gsxmukycj3xxtpbe1tsg.png)

Go to your bucket, click _upload_ button and upload your index.html file :

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8jjz9oj1bokfwh33ssno.png)

Go to _properties > Static website_ hosting and enable static website hosting for your bucket :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r6b4qrh3khznt73y474s.png)

You will now have an HTTP endpoint to access your website :

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0zyuma2pzrcxws2uvj5s.png)

Go to _permissions > Bucket policy_ and allow everyone to get your files :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zpdpk5nivsscuy6u7ls4.png)

Now you should be able to access your index.html with the static url of your S3 bucket (demo-error-page.s3-website-us-east-1.amazonaws.com in my case) :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8xk1zkqa409yib38ouxv.png)

Add S3 static website as Cloudfront origin
------------------------------------------

I'm going to assume here that you already have a working Cloudfront distribution with at least one origin :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/frzv2uuhtrnaxhicb82f.png)

Let's add our S3 website endpoint (the url which contains _s3-website_, not the bucket endpoint) as a new Cloudfront origin :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kkexfm4qkogqcwj7d9uz.png)

Now we can add a new behavior for our Cloudfront distribution on a custom path :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kz12i5rudugnn8n2q6h3.png)

In this way, requests whose path matches _/cloudfront-catched-errors-demo/\*_ will be sent to our bucket :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/76li9ookbsi5qv0vjrl9.png)

Set up Cloudfront error pages
-----------------------------

We are now going to configure our distribution so that it catches errors and redirects them invisibly for the user. To do this, Cloudfront offers an "Error Pages" section where we can configure custom error response :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2zsjfn8c3w563lt8k9mm.png)

Let's create a custom error response :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lv26s68q7szad50uxhot.png)

By doing that, we are going to catch all 502 HTTP errors and show our pretty HTML error page by setting "Response page path" to _/cloudfront-catched-errors-demo/index.html_. Let me show you!

Before :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9tjpvbv615afrc30akoe.png)


After :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/75bkv47abgxy1g0pnp0b.png)

To go further
-------------

I recommend that you catch at least HTTP 500, 501, 502, 503 and 504 errors via Cloudfront error pages because they concern server-side errors and are not managed by the application server. For 4xx errors, as they concern errors made by the customer, this is more debatable. If the error is handled correctly by the application, you might as well leave this role to it (this is very often the case for 404 errors, which are handled by web mode frameworks).

_**If you liked this post, you can find more on my blog https://adrien-mornet.tech/ 🚀**_