当检查 AWS 是否运行良好或遇到困难时，仅仅看绿灯或红灯是不够的： 你必须跨越健康面板、实时信号和对你的资源的具体审查通过这种综合方法，您将知道问题是普遍性的、区域性的还是与您自己的基础设施相关的，并且您将能够采取行动而不必贸然行动。
在本指南中，我将为您提供一切结构良好的信息，以便您检查 AWS 的状态： 来自 AWS Health Dashboard 及其与 EventBridge 的集成以及如何在 ACM 中查看续订状态、解读 EC2 检查以及如何使用 CloudWatch 指标和警报做出响应。您还将了解控制台拒绝加载时应采取的步骤、如何检查公共状态页面，以及为什么像 Downdetector 这样的第三方工具对于上下文有用，但对于自动化却无用。
AWS Health Dashboard：起点
AWS 运行状况仪表板显示可能影响您的服务和资源的中断、活动事件和计划维护。 它是您帐户的一部分，不需要配置，并提供上下文可见性。 了解正在发生的事情。如果您尚未登录特定实例或控制台，则首先要查看的是此处。
一个经常被遗忘的细节： AWS 是区域性的从“健康”面板选择器中选择正确的区域，因为如果您搜索错误的区域，可能会错过影响您的事件。这种精确度可以避免当问题局限于特定地理区域时出现误诊。
自 2023 年起，在“健康”板块开启公开活动时， 浏览器 URL 包含指向事件的深层链接这使您可以共享正在查看的确切事件或重新打开它并返回到加载弹出窗口的同一视图，从而促进事件期间的团队合作。
如果管理控制台没有打开或返回浏览器错误（例如 404），请不要急于进入。 首先检查健康仪表板中是否有相关的活动事件，然后采取本地措施，例如清除缓存和 cookie、尝试使用其他浏览器，并与您的 IT 团队确认您的网络没有阻止 Amazon 域（amazon.com 和子域，如 aws.amazon.com）。
可靠的事件提取：EventBridge 优于 RSS
有包含健康事件的 RSS 源，但它们的格式 可能会随着时间的推移而发生变化，并破坏你的集成至少可以说，抓取或依赖 RSS 来获取关键管道是有风险的。
强大的东西是整合 AWS Health 与 Amazon EventBridge这样，您可以实时接收具有稳定模式的事件，并准备将其路由到 Lambda、队列、通知或内部仪表板，从而创建没有脆弱部件的事件电路。
借助 EventBridge，您可以获得可追溯性和弹性： 您可以标记、丰富、关联和自动化响应 取决于服务、地区或影响。即使明天公开推送内容的呈现细节发生变化，您的集成功能仍将保持不变。
ACM：审查证书续订没有任何问题
使用 AWS Certificate Manager，您可以以托管方式验证您的证书是否正确更新。 当证书与 AWS 服务（例如 ELB 或 CloudFront）关联或自颁发或上次续订以来被导出时，该证书有资格自动续订。这种资格是忘记手动续订的基石。
当续订周期开始时，ACM 会在证书详细信息中显示状态字段。 您可以从控制台、API 或 CLI 检查续订状态 了解您的健康状况。如果有任何需要您关注的问题，您还会看到与“健康”仪表板相关的状态。
如果您更喜欢命令，CLI 可以简化操作： describe-certificate 操作返回详细信息，包括续订状态。。 例如：
例如： aws acm describe-certificate --certificate-arn arn:aws:acm:REGION:ACCOUNT:certificate/CERTIFICATE_ID
在 JSON 响应中，查看 RenewalStatus 字段。 如果该字段尚未出现，则表示 ACM 尚未启动托管续订。提前计划是个好主意：ACM 会在到期前 60 天左右尝试自动续订，如果出现问题（例如域验证）， 您将提前收到健康通知：45、30、15、7、3 和 1 天.
当控制台无法充电时：快速有效的步骤
访问 AWS 控制台时出现 404 错误或连接失败通常可以解决。 首先查看您的资源所在地区的健康仪表板。 消除影响该服务或控制台的正在发生的事件。
如果没有未决事件，则采取当地措施： 清除浏览器缓存和cookie，尝试使用其他浏览器登录，并向系统管理员确认公司网络没有阻止 amazon.com 或 aws.amazon.com 等子域。
该问题可能仅限于特定资源。 例如，EC2 实例可能正在进行计划维护。，健康面板将显示该事件的窗口及其影响。直接访问根目录可以节省您的时间。
此外，如果您的帐户被锁定，那么随时准备一些帮助文章总是一个好主意： 创建并激活新帐户、登录控制台或请求帮助。有了这些指南，可以减少紧张时刻的等待时间。
EC2 详情：状态检查以及失败时该怎么做
Amazon EC2 对每个实例执行自动检查，以检测影响您的应用程序的平台或软件问题。 这些检查每分钟运行一次，并根据结果标记为正常或受损。。它们无法关闭，并且是您的早期预警。
CloudWatch 中的指标支持每种类型的验证。 如果检查失败，相关指标就会上升，这时就需要发出警报了。通过此功能，您可以自动执行通知和操作以最大限度地减少停机时间。
系统检查（底层平台）
这些检查监控您的实例运行的基础设施。 当它们发生故障时，通常是平台问题，需要 AWS 干预或采取措施将实例移动到另一个主机。.
在 EBS 支持的实例中，有效的行动是 停止并启动实例以将其迁移到新主机如果您的实例使用实例存储（Linux），您可以选择终止并替换，因为关闭时临时卷将会丢失。
反映这一失败的指标是 StatusCheckFailed_System如果情况持续存在，它非常适合触发运行手册、自动恢复或打开支持案例的警报。
Bare Metal 有一个特点： 重新启动操作系统可能会暂时导致系统检查错误。当实例恢复正常工作时，状态将返回到 OK，无需进一步干预。
实例检查（连接性和软件）
这些检查分析实例本身的操作系统和网络的健康状况。 EC2 通过向 NIC 发送 ARP 请求来验证其是否正在响应，从而验证连接性。此处的失败通常需要您进行调整。
如果检查失败，就该采取行动了： 重新启动实例，检查防火墙/iptables，检查系统日志，并确保网络响应。当原因在于软件或配置时，等待是不够的。
需要关注的指标是 StatusCheckFailed_Instance. 使用它来触发运行诊断程序的警报（如果检测到它没有恢复，则收集日志、控制重启或回滚）。
同样，在裸机中，从操作系统重新启动时可能会出现暂时错误。 当实例完成启动时，检查通常会返回 OK。，所以不要惊慌。
EBS 附加检查（卷上的 I/O）
这些检查验证附加的 EBS 卷是否可访问以及是否可以完成输入/输出操作。 当一个或多个卷发生故障时，StatusCheckFailed_AttachedEBS 二进制指标会指示情况恶化。.
此方面的错误可能是由于底层计算问题或 EBS 中的问题造成的。 您可以期待 AWS 采取缓解措施或采取行动：更换卷，停止并启动实例以将其移动到另一个主机，或者如果发现瓶颈，请检查 IOPS 大小。
如果你的负载没有进行 I/O 但出现恶化， 停止和启动循环可以解决影响卷可访问性的主机问题。. 与 CloudWatch 中的原生 EBS 指标相补充，以检测性能不佳的模式。
在 Auto Scaling 组中，配置策略以 删除附加 EBS 检查中持续存在故障的实例无需人工干预，您便可保持车队健康，并避免长时间停机。
警报和自动化：CloudWatch + Auto Scaling
通过所有健康指标，CloudWatch 成为您的神经系统。 定义阈值、创建警报并协调操作：通知、Lambda、实例恢复或替换. 它是自动和一致响应的基础。
如果您需要业务连续性，请考虑自动化和替换： Auto Scaling 可以淘汰失败的实例并启动新的实例，同时您的闹钟会激活相应的通知渠道（电子邮件、Slack、PagerDuty 或您使用的任何渠道）。
完整的观点来自相关来源： 通过 EventBridge 实现 CloudWatch 指标和日志、跟踪以及 AWS Health 事件通过此图块，您将能够区分问题出在您的应用程序、实例、卷还是平台上，并且您将能够准确地做出反应。
了解 AWS 是否出现故障的官方和上下文来源
当有关下跌的谣言四处传播时——就像 AWS全球中断 导致大规模故障——，理想的做法是优先考虑官方来源。 检查公共页面 status.aws.amazon.com 以查看按服务和地区划分的状态。，如果您已登录，请使用 AWS Health Dashboard 获取特定于帐户的信息。
第三方来源提供额外的社会背景和信号。 Downdetector 反映了用户报告中的峰值，而 Stack Status 总结了几个提供商的状态。尽管它们不能取代官方渠道，但它们对于估计覆盖面很有用。
然而，它区分了可见性和自动化。 对于程序化事件提取，EventBridge 比 RSS 提要或抓取更好。，因为外部格式可能会发生变化并使您陷入事件之中。
大幅下降的表现以及预期结果
重大事故往往集中在交通繁忙的地区（例如美国东海岸），并且 影响波及整个产业链：存储、计算、数据库或 DNS像 S3、EC2、RDS、Route 53 或 Kinesis 这样的服务受到错误峰值的影响并不罕见。
在这些情况下，流媒体公司、协作工具、电子商务或移动应用程序可能会遇到延迟、身份验证错误和间歇性故障。 这种模式是不均衡的：它对某些用户有效，但对其他用户无效。，根据路线、存在点和活动区域。
官方渠道通常会定期发布更新： 初步确定原因（例如，API 上的 DNS 解析问题）、部署缓解措施并提出重试建议随着恢复的进展，错误减少，流量恢复正常。
在某些国家或地区，您会看到有关受影响的特定服务的头条新闻。 Netflix、Disney+、Slack 等平台、银行或非常流行的应用程序可能会受到影响 当他们所依赖的地区遭受损失时，甚至拉丁美洲的企业（例如过去发生事件的 iFood、Mercado Livre 或 PicPay）也感受到了震动。
跌倒造成的经济和声誉影响
除了技术层面之外，云中断还会带来实际成本： 每分钟的损失、超负荷的支持、沮丧的客户和媒体压力互联网某些支柱的集中化放大了网络效应。
运营关键服务的组织对此非常了解： 如果失败屡屡发生，信任就会被削弱 恢复品牌形象的成本比技术修复本身还要高。
这些危机给我们带来了一个显而易见但令人不安的教训： 我们严重依赖共享基础设施针对弹性和现实的故障假设进行设计不再是可选的。
应对下一次事件的策略
如果您的企业无法关闭，那么有一些策略可以降低运营风险。 考虑采用多区域架构在不同的 AWS 区域之间分配负载。 并避免单点地理故障。
当用例证明其合理时，评估多云。 将核心功能分发给另一个提供商（Azure、GCP）可以为您提供安全网。，尽管它涉及更大的复杂性和协调成本。
在交付层，配置良好的 CDN 有助于抵御风暴。 诸如 CloudFront 之类的服务或 Cloudflare 之类的替代方案允许您提供静态内容，即使您的来源出现问题。，让用户和系统休息一下。
如果没有组织，这一切都不会发生： 定义事件响应计划，包括角色、渠道、升级和外部沟通在关键时刻，清晰的思路可以节省宝贵的时间。
检查 AWS 状态而不迷失的最佳实践
Centraliza la observabilidad: 使用 AWS Health Dashboard 获取平台上下文并使用 CloudWatch 获取运营指标这种双重方法可以防止您被任何一层所蒙蔽。
有了证书，就实现了自动化。 监控 ACM 中的 RenewalStatus 并对 Health 仪表板中不断升级的警报做出反应 以免在错误的情况下到达到期日。
对关键 EC2 指标设置警报。 StatusCheckFailed_System、StatusCheckFailed_Instance 和 StatusCheckFailed_AttachedEBS 必不可少，根据您的 SLA，通过 Auto Scaling 与恢复、重启、故障转移或替换操作相关联。
如果控制台拒绝，请记住以下清单： 检查正确区域中的健康事件清除缓存和 Cookie，更换浏览器，并与 IT 部门确认 AWS 域未被屏蔽。这些简单的检查能解决的问题远超您的想象。
相关资源和帐户帮助
为了扩大和加强您的业务，请查看所涉及服务的文档。 AWS Health 和 EventBridge 用于事件路由，ACM 用于续订，CloudWatch/EC2 参考用于指标和操作。，组成一个强大的套件。
- AWS 健康仪表板：公共和帐户特定事件的可见性，无需额外配置。
- 亚马逊EventBridge：可靠地获取健康事件，并采用灵活的规则路由到多个目的地。
- AWS 证书管理器 (ACM)：续订状态跟踪和到期前的分阶段通知。
- 亚马逊 EC2 + CloudWatch：每分钟检查次数、状态指标以及触发自动响应的警报。
如果您对访问或管理您的帐户有任何疑问，请参阅最常见的支持文章： 如何创建和激活新帐户、如何登录控制台以及如何请求有关您的帐户和资源的帮助。。找到它们可以加快出现问题时的解决速度。
只看一个面板并不能说明全部情况： 检查 AWS 的健康状况需要结合健康仪表板的上下文、EventBridge 的可靠提取、ACM 信号和 EC2 检查。有了深思熟虑的警报和清晰的剧本，即使在流量增加或出现区域动荡的情况下，诊断也会更快，响应也会更准确，运营也会变得更加顺畅。
