我有一个基本的ELB v2网站。 没有集群或任何东西。 我对AWS很不熟悉。
我的堆栈是nginx / uwsgi / django +其他一些服务。
我想知道是否有人有任何想法让“抱歉，网站正在下降…” – 风格页面（自定义文本，我可以更新计划停机时间是一个奖金！）每当有任何原因的宕机和健康该实例是红色的。 亚马逊似乎没有提供这种能力 – 我错过了什么？ 有没有办法创build一个单独的，超小型的实例，只有在主要是红色的时候才会提供服务？
谢谢！
这里简单而酷的解决scheme是将ELB放在CloudFront后面。
如果源服务器（本例中为ELB）引发5XX错误（如果您喜欢，则为4XX），则CloudFront可以返回自定义错误页面 ，您可以通过创build第二个来源指向存储区并创buildcaching行为路由（例如） /errors/static/*到存储区。
这比路由53故障转移更好的一个重要原因…一个致命的缺陷，如果你愿意…浏览器是可怕的DNScaching查找远远超过您的预期。 DNS TTL不相关。
从本质上讲，一旦浏览器有一个DNS条目，它只是不断尝试使用它…通常，直到所有的浏览器窗口closures。
因此，如果您的网站对于已经在网站上的访问者发生故障，他们不太可能看到备用网站。
更糟糕的是，如果访问者在第一次访问您的网站时遇到了问题，他们会在维护页面上“坚持”，直到closures所有浏览器窗口。
如果您使用故障转移DNS，那么如果故障转移目标仍然是您的应用程序，那么这样做可能只是更好。
如果您不需要，可以closuresCloudFront的caching。
您也可以将CloudFront的错误cachingTTLconfiguration为非零值，如果您希望在停止时尝试恢复您的网站。 对于引发错误的给定页面，它将继续显示错误页面，并且不会在该错误页面有更多请求的情况下打扰服务器，直到Error CachingTTL过期。
使用Route53 DNS和故障转移路由 。 您应该能够启动一个承载单个页面静态网站的S3存储桶。 我不认为你只用ELB就可以做到这一点。
亚马逊有一篇博客文章，告诉你如何在这里做。
更新：正如Michael所说，浏览器DNScaching有一个缺点，请参阅他的答案获取更多信息。 Route 53可能比CloudFront更简单，但CF还有其他优势，性能和在某些使用情况下可以降低成本。