ベーシックっぽいELB v2サイトがあります。クラスタリングなどはまだありません。私はAWSにかなり不慣れです。
私のスタックはnginx / uwsgi / django +その他のサービスです。
なんらかの理由でダウンタイムが発生した場合はいつでも、「申し訳ありませんが、ウェブサイトは現在ダウンしています...」スタイルのページ（計画ダウンタイムを更新できるカスタムテキストはおまけです！）インスタンスは赤です。Amazonがこの機能を提供しているようではありません-私は何か不足していますか？メインのインスタンスが赤などの場合にのみ提供される別の超小型インスタンスを作成する方法はありますか？
ありがとう！
回答:
ここでのシンプルでクールなソリューションは、ELBをCloudFrontの背後に配置することです。
オリジンサーバー（この場合はELB）が5XXエラー（または、必要に応じて4XX）をスローした場合、CloudFrontはカスタムエラーページを返すことができます。これは、CloudFrontが、バケット、およびバケットへのキャッシュ動作ルーティング（例）の作成/errors/static/*。
これは、重要な理由でRoute 53フェイルオーバーよりもうまく機能します...致命的な欠陥である場合...ブラウザは、DNSルックアップを予想よりもはるかに長くキャッシュすることについてひどいです。DNS TTLは関係ありません。
基本的に、ブラウザはDNSエントリを取得すると、それを使用しようとし続けます。通常、すべてのブラウザウィンドウが閉じられるまで。
したがって、既にサイトにいた訪問者のサイトがダウンした場合、代替サイトが表示される可能性は低くなります。
さらに悪いことに、訪問者がダウンしているときに初めてサイトにアクセスした場合、すべてのブラウザウィンドウを閉じるまで、メンテナンスページに「固定」され続けます。
フェイルオーバーDNSを使用する場合、フェイルオーバーターゲットがまだアプリケーションである場合にのみ、これは本当に良いことです。
不要な場合は、CloudFrontのキャッシュをオフにできます。
CloudFrontのエラーキャッシングTTLをゼロ以外の値に設定して、サイトがダウンしていて回復を試みているときにサイトのハンマー処理を中止することもできます。エラーをスローする特定のページでは、エラーページが引き続き表示され、エラーキャッシュTTLの期限が切れるまで、サーバーがそのページへのリクエストで悩まされることはありません。
Route53 DNSとフェイルオーバールーティングを使用します。単一ページの静的WebサイトをホストするS3バケットを取得できるはずです。ELBだけでできるとは思いません。
Amazonには、ここでその方法を説明するブログ投稿があります。
更新：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ブログ3で説明されているように単純なS3ソリューションを使用できないことに注意してください。その場合、SSLを追加するためにS3バケットの前にCloudfrontを追加する必要があります。これにより、DNS障害ルーティングソリューションがより複雑になります。