AWS ELB "sorry, site is down" page

The simple and cool solution here is to put your ELB behind CloudFront.

If the origin server (the ELB in this case) throws a 5XX error (or 4XX if you like), CloudFront can return a custom error page, which you can configure CloudFront to fetch from an S3 bucket by creating a second origin pointing to the bucket and creating a cache behavior routing (e.g.) /errors/static/* to the bucket.

This works better than Route 53 failover for an important reason... a fatal flaw, if you will... browsers are terrible about caching DNS lookups for far longer than you expect. The DNS TTL isn't relevant.

Essentially, once a browser has a DNS entry in hand, it just keeps trying to use it... typically, until all browser windows are closed.

So if your site goes down for a visitor who was already on the site, they unlikely to see the alternate site.

Worse, if a visitor hits your site for the first time while it's down, they'll "stick" on the maintenance page until they close all browser windows.

If you use failover DNS, that's really only good if the failover target is still your application, maybe just further away.

You can turn CloudFront's caching off if you don't need it.

You can also configure CloudFront's error caching TTL to a nonzero value if you want it to quit hammering your site while it's down and trying to recover. For a given page that throws an error, it will keep showing the error page and not bother your server with more requests for that page until the Error CachingTTL expires.

Use Route53 DNS and failover routing. You should be able to get up an S3 bucket hosting a single page static website. I don't think you can do it with just ELB.

Amazon have a blog post that tells you how to do it here.

Update: as Michael says, there's a drawback around browser DNS caching, see his answer for more information. Route 53 is probably a simpler option than CloudFront, but CF has other advantages, performance and in some use cases can lower costs.

Several solutions have been mentioned already, including CloudFront and Route53. CloudFront is an excellent solution and in my experience hasn't slowed things down at all, but it does bring added cost. And Route53 has the DNS caching issues already mentioned.

Until ALB supports custom error pages out of the box (which may or may not happen), there's potentially a new solution after the recent announcement of ALB fixed responses, but it's not point and click: you could set up a Lambda function that temporarily adds a rule to your load balancer, providing a fixed response with your 'error page' contents.

Aside from writing the Lambda, you'll need to find a way to trigger it 'on' and 'off', which could possibly be via a Route53 health check or load balancer target group health check (probably via CloudWatch alarm -> SNS -> Lambda).

It's not exactly simple, but would probably work well once set up!

As written by @Tim and @Micheal, you have your choice of using Route53 DNS and failover routing, or CloudFront with custom error pages. Both methods have their pros and cons.

If you are not already using Cloudfront, I think Route53 is a simpler solution. See the updated blog post from AWS (which now includes a simpler method for ELB integration).

CloudFront is much more complicated to setup, and it will take about 15 minutes for every update. Cloudfront also caches (as to be expected) so it is not clear if that will be any slower to respond, than the DNS cache issues with Route 53.

Note that if your ELB website only responds to SSL then you cannot use the simple S3 solution as described in the AWS blog3. In that case you will have to add Cloudfront in front the the S3 bucket to add the SSL, this making the DNS failure routing solution more complicated.