This post was written by Sander Rodenhuis and Posted on 20 november 2017

[updated]

What if you would like to use a custom error page in case all instances behind an (classic) AWS Elastic Load Balancer (ELB) are unavailable (in case of maintenance)? ELB does not provide an option to use custom error pages. When the instances are unavailable, ELB will show a default blank page.

What surprises me is that this feature (using a custom 503 error page with ELB) has been suggested in a tread in the AWS forums (see here) in 2011. Now in 2017, the feature is still not available. In search of a solution I found 2 possible solutions: Using Route53 DNS failover and CloudFront custom error responses.

Route53 DNS failover

With DNS failover you can check the health of a resource (web server) and associate a record set with a failover routing policy. You can create a custom error page and set up a static website on Amazon S3. Route53 will check the health of your site by periodically requesting the homepage and verifying that it returns a successful response. If it does not return a successful response, Route53 will automatically start sending traffic to your custom error page site on S3. So far so good. However, it takes a significant amount of time for DNS entries to expire before the maintenance page shows up (and then it takes that same amount of time to update after maintenance is complete). Read this blog post to learn how to set up Route 53‘s DNS Failover feature. There is however another way to do this: using CloudFront custom error responses.

CloudFront custom error responses

CloudFront offers a feature to use custom error responses. In this setup, you will add the ELB as a Custom origin to CloudFront, also add a S3 origin, create a behavior and create a custom error response. Follow these steps:

  1. Create a new CloudFront distribution and add the ELB as a custom origin
  2. Configure CloudFront. Don’t forget to change the related Route53 record so it points to the CloudFront distribution instead to the ELB)
  3. Create a S3 bucket to store the custom error pages. Make sure CloudFront has read access to the bucket
  4. Add a second (S3) origin and add the Origin Domain name of the bucket where you stored the custom error pages (mysite.com.error-pages.s3.amazonaws.com) and configure bucket access
  5. Add a second Behavior. Add the path pattern (/error-5xx/*) and select the S3 origin. Leave all other option default.
  6. Add a Custom Error Response. See image.

To see if the custom error page works, take the instances out of the elb. Note that if you used en EC2 instance in the ELB to do a redirect from http to https, u can now let CloudFront do this for you.

If the instances in ELB are online during maintenance, you could use a second ELB without any instances and before starting maintenance use the AWS CLI to swap the environment CNAME to take your production environment into maintenance mode. This would cause the ELB to throw a 503 because there aren’t any running EC2 instances. CloudFront will then catch the 503 and return your custom 503 error page.

Summary

Route53 DNS failover

  • DNS records need to be in a Route53 hosted zone
  • S3 can be used to serve a custom error page
  • Failover will take some time because DNS entries first need to expire

CloudFront custom error responses

  • S3 can be used to serve a custom error page
  • Custom error page will be served immediately after ELB returns a 503
  • Additional cost for using CloudFront (see here for billing details)
  • Additional cost for using custom error pages

I prefer to use the CloudFront custom error responses. Too bad AWS still (after more than 6 years) hasn’t added this feature to ELB. And why would they, now you have to pay for it!

I’ve asked AWS if there is an update on this:

I guess we have to wait a little bit longer….