应对AWS服务中断：系统性地处理实际问题
社交媒体和技术新闻中，那些从未构建或支持过应用程序的人，每当遇到他们不理解的事情（比如无法访问电子邮件或其他服务）时往往会惊慌失措。
停止恐慌。
在不了解实际问题、影响或真正责任方的情况下惊慌失措、小题大做，这毫无帮助。
我对AWS（以及Azure、GCP、离线开发和自建数据中心或其他托管服务）有所了解。我在此不是要指责任何人。我写这篇文章是为了帮助您解决问题，减少未来此类中断事件的影响。
“等等，什么？不应该再有中断了！“我能听到一些人在咆哮。
首先，系统确实会发生故障。我们从不希望它们故障，但它们确实会发生。可能是数据中心发生火灾，可能是龙卷风或飓风导致的停电，可能是数据中心在意外战争中被炸毁，或是遭到外国对手的大规模DDoS攻击，也可能是横跨海底的线路被鲨鱼咬断。还可能是DNS记录被恶意或意外的内部人员或攻击者修改，将服务指向错误的IP地址。
事情总会发生。
顺便说一句，据我上次检查，微软和Azure平台上发生的事情更多，而我在银行工作、在云环境之外时发生的事情更多。那家银行每三个月通过在不同区域的另一个数据中心重新部署所有内容来测试系统故障转移，看看什么会出问题。这比我认识的大多数公司测试区域中断的系统故障转移都要好。
那么，对于这次中断，您可以做些什么呢？
到底发生了什么？
以下是关于这次中断我们所知道的情况。在事件发生期间，您无法知道发生了什么。您必须等待准确的信息，而不是惊慌失措和猜测。这就是为什么我说在数据泄露后，除非您有内部信息，否则请等待两天再做出评估。在这种情况下，亚马逊在不到两天的时间内发布了一份声明，但更多信息即将公布。
以下是列出未解决问题的声明，当您阅读本文时可能已经消失，但您可以在历史记录中找到它：
142项服务受到影响：
这是我们关心的主要条目，并期待未来从AWS听到更多信息。但这是我们目前所知道的：
[已解决] 错误率和延迟增加 10月20日下午3:53 PDT 在10月19日晚上11:49 PDT到10月20日凌晨2:24 PDT之间，我们在US-EAST-1区域的AWS服务经历了错误率和延迟增加。此外，依赖US-EAST-1端点的服务或功能（如IAM和DynamoDB全局表）在此期间也遇到了问题。在10月20日凌晨12:26，我们确定事件的触发因素是区域DynamoDB服务端点的DNS解析问题。在凌晨2:24解决DynamoDB DNS问题后，服务开始恢复，但由于EC2对DynamoDB的依赖，我们在EC2负责启动EC2实例的内部子系统中出现了后续故障。在我们继续处理EC2实例启动故障的同时，网络负载均衡器健康检查也出现故障，导致Lambda、DynamoDB和CloudWatch等多个服务出现网络连接问题。我们在上午9:38恢复了网络负载均衡器健康检查。作为恢复工作的一部分，我们暂时限制了一些操作，如EC2实例启动、通过Lambda事件源映射处理SQS队列以及异步Lambda调用。随着时间的推移，我们减少了操作限制，并并行工作以解决网络连接问题，直到服务完全恢复。到下午3:01，所有AWS服务恢复正常运行。一些服务如AWS Config、Redshift和Connect继续有消息积压，它们将在接下来的几个小时内完成处理。我们将分享详细的AWS事后总结。
一个区域（us-east-1）
首先要注意的是，故障发生在一个区域——us-east-1。因此，受影响的内容要么存在于us-east-1区域，要么对该区域有依赖。是的，us-east-1是故障最频繁的区域，并托管一些核心服务，因此您可能对us-east-1有一些依赖，无论您喜欢与否——特别是在美国。
然而，有许多服务不依赖us-east-1，因此如果可能，您应该尝试在us-east-1之外设置系统，或者至少故障转移到非us-east-1区域。
AWS上关键工作负载的最佳实践是设置它们，使其可以在两个不同的区域运行。然后，如果您需要在主区域故障时的可靠性，请设置系统在第一个区域宕机时故障转移到另一个区域。在之前的一次中断中，许多公司遇到了问题，但我一位在发送短信公司工作的朋友却没有。他说，很多人遇到问题而他们没有的主要原因是他们在两个不同区域放置了NAT。这使他们能够在主区域系统无法操作时将流量重新路由到另一个区域。
AWS需要重新审视的问题
查看这次故障，我相信AWS将审查并查看一些依赖关系，以了解是否可以解耦那些在us-east-1之外区域也受影响的服务，并加强导致DNS解析问题的原因。这些事情是AWS的责任，因跨区域依赖而经历故障的客户应该从客户角度讨论具体问题以及如何解决它们，并询问AWS将如何解决客户无法自行解决的问题。
除了对DNS记录和DynamoDB表（这些可能可以更改，也可能无法更改）的严重依赖外，听起来一些系统需要在故障时重新测试以进行优雅恢复。我在银行系统中经常遇到这个问题。当处理一批财务记录的批处理过程失败时，您必须确保在重新启动时，如果有记录处理到一半或丢失，它能正常工作。它需要正确处理和记录错误，同时继续处理其余记录。
我不确定，因为我不在AWS工作，但听起来可能是类似的问题，存在某种数据损坏，系统在修复损坏数据之前无法继续。所有系统都需要测试重启和正确记录错误，而不是卡在错误上。我猜测所有这些系统和其他系统将被重新审视，以在未来正确处理此类故障。
随着过去可能处理过此类问题的老员工离开公司，这类问题可能会被遗忘。我只是在猜测。客户可以向他们的客户代表询问更多信息，亚马逊的高管可能会深入探讨具体的故障点，以更好地理解和解决根本原因，确保这些问题得到修复并不再发生。
AWS IAM——这个核心服务实际受影响多久？
从外部看，中断时间可能看起来更长。但要注意的核心点之一是AWS IAM——几乎在所有地方登录AWS都需要的服务——在美国时间半夜大约宕机了2.5小时。
如果AWS IAM不工作，这是一个几乎所有服务都依赖的服务，您认为AWS需要多长时间来修复它？考虑到影响，我很确定它不会宕机很长时间。
这是您应该问自己的问题——我们的业务能承受AWS IAM或Identity Center多长时间的停机，这会阻止我们登录AWS控制台或通过API进行身份验证？
构建一个确保我们永远不会宕机的解决方案需要多长时间和多少成本，即使这些系统宕机？构建该解决方案的成本是高于还是低于等待AWS使IAM重新上线？
对于大多数公司，我很确定他们可以承受等待。您有什么替代方案——构建自己的Microsoft Active Directory本地系统，在重大数据泄露期间可能导致重大停机和所有数据丢失，而且除了自己之外没有其他人可以指责？通过审查这次数据泄露来考虑影响：
更不用说，由于无数数据泄露和漏洞，微软建议所有人远离自托管的Active Directory，转向云托管的Azure Entra ID（以前称为Azure AD）解决方案，微软可以立即为所有客户解决这些问题。
处理IAM和AWS Identity Center的区域依赖
话虽如此，我特别不喜欢对单个区域的依赖。您能做什么？我刚刚在思考一些选项，但您需要自己测试这些选项。
AWS Sovereign Cloud正在欧洲设置，具有完全独立的系统。如果过渡完成，通过欧洲系统登录的人不应该受到影响。我从社交媒体上认识的人那里了解到，欧洲的人基本上没有受到影响，除了少数对us-east-1有依赖的服务。
我实际上想了解更多关于这方面的信息，因为如果您使用AWS Sovereign Cloud，这些依赖关系应该不存在…
但似乎欧洲的人仍然可以登录。如果我错了，那么AWS一定还在开发AWS Sovereign Cloud。因此，对于欧洲的人（因为美国的人无法登录AWS Sovereign Cloud），您可能可以在美国和欧洲都设置账户以实现故障转移。显然我不使用AWS sovereign cloud，您需要测试一下。
这是我在思考的另一个选项。当我想使用Amazon Q pro tier时，我必须设置AWS Identity center以获得AWS提供的IP保护和IP赔偿（还有其他人提供吗？）
我在这里写过：
由于我在这个博客中多次写过的许多原因，我不想为我的组织使用AWS Identity Center，尽管我最近没有深入测试AWS Identity Center。由于我必须为Amazon Q使用它，我在一个特定区域设置了它，没有组织访问权限。它只能在两个区域设置——us-east-1或法兰克福区域——用于Amazon Q pro tier。因此，对于该特定用例，我可以在两个区域设置用户。如果一个区域宕机，我可以在另一个区域使用不同的登录继续使用Amazon Q。
顺便说一句，除了Amazon Q，我可以通过GitHub重新部署我的整个开发设置，除了一个任何区域的E2实例外，不依赖AWS。而且我不是为我写的每一行代码都使用Q。我可以轻松地添加使用我的特定脚本部署到任何云的能力，但创建和测试这不值得我花时间，因为我在AWS上经历的停机时间很少。
但我的问题是…为什么不允许客户在AWS的两个区域设置两个AWS IAM Identity center副本并进行故障转移？这在底层是否仍然依赖us-east-1中的AWS IAM服务？这是给AWS的问题。
我做的另一件事是同时使用AWS IAM和AWS Identity Center。您可以在账户中设置两者的登录。我的问题是，管理多个东西的风险是什么。值得吗？我的AWS Identity Center在一个账户中，仅在该账户中使用，并且无法访问我的组织或AWS服务。我没有很多人来管理我所有的IAM配置细节。所以我限制了我必须管理的内容。
拥有单一的真实身份来源并小心管理身份是保护系统安全的最关键方面之一——这是一项不能掉以轻心的任务。做好功课，考虑所有可能出错的事情。您真的知道所有与身份管理相关可能出错的事情吗？我在这个博客上写了很多。
如果您有更多的人来正确管理IAM，那么同时使用两者会有帮助吗？问题是，它们在底层是否都依赖us-east-1中的AWS IAM端点？那么同时使用两者对您没有帮助。
您可以将登录服务转移到像Okta这样的公司，但在底层Okta仍然依赖AWS IAM将您登录到AWS，所以这没有帮助。此外，Okta可能至少部分运行在AWS上。
您需要在某处处理身份和登录。问题是——您真的能自己做得更好吗？在写这篇文章时，我的经验是否定的。
所以只需为多年来最少的停机时间做计划，并询问AWS他们正在做什么来解决最近的中断，以及您可以做什么来最小化它对您验证和授权访问AWS系统能力的影响（如果发生的话）。
请注意，我在这里只讨论对所有全局AWS系统的身份验证和访问，不讨论其他内容。我不讨论失败的SAAS平台、失败的银行应用程序、在Crowd Strike崩溃后无法获得调度系统的航空公司或其他任何东西。
AWS IAM将使您无法登录AWS控制台，应用程序无法向AWS服务进行身份验证。事情会中断，在AWS修复该问题之前您无能为力。
在这次事件中，大约是2.5小时。您的业务能承受2.5小时的停机时间吗？
如果有任何不能等待那么长时间的事情，比如访问某些特定数据，那么您可能需要备份或故障转移到另一个云提供商、托管托管提供商或您自己的数据中心（如果您在该领域没有经验，祝您好运）——构建可靠并完全测试它对于一个复杂的应用程序将花费您一大笔钱。权衡该成本与停机成本，如果您需要，就构建它。
TLS证书
您必须在us-east-1中创建TLS证书。我不知道为什么。如果us-east-1中影响TLS证书的问题，我不知道这如何影响您的应用程序。可能是在区域中有多个系统支持TLS证书在备用区域中的功能，即使您必须在us-east-1中创建证书。向AWS询问更多信息，并根据需要为您的应用程序进行测试，以确保如果us-east-1出现问题，它们仍然有效。
我写过关于使用AWS TLS证书的文章，这些证书现在可以导出以更好地保护Ubuntu实例上的RDS流量（与某些实现默认使用的Snake Oil证书相对）：
我甚至不知道有AWS中断，因为IAM宕机时我不在线，而且我没有使用us-east-1或我的Ubuntu实例，所以我不确定这是否会受到影响。需要测试的事情。
一些其他服务出于某种原因依赖us-east-1。过去CloudFront是这样，今天有人告诉我QuickSight是这样。如前所述，Amazon Q需要IAM Identity Center登录以获得完整的IP保护。询问AWS哪些其他服务可能有区域依赖，审查文档——并测试。
对于有区域依赖的服务，问自己——这些服务对业务运营有多关键。我们真的需要使用它们吗？我们有什么替代方案？
如果您想使用它们，那么考虑上述停机时间以及它发生的频率。例如，我在这里审查了主要云提供商的中断：
您能承受停机时间吗？
测试您的应用程序的服务故障！
如果您必须使用像QuickSight这样的东西，假设它在您的银行应用程序中显示一个图表，当它失败时会发生什么？它是否优雅地失败，而您的应用程序的其余部分正常工作？设计并测试当对特定AWS服务的访问失败时会发生什么。
测试当AWS服务API由于无法登录或服务本身故障而不可用时会发生什么的一种基本方法是阻止对该区域API端点和全局端点的网络访问。
您的应用程序是否继续运行并显示用户友好的错误，说明您的应用程序的该特定功能有问题，还是您的整个系统崩溃，此时没有人能做任何事情？
其他一切
好的，对于其他一切，理论上，如果您构建多区域故障转移，如果us-east-1宕机，您应该能够继续正常运行。例如，我在IAM问题解决后上线。我在一个单独的区域工作。登录时我有一些零星的问题，但一旦登录，一切都很好。
我甚至不知道有中断。我刚刚向反馈链接发布了几条错误消息，以便AWS确切知道我在我这边看到了什么——来自Google Developer工具的浏览器错误和代理错误——而不仅仅是"一切都坏了！！！！"，顺便说一句，这非常没有帮助。类似于恐慌的文章，如"每个人都应该停止使用云！！！”
因此，如果您将系统架构设计为从一个区域故障转移到另一个区域，理论上，除了登录失败和一些对us-east-1的依赖外，您的系统应该大部分保持运行。
我还没有听到任何人说这不是真的，但人们可能仍在处理中断的后果，所以我们必须等待看看会发生什么。我真的很想不仅从遇到问题惊慌失措的人那里听到，而且从设计过跨区域故障的人那里听到，以及那是如何工作的。您学到了什么？如何改进——从客户和AWS的角度？
我是一个问题解决者，不是一个指责者。我尝试观察事物，找出哪里出了问题，什么能修复它。不仅仅是通过将东西从一个失败的平台转移到另一个可能更糟的平台——而是通过查看根本原因并进行公平的成本效益分析以及适当的灾难恢复和业务连续性计划。
关于您在AWS上的供应商和SAAS平台
有人提到，“不仅仅是AWS，所有其他SAAS供应商也是！！！“哦，天啊。是的。确保您的SAAS供应商在您雇用他们之前拥有为故障构建的适当架构，这是谁的责任？
您的。
进行适当的供应商评估。您能测试跨区域故障转移吗？您的供应商甚至支持多个区域吗？考虑我上面提到的所有事情，并询问AWS如何评估您的供应商拥有能够承受故障并及时恢复的架构。
在您的供应商DR和BCP评估中，有多个关键领域需要考虑。您需要了解完整的SAAS平台架构和所有依赖关系：
- 云架构
- 应用程序架构——系统能否在故障时重启并正确处理中断时损坏的数据？
- AWS之外的网络架构——AWS之外的网络停机能否阻止系统或应用程序运行或支持人员登录修复问题？
- 可能影响在AWS中运行的系统的供应商系统架构
- SAAS平台依赖的外部API以及提供这些外部API的供应商是否也有可靠的DR和BCP计划。
这是一个例子。我进行渗透测试，我看到公司使用Okta或Launch Darkly。好的，所以您想雇用的供应商遵循了所有最佳实践，并在AWS中构建了他们的架构以承受区域故障。但如果他们的系统无法访问Okta或Launch Darkly，它就会崩溃。
好的，现在您必须对Launch Darkly、DockerHub、Okta、安全供应商或您的供应商系统依赖的任何其他第三方系统进行评估。
如果您只看架构的AWS部分，请检查您的供应商是否遵循这里描述的AWS架构最佳实践：
但根据我执行过渗透测试的大多数系统，AWS通常只是系统完全依赖的第三方之一。
用扎实的逻辑解决正确的问题
在解决问题时，确保您不是基于错误逻辑做出决定，比如我在这里写的关于安全控制的决定…错误逻辑：您决定一个控制是问题，而不是修复它，而是用更糟的东西替换它。
使用五个为什么来找到您真正想要解决的问题，比如我得到的这个不是实际问题的问题。确保您问正确的问题并解决正确的问题。
如何说服我的安全团队让我停止使用CloudFormation
并记住为自己批判性思考—— disregard emotional hype.
总结：
- 问正确的问题。
- 获取正确的信息。
- 解决正确的问题。
- 测试解决方案——不要假设它会工作。
- 进行适当的成本效益分析。
- 避免炒作。
这是第二天发布的关于中断的完整评估，以及本可以防止它的一件事——说起来容易做起来难，但仍然。
关注更新。