How to implement the maintenance page using Route 53 to switch between CloudFront distributions?


Imagine following use case:

  1. First CloudFront distribution is used to serve the web application (multiple origins eg. ALB, Lightsail, ...)
  2. Second CloudFront distribution is used to show simple maintenance page from the S3 bucket

We want to use Route 53 to update the DNS record for our domain eg.

  • to point to the first CloudFront distribution during the normal operation of the web application
  • to point to the second CloudFront distribution during the maintenance of the web application

It is not possible to support this scenario (switching between two CloudFront distributions), because two CloudFront distribution cannot have the same alternate domain name. We wonder if it is not possible to do so for some special reason? Or is there any workaround?

2 Answers

It would be much better to do this with a single distribution - this is a fairly common requirement from customers and you can implement it using custom error pages in CloudFront, along with AWS WAF.

To implement this:

  1. Create the maintenance page in an S3 bucket as you originally intended
  2. Create a new Origin in your CloudFront distribution that points to the S3 Bucket. Use OAI/OAC as required.
  3. Create a new Behavior in your CloudFront distribution with the S3 Bucket as the origin. Use a path that's not currently part of your application, etc /errors
  4. Configure Custom Errors for your distribution so that your maintenance page is served in the case of a 403 error. Add other error codes if you wish.
  5. Configure an AWS WAF WebACL and attach it to your CloudFront distibution. If you already have a WebACL attached, you can simply modify that one.
  6. Create a new custom rule in AWS WAF and place it at the top of the WebACL. The rule should match all traffic - but you may want to add an exception for your own IP address(es) so that you won't receive the maintenance page. Make sure the rule action is set to COUNT
  7. When you want to invoke the maintenance page, simply change the rule action to BLOCK - this will cause a 403 error to be returned to all of your viewers. The error will be handled by CloudFront, which will display your maintenance page. When you want to return the application back to service, simply switch the rule action back to COUNT
  8. If you wish, you could use a Lambda function to toggle the rule action. You can then trigger the Lambda function in a variety of ways to suit your use case.
answered 9 months ago
  • Perfect way of doing this Paul L.. Theres no worries with DNS Cache here either..

  • Paul L, your answer adds a component (WAF) which costs money. The OP's desired solution on the other hand, having a dormant Cloudfront maintenance distribution, and then switching DNS to that from the production distribution, would, if it were possible, carry no additional costs. Do you have a suggestion which does not cost money just to add this maintenance functionality?

  • Also, from AWS docs: "CloudFront can't distinguish between an HTTP status code 403 that is returned by your origin and one that is returned by AWS WAF". Maintenance pages are usually served with a 503. This solution does not nicely allow separate management of planned maintenance vs a genuine application-level "forbidden".

  • If you prefer to use 503 status codes for your maintenance page, you can do this with a custom response action in WAF:

  • I recommended AWS WAF because it aligns to the Well Architected Framework (Apply security at all layers) and also is a best practice for DDOS mitigation. The intention is that it should be used for security use-cases, alongside this one. However, should you decide not to use AWS WAF, you could implement maintenance page functionality on a single CloudFront distribution by using a CloudFront Function to rewrite the URI of all incoming requests to that of your maintenance page. You would then enable/disable the maintenance page by attaching or removing the CloudFront Function.

Accepted Answer

Here is the working solution which actually made things quite simple:

Extra bonus is that we can put our ip addresses into the IP sets in AWS WAF and make it an exception, so we can access the site during a maintenance.

answered 9 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions