我有一个基本的ELB v2网站。没有群集或任何东西。我对AWS缺乏经验。
我的堆栈是nginx / uwsgi / django +其他服务。
我想知道是否有人想到了什么原因造成停机，无论是否出于任何原因，都会有人提出“抱歉，该网站当前正在关闭...”样式的页面（我可以更新计划的停机时间的自定义文本是一种奖励！）实例是红色的。亚马逊似乎没有提供此功能-我错过了什么吗？有没有一种方法可以创建一个单独的超微型实例，该实例仅在主实例为红色或其他东西时才可用？
谢谢！
我有一个基本的ELB v2网站。没有群集或任何东西。我对AWS缺乏经验。
我的堆栈是nginx / uwsgi / django +其他服务。
我想知道是否有人想到了什么原因造成停机，无论是否出于任何原因，都会有人提出“抱歉，该网站当前正在关闭...”样式的页面（我可以更新计划的停机时间的自定义文本是一种奖励！）实例是红色的。亚马逊似乎没有提供此功能-我错过了什么吗？有没有一种方法可以创建一个单独的超微型实例，该实例仅在主实例为红色或其他东西时才可用？
谢谢！
Answers:
这里简单而酷的解决方案是将您的ELB放在CloudFront之后。
如果原始服务器（在这种情况下为ELB）抛出5XX错误（如果需要，则抛出4XX），CloudFront可以返回一个自定义错误页面，您可以通过创建第二个指向该服务器的原始位置，将CloudFront配置为从S3存储桶中获取。存储桶并创建/errors/static/*到该存储桶的高速缓存行为路由（例如）。
由于一个重要原因，此方法比Route 53故障转移要好。这是一个致命缺陷，如果您愿意的话，浏览器将DNS查找缓存的时间远远超出了您的预期。DNS TTL不相关。
本质上，一旦浏览器拥有一个DNS条目，它就会一直尝试使用它……通常，直到关闭所有浏览器窗口。
因此，如果您的站点因某个已经访问过该站点的访问者而瘫痪，则他们不太可能看到该备用站点。
更糟糕的是，如果访问者在网站停机期间首次访问您的网站，他们将“粘贴”在维护页面上，直到他们关闭所有浏览器窗口。
如果您使用故障转移DNS，那么仅当故障转移目标仍然是您的应用程序（也许只是在更远的地方）时，这才真正有用。
如果不需要，可以关闭CloudFront的缓存。
如果希望退出站点崩溃并尝试恢复时退出站点，也可以将CloudFront的错误缓存TTL配置为非零值。对于抛出错误的给定页面，它将继续显示错误页面，并且直到Error CachingTTL过期之前，服务器才会对该页面发出更多请求。
使用Route53 DNS和故障转移路由。您应该能够建立一个托管单个页面静态网站的S3存储桶。我认为您不能仅使用ELB就能做到。
亚马逊有一篇博客文章，告诉您如何在这里做。
更新：正如Michael所说，浏览器DNS缓存存在一个缺点，有关更多信息，请参见他的答案。Route 53可能是比CloudFront更简单的选择，但是CF具有其他优势，性能，并且在某些情况下可以降低成本。
已经提到了几种解决方案，包括CloudFront和Route53。CloudFront是一个出色的解决方案，以我的经验，这丝毫没有减慢速度，但是确实带来了额外的成本。而且Route53具有已经提到的DNS缓存问题。
在ALB支持开箱即用的自定义错误页面之前（可能会发生或可能不会发生），在最近宣布ALB固定响应之后，可能会有一个新的解决方案，但这并不是指向并单击的：您可以设置一个Lambda函数来临时添加负载平衡器的规则，使用“错误页面”内容提供固定的响应。
除了编写Lambda之外，您还需要找到一种方式来触发它“打开”和“关闭”，这可能是通过Route53运行状况检查或负载均衡器目标组运行状况检查（可能是通过CloudWatch警报-> SNS- > Lambda）。
这不是很简单，但是一旦设置好就可以了！
正如@Tim和@Micheal所写，您可以选择使用Route53 DNS和故障转移路由，或者使用CloudFront和自定义错误页面。两种方法各有利弊。
如果您尚未使用Cloudfront，我认为Route53是一个更简单的解决方案。请参阅来自AWS 的更新的博客文章（现在包括用于ELB集成的更简单方法）。
CloudFront的设置要复杂得多，每次更新大约需要15分钟。Cloudfront还会缓存（如预期的那样），因此尚不清楚响应速度是否会比Route 53的DNS缓存问题慢。
请注意，如果您的ELB网站仅响应SSL，那么您将无法使用AWS博客3中所述的简单S3解决方案。在这种情况下，您将必须在S3存储桶之前添加Cloudfront来添加SSL，这会使DNS故障路由解决方案更加复杂。