首先，背景：
昨天，我们位于美国西部2区基于AWS的业务由ALB后面的两个自动扩展组（以及其他类似RDS的其他组件）组成，离线了六个小时。只有通过构建全新的ALB（在规则和目标组上迁移）才能恢复服务。
在我们当地时间上午4:15（格林尼治标准时间+10），ALB停止接收入站流量，并且不会响应网络流量。我们将其用于端口80和端口443（带有SSL证书）的终止。同时，所有目标组实例也被标记为“不健康”（尽管它们肯定是可操作的），并且没有流量转发给它们。 DNS正确解析为ALB。它只是停止了响应。网络路由器/交换机被关闭或防火墙不存在的等效症状。
我们其他不在ALB后面的EC2服务器继续运行。
最初的想法是：
a）由AWS故意隔离吗？未付帐单，滥用报告有违法行为吗？ AWS可能并没有将任何违法行为或采取行动的理由通知我们。
b）我们在网络配置方面存在错误？几天之内，NACL或安全组没有进行任何更改。此外，发生这种情况时我们睡着了，没有人摆弄设置。当我们构建替代ALB时，我们使用了相同的NACL和安全组而没有问题。
c）维护活动出了错？这似乎很有可能。但是AWS似乎没有检测到故障。我们之所以没有选择它，是因为我们认为ALB的完全，莫名其妙且未被发现的故障是“不太可能的”。我们将需要自己进行一些外部健康检查。我们有一些基于Nagios的软件，因此可以启用警报。但是，如果ALB不稳定，这将无济于事-如果再次出现这种情况，则必须继续构建新的ALB。
最大的担忧是，这突然而出乎意料地发生了，并且AWS没有检测到这一点。通常，我们从不担心AWS网络基础架构的“工作原理”。到现在。 ALB没有用户可维修的选项（例如，重新启动/刷新）。
现在是我的实际问题：
有没有其他人见过这样的东西？如果是这样，该如何做才能更快地恢复服务或首先阻止它？如果这发生在您身上，您做了什么？
答案 0 :(得分：0)
我要关闭这个。
第二天又发生了，今天晚上又发生了。症状完全相同。恢复最初是通过创建新的ALB并迁移规则和目标组来实现的。奇怪的是，先前的ALB被观察到又可以运行了，但是当我们尝试恢复它时，它又再次失败了。
创建新的ELB不再是一种解决方法，我们已转向AWS业务支持以从AWS获得直接帮助。
我们最好的假设是：AWS在维护过程中进行了一些更改，而ALB（实际上只是带有一些AWS“专有代码”的EC2实例的集合）失败了，但这实际上只是一种疯狂的猜测。