我有一个基础版的 ELB v2 网站。还没有集群之类的东西。我对 AWS 还不是很熟悉。
我的堆栈是 nginx/uwsgi/django + 一些其他服务。
我想知道是否有人想过，每当因任何原因停机时，如果实例的运行状况为红色，就制作一个“抱歉，该网站目前处于关闭状态...”样式的页面（我可以更新计划停机时间的自定义文本，这是一个额外的好处！）。亚马逊似乎没有提供此功能 - 我是否遗漏了什么？有没有办法创建一个单独的超小实例，只有当主实例为红色时才提供服务，或者其他什么？
谢谢！
答案1
这里简单而酷的解决方案是将您的 ELB 放在 CloudFront 后面。
如果源服务器（本例中为 ELB）抛出 5XX 错误（或者 4XX 错误），CloudFront 可以返回自定义错误页面，您可以通过创建指向存储桶的第二个源并创建/errors/static/*到存储桶的缓存行为路由（例如）来配置 CloudFront 从 S3 存储桶中获取。
这比 Route 53 故障转移效果更好，原因很重要……如果你愿意的话，这是一个致命缺陷……浏览器缓存 DNS 查找的时间比你预期的要长得多。DNS TTL 不相关。
本质上，一旦浏览器掌握了 DNS 条目，它就会不断尝试使用它……通常直到所有浏览器窗口都关闭。
因此，如果您的网站对于已经访问过该网站的访问者来说出现故障，他们不太可能看到替代网站。
更糟糕的是，如果访问者在网站瘫痪时第一次访问您的网站，他们会“停留”在维护页面上，直到关闭所有浏览器窗口。
如果您使用故障转移 DNS，那么只有当故障转移目标仍然是您的应用程序（可能距离更远）时，这才是真正有用的。
如果不需要，您可以关闭 CloudFront 的缓存。
如果您希望 CloudFront 在网站瘫痪并尝试恢复时停止对网站的攻击，您还可以将 CloudFront 的错误缓存 TTL 配置为非零值。对于抛出错误的给定页面，它将继续显示错误页面，并且不会再向您的服务器发送该页面的更多请求，直到错误缓存 TTL 到期。
答案2
答案3
已经提到了几种解决方案，包括 CloudFront 和 Route53。CloudFront 是一种出色的解决方案，根据我的经验，它完全没有减慢速度，但它确实增加了成本。而 Route53 存在前面提到的 DNS 缓存问题。
在 ALB 支持开箱即用的自定义错误页面（这可能会发生，也可能不会）之前，可能会有一个新的解决方案最近发布的 ALB 修复响应，但它不是指向和点击：您可以设置一个 Lambda 函数，临时向您的负载均衡器添加一条规则，并使用您的“错误页面”内容提供固定的响应。
除了编写 Lambda 之外，您还需要找到一种方法来触发它的“开启”和“关闭”，这可能是通过 Route53 运行状况检查或负载均衡器目标组运行状况检查（可能通过 CloudWatch 警报 -> SNS -> Lambda）。
它并不简单，但一旦设置好就会运行良好！
答案4
正如@Tim 和@Micheal 所写，您可以选择使用 Route53 DNS 和故障转移路由或 CloudFront 与自定义错误页面. 两种方法都有其优点和缺点。
如果你还没有使用 Cloudfront，我认为 Route53 是一个更简单的解决方案。请参阅更新博客文章来自 AWS（现在包含一种更简单的 ELB 集成方法）。
CloudFront 的设置要复杂得多，每次更新大约需要 15 分钟。Cloudfront 还会缓存（这是意料之中的），因此尚不清楚其响应速度是否会比 Route 53 的 DNS 缓存问题更慢。
请注意，如果您的 ELB 网站仅响应 SSL，那么您无法使用 AWS 博客中描述的简单 S3 解决方案3。在这种情况下，您必须在 S3 存储桶前面添加 Cloudfront 来添加 SSL，这会使 DNS 故障路由解决方案更加复杂。