AWS ELB「申し訳ありませんが、サイトがダウンしています」ページ
ベーシックっぽいELB v2サイトがあります。クラスタリングなどはまだありません。私はAWSにかなり不慣れです。
私のスタックはnginx/uwsgi/Django +いくつかの他のサービスです。
なんらかの理由でダウンタイムが発生した場合はいつでも、「申し訳ありませんが、ウェブサイトは現在ダウンしています...」スタイルのページ（計画ダウンタイムを更新できるカスタムテキストはボーナスです！）インスタンスは赤です。 Amazonがこの機能を提供しているようには見えません-何か不足していますか？メインのインスタンスが赤などの場合にのみ提供される別の超小型インスタンスを作成する方法はありますか？
ありがとう！
ここでのシンプルでクールなソリューションは、ELBをCloudFrontの背後に配置することです。
オリジンサーバー（この場合はELB）が5XXエラー（または、必要に応じて4XX）をスローした場合、CloudFrontは カスタムエラーページ を返すことができます。これにより、CloudFrontがS3バケットからフェッチするように構成できます。バケットを指す2番目のOriginを作成し、キャッシュ動作ルーティング（例）を作成する/errors/static/*をバケットに追加します。
これは、重要な理由でRoute 53フェイルオーバーよりもうまく機能します...致命的な欠陥、もしそうなら...ブラウザーはDNSルックアップを予想よりもはるかに長くキャッシュすることについてひどいです。 DNS TTLは関係ありません。
基本的に、ブラウザはDNSエントリを取得すると、それを使用しようとし続けるだけです。通常、すべてのブラウザウィンドウが閉じられるまでです。
そのため、既にサイトにアクセスしていた訪問者のサイトがダウンした場合、代替サイトが表示される可能性は低くなります。
さらに悪いことに、訪問者がダウンしているときに初めてサイトにアクセスした場合、すべてのブラウザウィンドウを閉じるまで、メンテナンスページに「固定」され続けます。
フェイルオーバーDNSを使用する場合、フェイルオーバーターゲットがまだアプリケーションである場合にのみ、これは本当に良いことです。
不要な場合は、CloudFrontのキャッシュをオフにできます。
CloudDownのエラーキャッシングを構成することもできますTTLそれがダウンしているときにサイトのハンマー処理を中止して回復しようとする場合は、ゼロ以外の値に設定します。エラーをスローする特定のページの場合、エラーページを表示し、エラーキャッシュTTLの期限が切れるまで、そのページへのリクエストでサーバーを悩ませないでください。
Route53 DNSと フェイルオーバールーティング を使用します。単一ページの静的WebサイトをホストするS3バケットを取得できるはずです。 ELBだけでできるとは思いません。
Amazonには、その方法を説明するブログ投稿 here があります。
更新：Michaelが言うように、ブラウザーのDNSキャッシングには欠点があります。詳細については彼の回答を参照してください。 Route 53はおそらくCloudFrontよりも簡単なオプションですが、CFには他の利点、パフォーマンスがあり、場合によってはコストを下げることができます。
CloudFrontやRoute53など、いくつかのソリューションについてはすでに言及しています。 CloudFrontは優れたソリューションであり、私の経験では物事がまったく遅くなっていませんが、追加のコストがかかります。また、Route53には、すでに述べたDNSキャッシングの問題があります。
ALBがそのままの状態でカスタムエラーページをサポートするまで（発生する場合と発生しない場合があります）、 ALBの修正済み応答の最新の発表 の後に新しい解決策が見つかるかもしれませんが、ポイントアンドクリックではありません。ロードバランサーに一時的にルールを追加するLambda関数をセットアップし、「エラーページ」の内容を含む固定応答を提供します。
Lambdaの作成とは別に、それを「オン」および「オフ」にトリガーする方法を見つける必要があります。これは、おそらくRoute53ヘルスチェックまたはロードバランサーターゲットグループヘルスチェック（おそらくCloudWatchアラーム-> SNS経由）による可能性があります。 >ラムダ）。
それは正確には単純ではありませんが、一度設定すればおそらくうまくいくでしょう。
@Timと@Michealによって書かれたように、Route53 DNSと フェイルオーバールーティング を使用するか、または カスタムエラーページ を使用してCloudFrontを使用するかを選択できます。どちらの方法にも長所と短所があります。
Cloudfrontをまだ使用していない場合は、Route53がより簡単なソリューションだと思います。 AWSから更新された ブログ投稿 を参照してください（ELB統合のためのより簡単な方法が含まれています）。
CloudFrontはセットアップがはるかに複雑であり、更新ごとに約15分かかります。 Cloudfrontは（予想どおりに）キャッシュも行うため、Route 53のDNSキャッシュの問題よりも応答が遅くなるかどうかは明確ではありません。
ELBウェブサイトがSSLにのみ応答する場合、AWSブログで説明されているように単純なS3ソリューションを使用できないことに注意してください。その場合、S3バケットの前にCloudfrontを追加してSSLを追加する必要があるため、DNS障害ルーティングソリューションがより複雑になります。