Pricing
Status historyRSS updatesStatus API

Powered by Uptimus

    Amazon Web Services 中断历史

    45 Amazon Web Services incidents · 2025年6月 — official updates, affected components, duration and resolution details.

    返回当前状态

    [resOLVED] 高发包损失

    开始时间 2026年10月4日 UTC 16:14 · 2h 42m

    Issues轻微事件
    1. 2026年10月4日 UTC 16:14resolved

      我们正在调查欧盟-SUTH-2区域高升的包裹损失.

    2. 2026年10月4日 UTC 16:36resolved

      在欧盟-SUTH-2区域,我们正经历一个单一可用区(eus2-az1)的日益严重的包装损失。 这个问题还导致其他工作流程和AWS Services的API延迟和出错率上升. 工程师们自动参与,并正在努力查明根源并减轻这一问题。 我们将在上午10时15分之前或一旦获得新的信息,向您提供另一个最新情况.

    3. 2026年10月4日 UTC 17:06resolved

      我们仍在努力在欧盟-SUTH-2区域以一个单一的可用区(eus2-az1)来减轻高包损失。 我们看到,由于多项平行努力,出现了一些改善的迹象。 我们继续努力确认根源并充分缓解这一问题。 虽然我们目前没有估计我们的行动将持续多久,但我们将随时向你们通报我们的进展情况,并在上午11点之前或在获得新信息后尽早向你们提供新的最新情况.

    4. 2026年10月4日 UTC 17:56resolved

      我们已查明了根源,目前正在集中我们的减灾努力来推动全面恢复。 虽然我们没有确切估计我们目前的努力需要多长时间,但我们确实期望看到随着我们的努力的进行而逐步改进. 我们将在上午11点45分之前,或在获得新资料之前,向你们提供另一个最新情况.

    5. 2026年10月4日 UTC 18:45resolved

      我们看到恢复的早期迹象。 我们会在中午12点前再给你一份最新消息.

    6. 2026年10月4日 UTC 18:56resolved

      8:48 AM至11:28 AM PDT之间,我们在欧盟-SUTH-2区域的一个单一可提供区(eus2-az1)内,经历了高发的包损失。 这个问题导致多个工作流程和AWS服务的API延迟和出错率提高. 早上8:54,我们自动被提醒注意这个问题,并立即着手查明根源,同时采取多条平行途径来缓解这一问题。 到上午10点,我们的缓解努力已导致一些改进。 到上午10:38时,我们确定与网络配置变化有关的根本原因,我们得以在上午11:28时恢复导致全面缓解的变革。 问题已经解决,服务正常运行.

    自动翻译自官方事件更新。

    [重 误差率上升

    开始时间 2026年9月21日 UTC 23:26 · 58m

    Issues轻微事件
    1. 2026年9月21日 UTC 23:26resolved

      我们正在调查美国-EAST-1地区增加的API误差率.

    2. 2026年9月21日 UTC 23:44resolved

      我们可以确认影响新实例发射的增高出错率,包括RunInstances, CreatFleet的API出错率以及美国-EAST-1区域的相关EC2出错率. 试图推出新的EC2的客户可能遇到发射故障或API反应延迟度提高. 我们的工程师正在积极地参与和努力恢复这一问题。 我们看到恢复的初步迹象。 现有情况没有受到影响。 我们建议重试失败的 RunInstances 和 CreateFleet API 调用 。 我们将在5: 30前提供最新消息.

    3. 2026年9月22日 UTC 00:24resolved

      3:49至5:06 PM PDT之间,我们经历了更高的出错率,影响到美国-EAST-1地区新的发射实例。 在此期间,客户在试图通过RunInstances,CreatFleet以及相关的EC2启动工作流程推出新的EC2实例时,可能经历了较高的出错率. 在此期间,为客户推出EC2实例的AWS服务也受到影响,其中包括亚马逊ECS、AWS Fargate、亚马逊EMR等。 我们查明了根源,这是最近向EC2服务中负责处理发射请求的子系统部署的一个原因。 我们开始撤回有问题的部署,并于下午4:44开始观察初步恢复迹象。 现有情况没有受到影响。 问题已经解决,服务正常运行.

    自动翻译自官方事件更新。

    [RESOLVED] 增加的API出错率

    开始时间 2026年9月3日 UTC 21:49 · 2h 18m

    Issues轻微事件
    1. 2026年9月3日 UTC 21:49resolved

      从2:12 PM PDT开始,我们开始看到STS和Sign In的API误差率上升,在US-WEST-2区域使用SAML时。 我们的工程组在下午2点19分 自动投入调查根源 目前没有工作可做。 我们将在下午3点半前提供最新消息.

    2. 2026年9月3日 UTC 22:26resolved

      我们看到恢复的早期迹象并继续监测全面恢复的情况。 我们将在下午4点15分再次提供最新消息.

    3. 2026年9月3日 UTC 23:20resolved

      我们继续看到美国-WEST-2区域的STS AssumeRoleWithSAML和AssumeRoleWithWebIDentity API的恢复保持稳定。 出错率现已恢复到事前水平,我们继续积极监测,以确认完全恢复. 我们将在下午5点15分或更早时再提供最新情况.

    4. 2026年9月4日 UTC 00:07resolved

      在下午2点12分到下午3点18分之间,我们经历了增加的API误差率,影响到美国-WEST-2地区的STS AssumeRoleWithSAML和AssumeRoleWithWebIDentity API。 其根源确定是由于一个负责与外部身份提供者沟通的STS子系统出现问题。 其他依靠这些身份联合会协议的AWS服务也受到了影响. 下午3点18分,我们观察到恢复的迹象并继续监测,以确保稳定和全面恢复。 问题已经解决,服务目前正常运行.

    自动翻译自官方事件更新。

    [重 误差率上升

    开始时间 2026年8月21日 UTC 02:02 · 38m

    Issues轻微事件
    1. 2026年8月21日 UTC 02:02resolved

      北区 我们在AP-NORTHEAST-1地区正经历越来越多的误差率影响实时测量。 客户可能遇到缺少或延迟实时计量数据的情况.

    2. 2026年8月21日 UTC 02:40resolved

      8:58 AM 10:34 AM AP-NORTHEAST-1 亚马逊联通 (例:人員の確認ブロック). 10:13 AM QQ 10:34 AM 在4:58和6:34 PM PDT之间,我们遭遇了影响AP-NORTHEAST-1区域亚马逊连接的实时度量的更长时间的拖延,导致数据缺失或陈旧. 在此期间,客户在分析报告中可能遇到缺失数据,如果在接触流程中利用实时衡量标准,如检查代理人员配备,则可能发现存在问题。 我们查明了造成问题的根本原因,即负责衡量事件的分系统。 我们于下午6点13分开始应用缓解措施, 问题已经解决,服务正常运行.

    自动翻译自官方事件更新。

    [重 误差率上升

    开始时间 2026年8月19日 UTC 15:15 · 3h 32m

    Issues轻微事件
    1. 2026年8月19日 UTC 15:15resolved

      我们正在调查一个影响在欧盟-WEST-2区域新启动的可提供区(euw2-az4)推出新的EC2案例和资源的问题。 在此期间,受影响客户在本区域创造或修改资源时可能会遇到问题。 其他AWS服务也可能受到影响. 为了立即恢复,我们建议客户酌情使用替代可用区(euw2-az1、euw2-az2和euw2-az3)。 现有的运行实例和资源没有受到影响。 我们将在上午10点之前提供另一个最新情况,或者如果有更多的信息要分享,则更早提供.

    2. 2026年8月19日 UTC 17:03resolved

      8月18日,我们在欧盟-WEST-2区域启动了一个新的供应区(euw2-az4)。 发射后,我们开始在新的可用区遇到发射EC2的失误,当时没有默认子网。 我们可以确认,现有的运行实例和资源没有受到影响。 工作流程通过可描述性区API自动获得区域可用区列表,然后试图在新的可用区启动新的实例或创造资源,可能会出错。 对于EC2的发射失败,我们正采取缓解步骤,在EC2的发射针对新的可提供区时,自动创建默认子网,而目前还没有这样的子网。 对于需要立即补救的客户和工作流程,<a href='https://docs.aws.amazon.com/vpc/latest/userguide/work- with-default-vpc.html#create-default-subnet>>您可以在新的可用区创建默认子网</a>. 这将使EC2实例发射成功完成. 对于其它资源,例如Lambda功能,目前没有支持新的可提供区,我们建议客户更新工作流程,以排除新启动的可提供区,并继续利用该地区其他可提供区创造资源。 虽然我们没有确切的估计 我们的缓解努力需要多长时间, 我们将随时向您提供最新进展.

    3. 2026年8月19日 UTC 18:47resolved

      8月18日下午5点至8月19日上午11:00, 我们在欧盟-WEST-2区域新推出的可提供区(euw2-az4), 在新的可用区启动后,我们开始在使用默认的VPC时遇到出错. 我们于8月19日早上9点发现了问题的根源, 在变化中,我们开始看到新发射的逐渐改进,在上午11点完全恢复。 现有的运行实例和资源没有受到影响。 一些区域服务,如Lambda功能或Aurora数据库,在新的可提供区启动时尚未提供,服务提供情况将随着时间的推移而增加。 试图在提供服务之前创造资源的客户将看到一个信息,即它没有在提供区得到支持。 问题已经解决,服务正常运行.

    自动翻译自官方事件更新。

    [重 增加的包装损失

    开始时间 2026年8月15日 UTC 03:42 · 3d 0h

    Issues轻微事件
    1. 2026年8月15日 UTC 03:42resolved

      我们正在调查增加的包丢失情况,影响到欧盟-加泰罗尼亚一区一些客户的AWS直接连接连接.

    2. 2026年8月15日 UTC 04:42resolved

      我们可以确认欧盟-CENTRAL-1地区直接连接的包丢失。 工程师们被自动雇用,并立即开始工作,既要找出根源,又要找出减轻这一问题的多条平行道路。 目前,我们看到恢复的早期迹象。 我们将在60分钟后再次提供最新情况,如果有需要分享的更多信息,则更早提供.

    3. 2026年8月15日 UTC 05:55resolved

      从7:33 PM PDT开始,我们开始看到AWS直接连接对欧盟-CENTRAL-1区域一些客户的连通性造成越来越多的包丢失. 虽然我们取得了进展,但与下列直接连接地点的连接仍然受损:Equinix FR5, Frankfurt, DEU. 拥有多站点冗余配置其直接连接路径的客户此时不应观察影响. 仅在Equinix FR5,法兰克福,DEU地点有连接的客户将继续遇到连接问题. 我们正积极努力减轻影响并努力实现全面恢复,但预计全面恢复需要几个小时的时间。 我们将在90分钟后提供最新情况,如果有更多的信息要分享,则更早提供.

    4. 2026年8月15日 UTC 07:24resolved

      我们正在积极努力通过直接连接地点恢复连接:Equinix FR5,法兰克福,DEU. 仅在Equinix FR5,法兰克福,DEU地点有连接的客户将继续遇到连接问题. 对于有选择权的受工作影响的客户,建议他们这样做,以实现恢复。 对于使用直接连接网关和中转网关的客户,我们建议创建一个AWS Site-Site VPN并附在您的中转网关上,参考步骤<a href='https://aws.amazon.com/premiumsupport/knowledge-center/dx-confect-dx-和-vpn-fellowover-tgw/'>>这里</a>. 对于其他客户,我们建议建立一个AWS Site-Site VPN作为临时备份路径,请参考步骤<a href='https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html>这里<a>。 此时此刻,我们预计恢复会持续多小时。 我们将在90分钟后再次提供最新情况,如果有需要分享的更多信息,则更早提供.

    5. 2026年8月15日 UTC 09:08resolved

      我们继续努力恢复位于德国法兰克福的Equinix FR5的AWS直接连接连接。 其根源与影响网络基础设施的地点的设施基础设施问题有关。 仅在该地点有连接的客户将继续经历包丢失或连接退化。 具有多地点或多余配置的客户不受影响。 就工作而言,建议有选择权的受影响客户放弃VPN。 对于使用直接连接网关和中转网关的客户,我们建议创建AWS站点对站点VPN,并附在您的中转网关上,参见"https://aws.amazon.com/premiumsupport/knowledge-center/dx-conform-dx-和-vpn-failover-tgw/"等步骤 </a>. 对于其他客户,我们建议建立一个AWS Site-Site VPN作为临时备份路径,请参考"https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">这里 </a>. 此时此刻,我们预计恢复会持续多小时。 我们将在2小时之内或一旦有更多的信息可以分享后立即提供另一个最新情况.

    6. 2026年8月15日 UTC 11:10resolved

      AWS直通互联互通对于在德意志国法兰克福的Equinix FR5站点连接的客户来说仍然不利. 其他地点具有多站点或多余配置的客户继续受到影响。 工程师们正在积极努力恢复连通性,在多个工作流程中正在努力解决潜在的设施问题,使受影响的网络设备恢复服务。 我们仍然期望恢复会持续多小时。 就工作而言,可选择退出VPN的受影响客户建议这样做。 对于使用直接连接网关和中转网关的客户,我们建议创建AWS站点对站点VPN,并附在您的中转网关上,参见"https://aws.amazon.com/premiumsupport/knowledge-center/dx-conform-dx-和-vpn-failover-tgw/"等步骤 </a>. 对于其他客户,我们建议建立一个AWS Site-Site VPN作为临时备份路径,请参考"https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">这里 </a>. 我们将在2小时之内或一旦有更多的信息可以分享后立即提供另一个最新情况.

    7. 2026年8月15日 UTC 13:17resolved

      工程师们在德意志统一联邦法兰克福的Equinix FR5站点继续努力恢复连接. 我们的同地办公伙伴正在努力解决潜在的设施基础设施问题,虽然客户尚未看到改进,但我们在解决方面正取得积极进展。 对于需要立即恢复的客户,我们建议如我们先前的更新中所概述的那样,向VPN失败。 我们将在上午9:30之前提供另一个最新情况,或者如果我们有额外信息要分享,则更早.

    8. 2026年8月15日 UTC 16:27resolved

      我们合用同一地点的合作伙伴继续努力解决位于德意志联邦法兰克福的Equinix FR5地点的基本设施问题。 由于安全考虑,目前进入受影响地区受到限制,这影响到我们评估网络设备实际状况的能力,并提供了更准确的恢复时间表。 根据目前的资料,预计近期内不会完全恢复,而且可能延续到今天以后。 这个位置的AWS直通连接仍然受损. 通过其他地点有多余联系的客户没有受到影响。 对于使用直接连接网关和中转网关的客户,我们建议创建AWS站点对站点VPN,并附在您的中转网关上,参见"https://aws.amazon.com/premiumsupport/knowledge-center/dx-conform-dx-和-vpn-failover-tgw/"等步骤 </a>. 对于其他客户,我们建议建立一个AWS Site-Site VPN作为临时备份路径,请参考"https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">这里 </a>. 我们将在下午3: 30前提供最新消息.

    9. 2026年8月15日 UTC 22:26resolved

      我们的同地办公伙伴正在继续努力,恢复安全进入位于欧盟法兰克福的Equinix FR5地段的受影响地区。 一旦安全进入,我们的工程师将能够评估受影响的网络设备。 我们将继续密切跟踪进展情况,并将在9:30前分享最新情况,或者在获得新信息后尽早分享.

    10. 2026年8月16日 UTC 04:37resolved

      我们正在积极与我们同地办公的伙伴进行接触,以恢复位于德国法兰克福的Equinix FR5地点的连接。 自上次更新以来,我们在恢复安全进入位于德国法兰克福的Equinix FR5地段受影响地区方面取得了逐步进展。 与此同时,我们优先考虑恢复关键和高度优先的架子,作为缓解努力的一部分。 根据我们目前的评估,预计近期内不会完全恢复,而且可能延续到今天以后。 这个位置的AWS直通连接仍然受损. 完全在这个地点有联系的客户将继续丢失包。 具有跨其他直接连接地点的多站点或冗余配置的客户不受影响。 就工作而言,建议有选择权的受影响客户放弃VPN。 对于使用直接连接网关和中转网关的客户,我们建议创建AWS站点对站点VPN,并附在您的中转网关上,参见"https://aws.amazon.com/premiumsupport/knowledge-center/dx-conform-dx-和-vpn-failover-tgw/"等步骤 </a>. 对于其他客户,我们建议建立一个AWS Site-Site VPN作为临时备份路径,请参考"https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">这里 </a>. 我们将继续密切跟踪进展情况,并将在8月16日凌晨3:30之前分享最新情况,或者在获得新信息后尽早分享.

    11. 2026年8月16日 UTC 10:25resolved

      我们继续与合用同一地点的伙伴合作,恢复在德国联邦首都法兰克福的Equinix FR5地点的连接。 自我们上次通报以来,我们在恢复安全进入受影响地区方面已取得重大进展。 电气隔离程序正在进行中,我们的小组在电气室现场对受影响的基础设施进行去功能化。 一旦隔离得到核实和确认安全,工程师将开始对受影响的网络设备进行实际检查,以确定所需的更换范围。 根据目前的评估,由于可能影响到设备的范围,预计近期内不会完全恢复。 这个位置的AWS直通连接仍然受损. 完全在这个地点有联系的客户将继续丢失包。 具有跨其他直接连接地点的多站点或冗余配置的客户不受影响。 就工作而言,建议有选择权的受影响客户放弃VPN。 对于使用直接连接网关和中转网关的客户,我们建议创建AWS站点对站点VPN,并附在您的中转网关上,参见"https://aws.amazon.com/premiumsupport/knowledge-center/dx-conform-dx-和-vpn-failover-tgw/"等步骤 </a>. 对于其他客户,我们建议建立一个AWS Site-Site VPN作为临时备份路径,请参考"https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">这里 </a>. 我们将继续密切跟踪进展情况,并将在8月16日9:30之前,或在获得新信息后尽早分享最新情况.

    12. 2026年8月16日 UTC 16:30resolved

      在法兰克福的Equinix FR5的电气隔离现已完成,我们的工程师已开始对被影响的网络设备进行实际检查。 在我们继续评估对设备影响的程度时,我们还没有全面解决的时间表。 此位置的直通连接仍然受损. 完全在这个地点有联系的客户将继续丢失包。 具有跨其他直接连接地点多站点或冗余配置的客户不受影响. 我们建议,受影响客户在进一步明确下一步步骤和回收时间表之前,不要进入VPN。 对于使用直接连接网关和中转网关的客户,您可以创建AWS站点对站点的VPN并附在您的中转网关上,参见"https://aws.amazon.com/premiumsupport/knowledge-center/dx-conform-dx-和-vpn-failover-tgw/""这里". 对于其他客户,我们建议建立一个AWS Site-Site VPN作为临时备份路径,参见"https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html" >here </a>. 我们将在8月16日5:30之前提供另一个最新情况,或者在获得新信息之前提供.

    13. 2026年8月16日 UTC 22:51resolved

      我们已完成了对位于法兰克福的Equinix FR5地段受影响的网络设备的评估,现在对影响范围有了明确的了解。 我们正在恢复连通性方面取得进展,并将采取分阶段的补救办法。 仅在该地点有连接的客户将继续遭受包件损失,直至补救完成。 具有跨其他直接连接地点多站点或冗余配置的客户不受影响. 我们将在8月16日10:30之前,或者在获得新信息之前,提供另一个最新情况.

    14. 2026年8月17日 UTC 05:38resolved

      我们继续在位于德国法兰克福的Equinix FR5地点进行分阶段补救。 自上次更新以来,一些依赖性的网络基础设施已经恢复。 其余基础设施的修复工作正在进行,部分恢复工作取决于更换硬件的交付。 已全面恢复冷却,环境条件稳定在正常运行阈值以内. 随着补救工作的进展,完全在这个地点有联系的客户将继续遭受包件损失。 具有跨其他直接连接地点多站点或冗余配置的客户不受影响. 以前通报的缓解指导意见和建议目前保持不变。 我们将在8月17日凌晨4: 30之前, 或随着补救的进展.

    15. 2026年8月17日 UTC 11:22resolved

      我们继续在位于德国法兰克福的Equinix FR5地点进行分阶段补救。 随着受影响的硬件重新上线,网络基础设施和附属系统继续得到改进。 一些更换的硬件已经交付,随着部件到达现场,正在安装。 与此同时,我们正在改变网络流量,以便恢复设备在客户上线时开始服务客户。 随着我们逐步恢复,客户将分两个阶段观察恢复情况。 在第一阶段,BGP会话会重新建立,但IP前缀尚未公布,这表明恢复仍在进行,而基础基础设施尚未准备好承接交通. 在第二阶段,IP前缀广告将恢复,届时基础设施将得到充分补救并恢复连接。 虽然我们目前还没有全面恢复的ETA,但我们继续尽可能快和安全地努力减轻对客户的影响。 我们将在8月17日10:30之前,或随着补救的进展,提供另一份最新情况.

    16. 2026年8月17日 UTC 16:25resolved

      我们继续逐步在德意志民主联邦法兰克福的Equinix FR5地点进行分阶段补救。 我们正在看到恢复的早期迹象,同时我们继续充分纠正这一问题。 我们正积极努力将其余受影响的硬件重新上线,我们将在下午12:30之前,或随着补救的进展,提供另一个更新.

    17. 2026年8月17日 UTC 17:59resolved

      在德国法兰克福的Equinix FR5号地点,我们看到广泛的复苏迹象。 我们恢复了大多数受影响的硬件的连通性,大多数连接已经完全恢复和稳定。 少数客户仍然会受到影响,直到剩余设备完全恢复. 我们将在下午2点之前, 或随着补救的进展.

    18. 2026年8月17日 UTC 21:00resolved

      我们继续努力使受影响的硬件重新上网。 自从我们上次更新以来,我们取得了进展,客户不会看到,而是为了恢复。 我们同时努力尽可能安全地将所有设备上线。 这项工作预计需要几个小时才能完成和验证。 对于需要变通的顾客,我们建议你考虑失败到VPN. 对于使用直接连接网关和中转网关的客户,您可以创建AWS站点对站点的VPN并附在您的中转网关上,参见"https://aws.amazon.com/premiumsupport/knowledge-center/dx-conform-dx-和-vpn-failover-tgw/""这里". 对于其他客户,我们建议建立一个AWS Site-Site VPN作为临时备份路径,参见"https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html" >here </a>. 我们将在7:00前或一旦获得新信息后,提供另一个最新情况.

    19. 2026年8月18日 UTC 01:50resolved

      现阶段,大多数客户的连接都恢复了 虽然我们尚未完全恢复,但恢复努力正如欧盟法兰克福的Equinix FR5地点所预期的那样取得进展。 其余基础设施的修复工作包括完成硬件更换和交通验证,这两个工作正在积极进行。 随着其余的基础设施重新投入使用,我们预计客户可以看见的进一步恢复。 仅在该地点有连接的客户将继续遭受包件损失,直至补救完成。 以前通报的缓解指导意见和建议目前保持不变。 我们将在8月17日11点前 或更早提供最新消息.

    20. 2026年8月18日 UTC 04:01resolved

      从8月14日7:33 PM PDT开始, 我们经历了越来越多的包丢失 影响AWS 直接连接连接 客户与连接 在德国法兰克福的Equinix FR5 地点。 8月14日下午7:45工程师自动被雇用,并立即开始调查缓解措施. 8: 30前,我们发现FR5地点的网络设备因水入侵同地设施而受损. 因此,冷却系统受损,导致设备过热并关闭。 水还影响到电源分配系统,使电网设备的电源失效。 由于设施内的环境条件需要稳定下来,工程人员才能安全进入受影响地区,初步恢复工作被推迟。 在整个8月15日和16日,我们的工程师与设施运营商协调,修复受损的网络装置,同时解决基本的基础设施问题。 至8月17日7:26,已成功恢复所有受损的网络设备,并核实与该地的连通性已全面运行并持续恢复. 我们不期望这个问题再次发生。 在整个活动期间,具有跨其他直接连接地点的冗余连接的客户通过其他途径维持连接,无需采取进一步行动。 实施VPN的客户作为变通工作,现在可以安全地回到他们的主要直接连接路径。 经核实,连通性稳定并充分运作。 需要进一步援助的客户可通过AWS管理控制台或<a href='https://console.aws.amazon.com/ support'>AWS支持中心</a>与AWS支持联系.

    自动翻译自官方事件更新。

    [重回]高档包装损失

    开始时间 2026年7月31日 UTC 17:33 · 1h 21m

    Issues轻微事件
    1. 2026年7月31日 UTC 17:33resolved

      我们可以确认网络包丢失增加,影响AP-SUTH-1区域的AWS直接连接连接。 我们的工程队在上午9点54分 自动开始调查此事 目前没有工作余地。 我们将在上午11时30分之前提供另一个最新情况.

    2. 2026年7月31日 UTC 18:27resolved

      我们查明了与改变配置系统负责为设备分配路线有关的根源。 我们已开始开展工作,以减少在AP-SUTH-1区域影响AWS直接连接的包损失,我们预计在今后30分钟内将逐步恢复。 随着我们对这些努力的信心得到增强,我们将努力同步加快恢复。 我们将在中午12点前提供另一个最新情况.

    3. 2026年7月31日 UTC 18:54resolved

      9:42 AM至11:44 AM PDT之间,我们经历了AWS直通连接在AP-SUTH-1区域受到的网络包损失上升. 我们的工程组在上午9点46分 自动开始调查 到了上午10点51分,我们理解根本原因是对一个负责为设备分配路线的系统进行配置改变. 随着我们对减缓措施的信心增加,我们同时努力进一步减少损失。 问题解决了,服务正常运行.

    自动翻译自官方事件更新。

    [重 连通性问题

    开始时间 2026年7月24日 UTC 11:40 · 1h 21m

    Issues轻微事件
    1. 2026年7月24日 UTC 11:40resolved

      我们正在调查影响美国-WEST-2区域多个AWS服务的敌对问题.

    2. 2026年7月24日 UTC 11:56resolved

      我们看到恢复的初步迹象,并继续努力实现全面恢复.

    3. 2026年7月24日 UTC 12:30resolved

      我们仍然看到,由于我们努力减缓影响美国-WEST-2区域多个AWS服务的连通性问题,出现了重大的复苏迹象。 我们已经确定,根源是一个问题,有一个网络设备负责网络线路从区域到西雅图地铁。 工程师们完成了所有的缓解工作. 随着线路的继续恢复,客户在连接受影响的服务时,应看到出错率和超时率继续下降。 我们正在密切监测恢复进展情况,并将继续工作,直至所有路线完全恢复,服务指标恢复到事前水平。 我们将在今后30-45分钟提供另一个最新情况.

    4. 2026年7月24日 UTC 13:01resolved

      3:55至4:15 AM PDT, 我们经历了连接问题, 这影响到该地区多个AWS服务机构。 一些客户还可能遇到接入AWS管理控制台的问题,出现连接超时和无响应的页面. 区域内的连通性没有受到影响。 我们的工程师在4: 01 AM PDT自动订婚,并立即开始调查这个问题. 我们把根源确定为一个网络设备的问题,这些网络设备负责从该区域到西雅图地铁的网络线路,并开始在多条路径上并行工作来减轻影响。 我们采取了缓解措施,导致在凌晨4点15分恢复。 在我们的缓解行动之后,该网络继续稳定下来,在4:47和4:59之间发生了短暂的重新发现事件。 在这一重组期间,随着网络路线的重建,一些客户可能会遇到与区域间断的连接问题. 至4:59AM PDT,所有路线已完全恢复,服务度量衡恢复到事前水平. 西雅图Westin Building Exchange使用AWS Direct Connect通过EqSe2,西雅图Westin Building Exchange的客户经历了从3:55到5:12AM PDT的延伸撞击窗口. 在5:12AM PDT完全恢复这一具体路径的网络线路之前,这些客户会遇到连接问题. 通过其他AWS直接连接地点冗余连接的客户没有受到这一事件的影响. 这个问题已经解决,所有AWS服务都在正常运行.

    自动翻译自官方事件更新。

    [RESOLVED]不准确的估计账单数据

    开始时间 2026年7月17日 UTC 08:33 · 1d 5h

    Issues轻微事件
    1. 2026年7月17日 UTC 08:33resolved

      我们正在与成本探索公司调查反映不准确的估计账单数据的问题.

    2. 2026年7月17日 UTC 09:07resolved

      从7月16日7:38 PM PDT开始,我们开始在计费和成本管理控制台上显示不正确的估算计费数据. 我们的工程队正在参与并调查根源。 我们将在下午3点之前提供另一个最新情况,或者在获得更多信息时更早.

    3. 2026年7月17日 UTC 10:03resolved

      我们继续努力解决影响计费和成本管理控制台显示的估计费用和使用数据的问题。 我们已查明其根源是估计计费子系统内单位定价的一个问题,我们正在努力减轻影响。 显示的计费估计数没有反映实际使用情况和费用。 目前不需要客户采取行动。 一旦该问题得到缓解,我们期望在重新计算估算的账单数据时,需要数小时才能完全解决。 我们将在下午4点之前提供另一个最新情况,或者在获得更多信息时提前提供.

    4. 2026年7月17日 UTC 10:52resolved

      我们继续努力解决影响计费和成本管理控制台显示的估计费用和使用数据的问题。 正如以前一样,我们已查明根源是计算分系统估计数内的单位定价问题。 为防止进一步显示不准确的计费估计数,我们暂停了估算的计费计算。 目前看到正常账单估计数的客户将继续看到这些估计数,看到过高估计数的客户在我们努力解决问题时不会看到这些估计数进一步增加。 显示的计费估计数没有反映实际使用情况和费用。 我们继续努力全面缓解这一问题。 一旦该问题得到缓解,我们期望在重新计算估算的账单数据时,需要数小时才能完全解决。 目前不需要客户采取行动。 我们将在下午5点之前提供另一个最新情况,或者在获得更多信息时提前提供.

    5. 2026年7月17日 UTC 11:58resolved

      我们继续努力解决影响计费和成本管理控制台显示的估计费用和使用数据的问题。 我们正积极探索平行的多条减缓路径。 第一个途径是恢复最后已知的良好估计账单计算。 采用这一办法,客户到7月15日才能看到成本和使用数据,但过高的费用数据将被删除。 第二种途径是将最近对计费次系统的改动推回。 显示的计费估计数没有反映实际使用情况和费用。 目前不需要客户采取行动。 一旦该问题得到缓解,我们期望在重新计算估算的账单数据时,需要数小时才能完全解决。 我们将在上午6点之前,或在获得更多信息时提前提供另一个最新情况.

    6. 2026年7月17日 UTC 12:54resolved

      我们继续同时研究多种减缓途径,以解决影响计费和成本管理控制台显示的估计费用和使用数据的问题,包括《成本和使用报告》。 我们正在评估恢复估计的计费计算,因为我们的内部监测显示,计费计算子系统现在正在产生准确的估计。 我们正在进行更多的验证,然后才能走上这条道路。 显示的计费估计数没有反映实际使用情况和费用。 目前不需要客户采取行动。 我们将在上午8点之前提供另一个最新情况,如果有更多信息,则更早提供.

    7. 2026年7月17日 UTC 14:53resolved

      我们继续努力解决影响计费和成本管理控制台显示的估计费用和使用数据的问题,包括《成本和使用报告》。 最近的变化的回落并没有解决问题,我们正在继续调查多种减缓路径。 账单更新估计仍被暂停。 我们正在恢复最后一份准确的估计账单数据。 显示的计费估计数没有反映实际使用情况和费用。 目前不需要客户采取行动。 我们预计,在重新计算估算的账单数据时,这种缓解需要几个小时才能完成。 我们将在上午10点之前提供另一个最新情况,或者在获得更多信息时提前提供.

    8. 2026年7月17日 UTC 16:59resolved

      我们查明了根源,并缓解了造成不正确的成本和使用估计数据在账单和成本管理控制台以及成本和使用报告中显示的根本问题。 我们已开始回填数据,以纠正所有客户的成本数据。 我们期望一些客户在未来三个小时内开始恢复,所有客户在7月18日中午12点前全面恢复。 在回填完成之前,一些客户可能仍然看到不正确的成本和使用数据. 显示的计费估计数没有反映实际使用情况和费用。 目前不需要客户采取行动。 我们将在下午1点之前提供另一个最新情况,或者在得到信息后提前提供.

    9. 2026年7月17日 UTC 19:56resolved

      我们仍在努力回填已更正的估计费用和使用数据。 我们的进展比预期的要慢。 虽然我们看到一些账户以正确的成本和使用数据得到恢复,但我们期望所有受影响的账户都能在7月19日中午12时以前得到恢复。 在回填完成之前,一些客户可能仍然看到不正确的成本和使用数据. 显示的计费估计数没有反映实际使用情况和费用。 目前不需要客户采取行动。 我们将在下午7点之前提供另一个最新情况,或者在得到信息后提前提供.

    10. 2026年7月18日 UTC 01:38resolved

      我们在解决影响账单和成本管理控制台显示的估计费用和使用数据的问题方面继续取得稳步进展。 我们仍在努力回填更正后的数据,我们期望所有受影响的账户在7月19日中午12时前全部收回。 在回填完成之前,一些客户可能仍然在计费和成本管理控制台以及成本和使用报告中观察到不正确的成本和使用数据. 这些估计数没有反映实际使用情况或费用。 用"Overwrite"选项配置其"成本与使用报告"的客户不需要任何动作——一旦回填完成,他们的报告将自动被修正后的数据所更新. 用"创建新报告版本"选项配置其成本和使用报告(Cost and Usage Report)的客户,将之前的报告交付全部保留在其S3桶中. 在受影响的窗口提供的报告版本可能包含不准确的数据。 数据回填完成后,将在新的组装Id下提供更正后的报告版本. 使用此配置的客户应当更新任何下游进程(雅典娜表格,Redshift管线,亚马逊快视,或自定义ETL),以参考受影响的计费期的最新组装Id,并可以删除或归档受影响的报告版本来防止处理过时数据. 为了确定最新的报告,客户可以使用https://docs.aws.amazon.com/cur/latest/userguide/view-latest-cur.html > documentation </a>中的步骤。 我们将在7月18日凌晨1点之前提供另一个最新情况,或者在获得更多信息时提前提供.

    11. 2026年7月18日 UTC 08:05resolved

      我们在解决影响计费和成本管理控制台显示的估计费用和使用数据的问题方面继续取得重大进展。 我们的缓解努力正在按照预期进行,我们看到越来越多的账户反映了正确的成本和使用数据。 我们期望所有受影响的账户在7月19日中午12:00之前全部收回。 在回填完成之前,一些客户可能仍然在计费和成本管理控制台以及成本和使用报告中观察到不正确的成本和使用数据. 这些估计数没有反映实际使用情况或费用。 我们将在7月18日,即上午7:00之前,或者在获得更多资料之前,提供另一份最新情况.

    12. 2026年7月18日 UTC 13:57resolved

      从7月16日7:38 PM PDT到7月18日6:00 AM PDT,我们开始在计费和成本管理控制台上显示不正确的估计账单数据,包括成本和使用报告. 客户可能收到错误的预算和费用异常发现警报,并观察到估计成本和使用数据被夸大。 7月16日7:46 PMPDT, 我们的警报检测到成本异常, 7月17日12:19AMPDT被客户升级事件警告,立即开始调查. 我们于7月17日凌晨1点33分通过AWS Health首次通知顾客. 在上午8点24分,我们暂停了对估计账单数据的进一步更新,并关闭了预算和费用异常警报,作为一项预防措施。 我们在7月17日中午12点, 该系统依靠单位转换数据来计算行项目收费. 配置的改变导致单位转换数据更新失败,导致细列项目成本膨胀,向计费和成本管理控制台宣传并引发了预算和成本异常警报. 我们于7月17日中午12:30缓解了PMPDT问题,纠正了单位转换配置,并开始所有客户账户的后处理成本和使用数据. 我们从4点19分开始观察回收情况, 少数账户仍在处理中,我们将将这些账户的更新贴入个人健康板上。 我们已经纠正了警报 以立即停止处理 并在出现异常时通知我们的工程队 我们为这起事件引起顾客的震惊而道歉,并正在进行彻底的回顾,以防止此类事件再次发生,以及改进我们在计费时的反应。 这个问题已经解决,所有AWS服务现已正常运行.

    自动翻译自官方事件更新。

    [重 增加5xx错误

    开始时间 2026年7月16日 UTC 08:44 · 3h 38m

    Issues轻微事件
    受影响的组件
    Amazon CloudFront
    1. 2026年7月16日 UTC 08:44resolved

      我们正在调查Cloudfront客户使用VPC Origins连通性增加的5xx错误.

    2. 2026年7月16日 UTC 09:21resolved

      从12:45 AM PDT开始,我们发现CloudFront客户使用VPC Origins连接的5xx错误增加. 我们确认,使用其他原产地类型的客户不受这一问题的影响。 我们的工程师正在参与并积极努力减轻影响。 作为一种工作,不需要VPC Origins的客户可以改变其来源类型来解决出错. 我们将在下午3时15分之前,或在获得更多信息的情况下,提前提供另一个最新情况.

    3. 2026年7月16日 UTC 10:18resolved

      我们继续努力利用VPC Origins的连通性解决CloudFront客户增加的5xx错误。 使用其他原产地类型的客户仍然不受这一问题的影响。 根据我们的调查,我们相信根本原因与一个包处理子系统有关 负责从CloudFront的边缘位置 向客户VPC内部的资源发送请求 我们继续建议有能力的客户暂时改变原产地类型以解决错误. 我们将在下午4: 15之前提供另一个最新情况,或者在获得补充资料之前提供.

    4. 2026年7月16日 UTC 11:16resolved

      我们继续努力利用VPC Origins的连通性解决CloudFront客户增加的5xx错误。 使用其他原产地类型的客户仍然不受这一问题的影响。 我们进一步将问题范围缩小到包处理子系统内的路由表容量,负责从CloudFront的边缘位置到客户VPC内部的资源的路由请求。 我们已经确定并正在测试一项缓解战略来解决这一问题。 一旦测试完成,我们将分阶段部署缓解措施。 根据这些测试的结果,我们将在下一次更新中提供更明确的估计解决时间。 我们继续建议有能力的客户暂时改变原产地类型以解决错误. 我们将在下午5时15分之前,或者在获得补充资料之前,再次提供最新情况.

    5. 2026年7月16日 UTC 11:27resolved

      我们看到恢复的初步迹象,并继续努力实现全面恢复.

    6. 2026年7月16日 UTC 11:57resolved

      由于我们的减灾努力,我们继续看到恢复的重大迹象,预计在今后45分钟内全面恢复.

    7. 2026年7月16日 UTC 12:21resolved

      在12:45 AM到4:18 AM PDT之间,我们经历了CloudFront客户使用VPC Origins连接的5xx错误增加. 我们的工程师被自动雇用,并立即开始调查根源。 到了2:57AM PDT,我们确定问题的根源是管理与私人VPC起源的连接的舰队的内部制约. 当达到这个限制时,负责向我们的网络处理器分配路由配置的系统未能正确加载更新的配置数据,影响了VPC Origin连接的路由. 3:52AM PDT,我们采取了多起缓解行动,最终在4:18AM PDT完全恢复. 现在这个问题已经缓解了,暂时改变原产地类型的客户可以安全地恢复这些变化. 使用其他原产地类型的客户不受这一问题的影响。 问题已经解决,服务正常运行.

    自动翻译自官方事件更新。

    [恢复] 与单一可变区的联系问题加剧

    开始时间 2026年7月15日 UTC 23:11 · 2h 13m

    Issues轻微事件
    1. 2026年7月15日 UTC 23:11resolved

      我们正在调查与欧盟-中央TRAL-1区域单一可变区(euc1-az2)的连接性问题.

    2. 2026年7月15日 UTC 23:36resolved

      我们看到恢复的早期迹象,并继续努力争取全面解决。 我们将继续提供最新情况.

    3. 2026年7月16日 UTC 01:24resolved

      从下午2点56分到下午6点07分之间,我们在欧盟-中央TRAL-1区域的一个单一可用区(euc1-az2)经历了与EC2子集的连接问题。 在此期间,客户还可能遭遇到在受影响地区新发射的出错率和延迟,以及一些使用受影响的EC2实例的AWS API。 一些AWS Services还经历了连接问题,并增加了受影响地区的出错率. 工程师们自动订婚,并立即开始调查. 作为我们恢复努力的一部分,我们于下午3:04将受影响服务的交通从受影响供应区转移。 在下午3点05分,我们找出了造成这种影响的最近网络变化的根源。 工程师们立即开始恢复这一改变,于下午4:28完成。 这导致在下午4:30恢复与受影响地区的网络连接。 我们继续工作,直到下午6点07分完全恢复影响。 我们不期望这个问题再次发生。 问题已经解决,服务正常运行.

    自动翻译自官方事件更新。

    [RESOLVED] Increased Launch Template API Error Rates

    开始时间 2026年7月6日 UTC 12:45 · 2h 8m

    Issues轻微事件
    1. 2026年7月6日 UTC 12:45resolved

      We are investigating increased error rates when calling EC2 Launch Template APIs in US-EAST-1 Region. During this time, affected customers may experience errors when creating, modifying, or referencing launch templates. Other AWS services that rely on launch templates may also be impacted. We will provide another update by 6:30 AM PDT or sooner, if we have additional information to share.

    2. 2026年7月6日 UTC 13:34resolved

      Starting at 2:56 AM PDT, we began experiencing increased error rates when calling EC2 Launch Template APIs in the US-EAST-1 Region. Our engineers have been engaged and are actively working to mitigate the impact. Additionally, Amazon Elastic Kubernetes (EKS) customers may experience errors when creating or updating clusters, or when launching and scaling nodes via Managed Node Groups, EKS Auto Mode, or Karpenter; this issue does not impact existing clusters and nodes. We have identified the root cause to be a congestion issue within an EC2 internal subsystem responsible for processing EC2 launch template workflows. We are pursuing multiple mitigation paths. We recommend that customers retry any failed requests during the impact window. While we do not currently have an ETA for full recovery, we are prioritizing this issue and will provide another update by 7:15 AM PDT or sooner if we have additional information to share.

    3. 2026年7月6日 UTC 14:12resolved

      We are seeing initial signs of recovery and continue to work toward full recovery.

    4. 2026年7月6日 UTC 14:53resolved

      Between 2:56 AM and 6:54 AM PDT, we experienced increased error rates when calling EC2 Launch Template APIs in the US-EAST-1 Region. During this time, affected customers may have experienced errors when creating, modifying, or describing Launch Templates. Other AWS services that rely on Launch Templates were also impacted. Amazon EC2 instances and Amazon EKS workloads already running on provisioned nodes continued to operate normally. Cluster modification operations, and Managed Node Group creation were also impacted. For EKS Auto Mode, impact was limited to operations requiring new capacity or changes, including node provisioning and pod scheduling. Our engineers were automatically engaged and immediately began investigating the root cause. We identified the root cause as a congestion issue within an EC2 internal subsystem responsible for processing EC2 launch template workflows. At 3:26 AM PDT, we took mitigation actions by introducing throttling for the affected APIs and we saw some recovery which was communicated directly with a subset of customers via the 'Your Account view' of the AWS Health Dashboard. We took multiple additional mitigation paths, incrementally lifting these throttle limits, and by 6:54 AM PDT, the issue was fully mitigated. We recommend that customers retry any failed requests. The issue has been resolved and all AWS services are now operating normally.

    [RESOLVED] Increased Error Rates and Latencies

    开始时间 2026年6月30日 UTC 21:02 · 51m

    Issues轻微事件
    1. 2026年6月30日 UTC 21:02resolved

      We are investigating increased launch errors and API errors in the EU-NORTH-1 Region. Existing instances are not affected by this issue.

    2. 2026年6月30日 UTC 21:21resolved

      We can confirm increased error rates for the EC2 APIs, as well as errors launching new EC2 instances in the EU-NORTH-1 Region. Other AWS Services that launch new instances or call the EC2 APIs as part of their workflows may also be affected by this issue. During this time, customers may receive an Internal Server Error in the Management Console and APIs. Engineers were automatically engaged and began investigating the issue. We are actively working on identifying the root cause. Existing instances are unaffected by this issue. We will provide an update by 3:15 PM, or sooner if we have additional information to share.

    3. 2026年6月30日 UTC 21:29resolved

      We are seeing early signs of recovery and continue to work toward full recovery.

    4. 2026年6月30日 UTC 21:53resolved

      Between 1:42 PM and 2:25 PM PDT we experienced increased error rates and latencies for EC2 APIs in the EU-NORTH-1 Region. This issue also affected new instance launches. Other AWS Services that launch new instances or call EC2 APIs as part of their workflows were also affected by this issue. Existing EC2 instances were unaffected by this issue. During this time, customers would have received an Internal Server Error in the Management Console and APIs. Engineers were automatically engaged and began investigating the root cause. We identified the root cause as a planned configuration change. This change was reverted and we began observing recovery at 2:19 PM. By 2:25 PM, the issue was fully mitigated. We do not expect this issue to reoccur. Since the issue was mitigated at 2:25 PM, we have been processing a backlog for ELB workflows and expect this backlog to complete within the next 30 minutes. We recommend customers retry requests that failed during this time. The issue has been resolved and all services are operating normally.

    [RESOLVED] Fable 5 and Mythos 5 Access

    开始时间 2026年6月13日 UTC 01:26 · 2d 16h

    Issues轻微事件
    受影响的组件
    Amazon Bedrock (N. Virginia)
    1. 2026年6月13日 UTC 01:26resolved

      To support compliance with the US Government export control directive, Anthropic has asked us to revoke access to Claude Fable 5 and Claude Mythos 5 for all users in all regions. All other models, including Opus 4.8, are not affected and you can continue using them in full confidence. Please view the <a href="https://www.anthropic.com/news/fable-mythos-access">Anthropic statement</a> for further details.

    2. 2026年6月15日 UTC 18:13resolved

      Claude Fable 5 and Claude Mythos 5 models remain unavailable for all users in all regions. We are resolving this Health event. For further details please view the <a href="https://www.anthropic.com/news/fable-mythos-access">Anthropic statement</a>.

    [RESOLVED] Internet Connectivity Issues

    开始时间 2026年6月6日 UTC 04:24 · 0m

    Issues轻微事件
    1. 2026年6月6日 UTC 04:24resolved

      Between 5:50 PM and 7:15 PM PDT, we experienced connectivity issues that may have impacted Internet performance for some customers in the SA-EAST-1 Region. During this time, connectivity to instances and services within the Region was not affected. Our engineering team was automatically engaged at 5:51 PM PDT and immediately began investigating the issue. We identified the root cause and implemented a fix, which mitigated the issue at 7:15 PM PDT. The issue has been resolved and the service is operating normally.

    [RESOLVED] Increased API Error Rates

    开始时间 2026年5月22日 UTC 23:38 · 35m

    Issues轻微事件
    1. 2026年5月22日 UTC 23:38resolved

      We are investigating increased error rates for Route53 API calls.

    2. 2026年5月23日 UTC 00:13resolved

      Between 4:00 PM and 4:46 PM, we experienced increased error rates for the Route53 APIs. This issue did not impact resolution of existing DNS records. Engineers were automatically engaged and immediately began investigating the issue. During this time, customers may have received 500s for Route53 APIs and the Route53 Management Console. We have identified the root cause and have mitigated this issue. Other AWS Services that call the Route53 APIs in their workflows may also have been impacted during this time. We recommend retrying any failed operations or stuck workflows. We do not expect this issue to reoccur. The issue has been resolved and the service is operating normally.

    [RESOLVED] Increased Error Rate and Latency

    开始时间 2026年5月8日 UTC 00:25 · 1d 2h

    Issues轻微事件
    1. 2026年5月8日 UTC 00:25resolved

      We are investigating instance impairments in a single Availability Zone (use1-az4) in the US-EAST-1 Region. Other Availability Zones are not affected by the event and we are working to resolve the issue.

    2. 2026年5月8日 UTC 00:53resolved

      We continue to investigate instance impairments to a single Availability Zone (use1-az4) in the US-EAST-1 Region. We have experienced an increase in temperatures within a single data center, which in some cases has caused impairments for instances in the Availability Zone. EC2 instances and EBS volumes hosted on impacted hardware are affected by the loss of power during the thermal event. Other AWS services that depend on the affected EC2 instances and EBS volumes in this Availability Zone, may also experience impairments. We will continue to provide updates as recovery continues.

    3. 2026年5月8日 UTC 01:47resolved

      We continue to work towards mitigating the increased temperatures to its normal levels in the affected Availability Zone (use1-az4) in the US-EAST-1 Region. Other AWS services that depend on the affected EC2 instances and EBS volumes in this Availability Zone, may also experience impairments. We have weighed away traffic for most services at this time. We recommend customers utilize one of the other Availability Zones in the US-EAST-1 Region at this time, as existing instances in other AZ's remain unaffected by this issue. Customers may experience longer than usual provisioning times. We will provide an update by 7:45 PM PDT, or sooner if we have additional information to share.

    4. 2026年5月8日 UTC 03:06resolved

      We are actively working to restore temperatures to normal levels in the affected Availability Zone (use1-az4) in the US-EAST-1 Region, though progress is slower than originally anticipated. Since our last update we have made incremental progress to restore cooling systems within the affected AZ, which will not be visible to external customers but are required for the restoration of affected services. In the impacted Availability Zone, EC2 Instances, EBS Volumes, and other AWS Services are also experiencing elevated error rates and latencies for some workflows. As part of our recovery effort, we have shifted traffic away from the impacted Availability Zone for most services. We recommend customers utilize one of the other Availability Zones in the US-EAST-1 Region, as existing instances in other AZs remain unaffected by this issue. If immediate recovery is required, we recommend customers restore from EBS Snapshots and/or replace affected resources by launching new replacement resources in one of the unaffected zones. We will provide an update by 10:00 PM PDT, or sooner if we have additional information to share.

    5. 2026年5月8日 UTC 05:11resolved

      We are observing early signs of recovery. We continue to work towards restoring temperatures to normal levels and bring impacted racks back online in the affected Availability Zone (use1-az4) in the US-EAST-1 Region. We have been able to get additional cooling system capacity online, which has allowed us to recover some affected racks and are actively working to recover additional racks in a controlled and safe manner. In the impacted Availability Zone, EC2 Instances, EBS Volumes, and other AWS Services may continue to experience elevated error rates and latencies for some workflows until full recovery is achieved. We will provide an update by 11:30 PM PDT, or sooner if we have additional information to share.

    6. 2026年5月8日 UTC 06:38resolved

      We continue to make progress in resolving the impaired EC2 instances in the affected Availability Zone (use1-az4) in the US-EAST-1 Region, and are working towards full recovery. We are actively working to bring additional cooling system capacity online, which will enable us to recover the remaining affected racks in a controlled and safe manner. In the impacted Availability Zone, EC2 Instances, EBS Volumes, and other AWS Services may continue to experience elevated error rates and latencies for some workflows. Customers will continue to see some of their affected EC2 instances and EBS volumes as impaired until we achieve full recovery. We will provide an update by May 8, 1:30 AM PDT, or sooner if we have additional information to share.

    7. 2026年5月8日 UTC 08:32resolved

      Mitigation efforts remain underway to resolve the impaired EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region. These EC2 instances and EBS volumes were impacted due to a loss of power during the thermal event. The work to bring additional cooling system capacity online, which will enable us to recover the remaining affected infrastructure in a controlled and safe manner, is taking longer than we had initially anticipated. Some services, such as IoT Core, ELB, NAT Gateway, and Redshift, have seen significant improvements in the recovery of their workflows. However, some customers will continue to see their affected EC2 instances and EBS volumes as impaired until we achieve full recovery. While we do not currently have an ETA for full recovery, we are prioritizing this issue and will provide another update by 3:30 AM PDT or sooner if additional information becomes available.

    8. 2026年5月8日 UTC 10:54resolved

      We continue to make progress towards resolving the impaired EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region. At this time, we wanted to provide some more details on the issue. Beginning on May 7 at 4:20 PM PDT, we began experiencing an increase in instance impairments within the affected zone due to the loss of power during a thermal event. Engineers were automatically engaged within minutes and immediately began investigating multiple mitigations. By 9:12 PM PDT, we restored power to a subset of the affected infrastructure and observed some signs of recovery, which have remained stable. We continue working to bring additional cooling system capacity online, which will enable us to recover the remaining affected hardware in the impacted zone in a controlled and safe manner. Some AWS services, such as IoT Core, ELB, NAT Gateway, and Redshift, continue to see significant improvements in the recovery of their workflows. However, some customers will continue to see their affected EC2 instances and EBS volumes as impaired until we achieve full recovery. If immediate recovery is required, we recommend customers restore from EBS snapshots and/or replace affected resources by launching new replacement resources in one of the unaffected zones. Based on our current mitigation efforts, we expect full recovery to take several hours. We are prioritizing this issue and will provide another update by 6:30 AM PDT or sooner if additional information becomes available.

    9. 2026年5月8日 UTC 13:51resolved

      We continue working to resolve the impaired EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region caused by a thermal event. During such an event, servers automatically shut down when the temperatures exceeded the operating thresholds in order to protect the hardware. We are actively working to bring additional cooling system capacity online, which will enable us to recover the remaining affected hardware in the impacted zone. Some customers will continue to see their affected EC2 instances and EBS volumes as impaired until we achieve full recovery. If immediate recovery is required, we recommend customers restore from EBS snapshots and/or replace affected resources by launching new replacement resources in one of the unaffected zones. In parallel, we are investigating increased error rates and query failures for Redshift clusters in the US-EAST-1 Region. During this time, affected customers may see errors for resume and restart workflows, as well as failover operations and availability issues. Our engineers are actively working to resolve this issue. Full recovery is still expected to take several hours. We are prioritizing this issue and will provide another update by 9:00 AM PDT or sooner if additional information becomes available.

    10. 2026年5月8日 UTC 15:58resolved

      We continue our efforts to work towards the recovery of the impaired EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region. We are making progress towards the restoration of the cooling system capacity that is required to recover the affected hardware in the impacted zone. Some customers will continue to see their affected EC2 instances and EBS volumes as impaired until the affected racks are recovered. We continue to recommend that customers who require immediate recovery restore from EBS snapshots and/or replace affected resources by launching new replacement resources in one of the unaffected zones. As part of our parallel investigation, we have identified the root cause of the increased error rates and query failures for Redshift clusters in the US-EAST-1 Region. This has been confirmed to be related to impact from an upstream dependency. Affected customers may continue to see errors for resume and restart workflows, failover operations, and impact to general availability. We are actively working to resolve the issue. Our timeline for full recovery is still expected to take several hours and will be incremental as we bring racks online in phases. We will provide an additional update by 12:30 PM or sooner if we have new information to provide.

    11. 2026年5月8日 UTC 16:30resolved

      We have observed complete recovery of increased error rates and query failures for Redshift clusters in the US-EAST-1 Region. We were able to resolve the impact independently of the ongoing efforts to recover the affected hardware in the use1-az4 Availability Zone. The issue affecting Redshift has been resolved and the service is operating normally. We will provide an additional update regarding the efforts towards hardware restoration by 12:30 PM or sooner.

    12. 2026年5月8日 UTC 18:12resolved

      We are experiencing an increase in timeouts to Amazon Managed Streaming for Apache Kafka partitions on a subset of clusters as a result of the ongoing issue in a single Availability Zone (use1-az4) in the US-EAST-1 Region. We are working in parallel to determine a path towards mitigation for affected clusters. We will provide an additional update by 12:30 PM or sooner.

    13. 2026年5月8日 UTC 19:29resolved

      We continue to work towards the recovery of the impaired EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region though efforts are slower than we had previously anticipated. We are taking measured steps to ensure that cooling capacity is brought online in a safe and controlled manner. As a result, EBS Volumes and EC2 instances affected by the issue will continue to experience impairments. We continue to recommend that customers who require immediate recovery restore from EBS snapshots and/or replace affected resourced by launching new replacement resources. Full recovery is still expected to take several hours. We will provide an additional update by 4:00 PM or sooner if we have new information to provide.

    14. 2026年5月8日 UTC 23:00resolved

      We have begun to see improvements in the overall number of affected EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region. The steps taken to supply additional cooling capacity have been showing steady signs of progress. Some EBS Volumes and EC2 instances affected by the issue will continue to experience impairments while we continue to drive these efforts. We continue to recommend that customers who require immediate recovery restore from EBS snapshots and/or replace affected resources by launching new replacement resources. In parallel, we have seen some improvements in Amazon Managed Streaming for Apache Kafka as a result of the parallel mitigation efforts being performed. We are still experiencing timeouts to partitions but are seeing continued progress. We do anticipate that recovery will still take several hours. We will provide an additional update by 7:30 PM or sooner if we have new information to provide.

    15. 2026年5月9日 UTC 03:04resolved

      Starting May 7 4:20 PM PDT, we experienced increased impaired EC2 instances and degraded EBS volumes in a single facility (data center) within a single Availability Zone (use1-az4) in the US-EAST-1 Region. The issue was caused by a thermal event resulting in a loss of power. As part of our recovery effort, we shifted traffic away from the impacted Availability Zone for most services at May 7 5:06 PM. AWS services, like Elastic Load Balancing, Elastic Kubernetes Service, ElastiCache, Redshift, OpenSearch, Managed Streaming for Apache Kafka among others, that depend on the affected EC2 instances and EBS volumes in this Availability Zone, also experienced elevated error rates and latencies for some workflows and/or configurations. Our main effort during the event mitigation strategy was to bring back our cooling systems capacity. By May 8 1:50 PM, we were able to stabilize cooling system capacity to pre-event levels, which helped us to restore the majority of the impaired EC2 instances and EBS volumes. A small number of instances and EBS volumes remain impaired and we continue to work to recover all affected remaining resources. We will communicate with customers who are still impacted via the Your Account view of the AWS Health Dashboard. Customers that require further assistance with this event may contact AWS Support through the AWS Management Console or the AWS Support Center.

    [RESOLVED] Increased Connectivity Issues

    开始时间 2026年4月27日 UTC 11:27 · 39m

    Issues轻微事件
    1. 2026年4月27日 UTC 11:27resolved

      We are investigating instance connectivity issues in a single Availability Zone (euw3-az2) in the EU-WEST-3 Region.

    2. 2026年4月27日 UTC 12:05resolved

      Between 3:58 AM and 4:40 AM PDT, we experienced increased error rates and increased launch failures for EC2 instances in a single Availability Zone (euw3-az2) in the EU-WEST-3 Region. During this time, customers attempting to launch new EC2 instances in the affected Availability Zone would have experienced launch failures. Additionally, a subset of existing EC2 instances and EBS volumes in this Availability Zone were impacted and became unreachable. We have identified the root cause to be a loss of power to infrastructure within the affected Availability Zone. Engineers were engaged at 4:02 AM and immediately began working to restore power and assess the scope of impact. By 4:20 AM, power was successfully restored to the affected infrastructure. We then focused our efforts on recovering impacted EC2 instances and EBS volumes. By 4:40 AM, all impacted EC2 instances and EBS volumes had been fully recovered and were operating normally. No additional action is required for EC2 instances and EBS volumes that were impacted during the power loss event, as these have been fully recovered. While EC2 and EBS have recovered, some AWS services may take additional time to fully recover as they process backlogs and complete their own recovery procedures. The issue has been resolved and the service is operating normally.

    [RESOLVED] Increased Error Rates

    开始时间 2026年3月7日 UTC 19:53 · 1h 11m

    Issues轻微事件
    1. 2026年3月7日 UTC 19:53resolved

      We are investigating increased error rates in the EU-CENTRAL-2 Region.

    2. 2026年3月7日 UTC 20:17resolved

      We can confirm substantial error rates for PUT and GET requests to Amazon S3 in the EU-CENTRAL-2 Region. Engineers engaged immediately based on automated alarming. We have triangulated the issue to a subsystem responsible for assembling objects from bytes in storage. We have begun implementing mitigations, and are observing some improvement in error rates. We continue to work to identify the root cause, and are working on multiple parallel paths to fully mitigate the issue. Other AWS Services (such as EC2 launches) that rely on S3 are also affected by this issue. Existing EC2 instances are unaffected by this issue. We will provide another update by 12:45 PM PST, or sooner if we have additional information to share.

    3. 2026年3月7日 UTC 20:28resolved

      We are seeing early signs of recovery and continue to monitor and work toward full recovery.

    4. 2026年3月7日 UTC 21:04resolved

      Between 11:27 AM and 12:20 PM PST we experienced substantial error rates for S3 PUT/GET requests in EU-CENTRAL-2 Region. Engineers were engaged immediately based on automated alarming. We identified the root cause as an issue with a subsystem responsible for assembling objects bytes in storage. At 12:04 PM PST, we implemented mitigations and began observing early signs of recovery for S3. Error rates continued to improve, and other AWS Services continued to recover until 12:50 PM PST when we observed full recovery. We continue to work toward backfilling Cloudwatch logs, and expect that to continue over the next couple hours. We recommend customers retry any failed requests. The issue has been resolved and all services are operating normally.

    Region Availability

    开始时间 2026年3月2日 UTC 05:56 · 进行中

    Issues轻微事件
    1. 2026年3月2日 UTC 05:56resolved

      We are investigating increased API error rates in a single Availability Zone (mes1-az2) in the ME-SOUTH-1 Region.

    2. 2026年3月2日 UTC 07:09resolved

      We are investigating connectivity and power issues affecting APIs and instances in a single Availability Zone (mes1-az2) in the ME-SOUTH-1 Region due to a localized power issue. Existing instances in this zone will also be affected. Other AWS Services may also be experiencing increased errors and latencies for their workflows, and we are working to route requests away from this affected Availability Zone. We recommend customers make use of other Availability Zones at this time. During this time, we are also experiencing delays in propagating DNS changes for Route53 to pops (Points of Presence) in ME-SOUTH-1.  Targeting new launches using RunInstances in the remaining AZs should succeed. Existing instances in the other AZs are not affected.

    3. 2026年3月2日 UTC 09:03resolved

      We continue to work on a localized power issue affecting a single Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. In the impacted Availability Zone, EC2 Instances, DB Instances, EBS Volumes, and other AWS Services are also experiencing elevated error rates and latencies for some workflows. As part of our recovery effort, we have shifted traffic away from the impacted Availability Zone for most services. We recommend customers utilize one of the other Availability Zones in the ME-SOUTH-1 Region, as existing instances in other AZs remain unaffected by this issue. We are actively working to restore power and connectivity, at which time we will begin recovering affected resources. Currently, we expect recovery to take many hours. We will provide an update by 2:30 AM PST, or sooner if we have additional information to share.

    4. 2026年3月2日 UTC 10:41resolved

      We continue to work toward restoring power in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. At this time, some AWS services have shifted traffic away from the affected Availability Zone and are seeing recovery for their affected operations and workflows. EC2 Instances, EBS Volumes, and other resources impacted in the affected Availability Zone will require a longer recovery timeline. Power has not yet been restored to the affected Availability Zone. If immediate recovery is required, we recommend customers restore from EBS Snapshots and/or launch replacement resources in one of the unaffected Availability Zones or an alternate Region. In parallel, we are actively working on reducing the error rates and latencies that some customers are experiencing with EC2 APIs. For now, we recommend continuing to retry any failed API requests. We will provide an update by 6:00 AM PST on March 2, or sooner if we have additional information to share.

    5. 2026年3月2日 UTC 14:23resolved

      We continue to work toward restoring power in the impacted Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. Meanwhile, EC2 instance and networking APIs have been restored for the other Availability Zones. Additionally, we have made improvements to the availability of RDS multi-AZ databases while operating with the impaired Availability Zone. These improvements will help customers create database exports to preserve data, and we recommend customers with databases in the affected Availability Zone consider creating exports as a precautionary measure. EC2 Instances, EBS Volumes, and other resources impacted in the affected Availability Zone will require a longer recovery timeline, as power has not yet been restored. We are expecting recovery to take at least a day, as it requires repair of facilities, cooling and power systems, coordination with local authorities, and careful assessment to ensure the safety of our operators. If immediate recovery is required, we recommend customers restore from EBS Snapshots and/or launch replacement resources in one of the unaffected Availability Zones or an alternate AWS Region. We will provide an update by 11:00 AM PST on March 2, or sooner if we have additional information to share.

    6. 2026年3月2日 UTC 18:52resolved

      We continue to work towards restoring power in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. We currently expect our recovery efforts to take at least a day. Our current guidance regarding immediate recovery remains unchanged from our previous update. Customers are able to disassociate Elastic IP addresses from resources in the affected Availability Zone and associate those with resources in the unaffected Availability Zones. This can be done by specifying --allow-reassociation when attempting to associate the Elastic IP to the new resource. We will provide you with further updates by 2:00 PM PST or sooner if new information becomes available.

    7. 2026年3月2日 UTC 22:29resolved

      We continue to work towards restoring power in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. We have no updated guidance on expected recovery times, and still expect this to take at least a day to fully restore power and connectivity. We continue to advise customers to launch replacement resources in one of the unaffected Availability Zones or an alternate AWS Region. At this time we recommend that customers that are capable of backing up data outside of the region consider doing so. You can view the current status of affected AWS services below. We will provide you with another update by 7:00 PM PST, or sooner if we have additional information to share.

    8. 2026年3月3日 UTC 00:22resolved

      We are providing an update on the ongoing service disruptions affecting the AWS Middle East (UAE) Region (ME-CENTRAL-1) and the AWS Middle East (Bahrain) Region (ME-SOUTH-1). Due to the ongoing conflict in the Middle East, both affected regions have experienced physical impacts to infrastructure as a result of drone strikes. In the UAE, two of our facilities were directly struck, while in Bahrain, a drone strike in close proximity to one of our facilities caused physical impacts to our infrastructure. These strikes have caused structural damage, disrupted power delivery to our infrastructure, and in some cases required fire suppression activities that resulted in additional water damage. We are working closely with local authorities and prioritizing the safety of our personnel throughout our recovery efforts. In the ME-CENTRAL-1 (UAE) Region, two of our three Availability Zones (mec1-az2 and mec1-az3) remain significantly impaired. The third Availability Zone (mec1-az1) continues to operate normally, though some services have experienced indirect impact due to dependencies on the affected zones. In the ME-SOUTH-1 (Bahrain) Region, one facility has been impacted. Across both regions, customers are experiencing elevated error rates and degraded availability for services including Amazon EC2, Amazon S3, Amazon DynamoDB, AWS Lambda, Amazon Kinesis, Amazon CloudWatch, Amazon RDS, and the AWS Management Console and CLI. We are working to restore full service availability as quickly as possible, though we expect recovery to be prolonged given the nature of the physical damage involved. In parallel with efforts to restore the physical infrastructure at the affected sites, we are pursuing multiple software-based recovery paths that do not depend on the underlying facilities being fully brought back online. For Amazon S3 and Amazon DynamoDB, we are actively working to restore data access and service availability through software mitigations, including deploying updates to enable S3 to operate within the current infrastructure constraints and remediating impaired DynamoDB tables to restore read and write availability for dependent services. Our focus on restoring these foundational services is deliberate, as recovery of Amazon S3 and Amazon DynamoDB will in turn enable a broad range of dependent AWS services to recover. For other affected service APIs, we are deploying targeted software updates to reduce error rates and restore functionality where possible, independent of the physical recovery timeline. We are also working to restore access to the AWS Management Console and CLI through network-level changes that route traffic away from the affected infrastructure. While these software-based mitigations can address many of the service-level impacts, some recovery actions are constrained by the physical state of the affected facilities — meaning that full restoration of certain services will require the underlying infrastructure to be repaired and brought back online. Across all services, our teams are working in parallel on both the physical restoration of the affected facilities and these software-based mitigations, with the goal of restoring as much customer access as possible as quickly as possible, even ahead of full infrastructure recovery. In addition, we are prioritizing the restoration of services and tools that enable customers to back up and migrate their data and applications out of the affected regions. Finally, even as we work to restore these facilities, the ongoing conflict in the region means that the broader operating environment in the Middle East remains unpredictable. We recommend that customers with workloads running in the Middle East consider taking action now to backup data and potentially migrate your workloads to alternate AWS Regions. We recommend customers exercise their disaster recovery plans, recover from remote backups stored in other regions, and update their applications to direct traffic away from the affected regions. For customers requiring guidance on alternate regions, we recommend considering AWS Regions in the United States, Europe, or Asia Pacific, as appropriate for your latency and data residency requirements. We will continue to provide updates as recovery progresses and as the situation evolves. Our next update will be provided by 9:00 PM PST on March 2, 2026, or sooner if new information becomes available.

    9. 2026年3月3日 UTC 06:27resolved

      We continue to work towards restoring power in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. We have no updated guidance on expected recovery times, and still expect this to take at least a day to fully restore power and connectivity. AWS infrastructure is designed to be highly resilient, but given the uncertainty of the current situation, we encourage our customers to replicate Amazon S3 and critical data from the ME-SOUTH-1 Region to another AWS Region. For customers requiring guidance on alternate regions, we recommend considering AWS Regions in the United States, Europe, or Asia Pacific, as appropriate for your latency and data residency requirements. We will provide another update by March 3 at 3:00 AM PST, or sooner if new information becomes available. For more information on Cross-Region Replication, refer [1]. For more information on S3 Batch Replication, see [2]. For a simple script to quickly set up and start S3 Replication, see [3]. If you have questions or concerns, please contact AWS Support [4]. [1] <a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html">https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html</a> [2] <a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-batch-replication-batch.html">https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-batch-replication-batch.html</a> [3] <a href="https://github.com/awslabs/aws-support-tools/blob/master/S3/Setup_Replication/setup_replication.py">https://github.com/awslabs/aws-support-tools/blob/master/S3/Setup_Replication/setup_replication.py</a> [4] <a href="https://aws.amazon.com/support">https://aws.amazon.com/support</a>

    10. 2026年3月3日 UTC 11:10resolved

      We continue to work toward restoring power in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. The overall state of the region remains largely unchanged from our previous update. At this time, we have no updated guidance on expected timelines for fully restoring power and connectivity. We are taking all necessary steps to support the recovery process. While progress is being made, significant work remains before full restoration is complete. Given the ongoing uncertainty, we encourage customers to replicate their Amazon S3 data and other critical data from the ME-SOUTH-1 Region to another AWS Region, using the guidance provided in our previous update. We will continue to provide updates as recovery progresses and as the situation evolves. Our next update will be provided by 6:00 AM PST on March 3, or sooner if new information becomes available.

    11. 2026年3月3日 UTC 14:02resolved

      Recovery efforts in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region are ongoing, with the situation remaining consistent with our last update. We have no change to expected timelines for fully restoring power and connectivity. While progress is being made, significant work remains before full restoration is complete. We continue to recommend customers launch replacement resources in one of the unaffected Availability Zones or an alternate AWS Region. Given the extended nature of this event, we continue to encourage customers to replicate Amazon S3 data and other critical workloads from ME-SOUTH-1 to another AWS Region using the guidance shared previously. We will provide our next update by 12:00 PM PST on March 3, or sooner if conditions change.

    12. 2026年3月3日 UTC 16:40resolved

      We are providing an update on the ongoing service disruptions affecting the AWS Middle East (Bahrain) Region (ME-SOUTH-1). We continue to make progress on recovery efforts across multiple workstreams. With the immediate phase of this event now better understood, we are moving to a more targeted communication model. Going forward, updates will be delivered directly to affected customers through the AWS Personal Health Dashboard. Customers who require assistance with this event are encouraged to contact AWS Support through the AWS Management Console or the AWS Support Center. We continue to strongly recommend that customers with workloads running in the Middle East take action now to migrate those workloads to alternate AWS Regions. Customers should enact their disaster recovery plans, recover from remote backups stored in other Regions, and update their applications to direct traffic away from the affected Regions. For customers requiring guidance on alternate regions, we recommend considering AWS Regions in the United States, Europe, or Asia Pacific, as appropriate for your latency and data residency requirements.

    13. 2026年4月30日 UTC 07:07investigating

      We are providing an update on the ongoing service disruption. The Middle East (Bahrain) Region (ME-SOUTH-1) has suffered damage due to the conflict in the Middle East and is currently unavailable. Customers should recover their resources in other Regions from remote backups. Relevant billing operations are currently suspended while we restore normal operations in this AWS Region. This process is expected to take several months.

    14. 2026年9月15日 UTC 10:22investigating

      We are providing an update on the disruption affecting the Middle East (Bahrain) (me-south-1) Region. The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand. After a thorough assessment, we have determined that we are unable to restore access to the resources and data hosted exclusively in this Region. When the first Availability Zone was damaged in March, we began recommending that customers migrate their workloads to other Regions, and most did so before the Region became unavailable following the disruption of a second Availability Zone in April. Since then, we have supported the remaining customers in re-establishing their operations in alternate Regions, using backups where available or implementing alternative solutions to mitigate the impact of inaccessible data. In parallel, we assessed all affected infrastructure and exhausted every option for restoring data and resources that had not been migrated before the Region became unavailable. We remain committed to supporting our customers in Bahrain in the long term and will share a further update in early 2027. We have notified the relevant authorities and continue to work with them toward that goal.