Histórico de interrupções do AWS

1. 4 Here 2026 da 16:14 UTCresolved

   Estamos investigando perdas elevadas de pacotes na Região UE-SOUTH-2.

2. 4 Here 2026 da 16:36 UTCresolved

   Estamos passando por uma perda de pacote elevada com uma única Zona de Disponibilidade (eus2-az1) na Região UE-SOUTH-2. Este problema também está resultando em altas latências da API e taxas de erro para outros fluxos de trabalho e serviços AWS. Os engenheiros foram automaticamente envolvidos e estão trabalhando para identificar a causa raiz e para mitigar o problema. Nós lhe forneceremos outra atualização até 10:15 AM PDT ou mais cedo quando novas informações estiverem disponíveis.

3. 4 Here 2026 da 17:06 UTCresolved

   Nossos esforços para mitigar a perda elevada de pacotes com uma única Zona de Disponibilidade (eus2-az1) na Região UE-SOUTH-2 ainda estão em andamento. Estamos a ver alguns sinais de melhoria como resultado de múltiplos esforços paralelos. Continuamos a trabalhar para confirmar a causa raiz e mitigar totalmente a questão. Embora atualmente não tenhamos uma estimativa de quanto tempo nossas ações levarão, vamos mantê-lo informado sobre nosso progresso e fornecer-lhe outra atualização até 11:00 PDT ou mais cedo quando novas informações estiverem disponíveis.

4. 4 Here 2026 da 17:56 UTCresolved

   Identificamos a causa raiz e atualmente estamos focando nossos esforços de mitigação para impulsionar a recuperação total. Embora não tenhamos uma estimativa exata por quanto tempo nossos esforços atuais levarão, esperamos ver melhorias incrementais à medida que nossos esforços prosseguirem. Nós lhe forneceremos outra atualização até 11:45 PDT, ou mais cedo se novas informações estiverem disponíveis.

5. 4 Here 2026 da 18:45 UTCresolved

   Estamos a ver sinais iniciais de recuperação. Nós lhe forneceremos outra atualização até 12:00 PM PDT.

6. 4 Here 2026 da 18:56 UTCresolved

   Entre 8:48 AM e 11:28 PDT, tivemos elevada perda de pacotes em uma única Zona de Disponibilidade (eus2-az1) na Região UE-SOUTH-2. Este problema resultou em latências elevadas da API e taxas de erro para múltiplos fluxos de trabalho e serviços AWS. Fomos automaticamente alertados para o problema às 8:54 da manhã, e imediatamente começamos a trabalhar para identificar a causa raiz, ao tomar múltiplos caminhos paralelos para mitigar o problema. Por volta das 10:00, nossos esforços de mitigação levaram a algumas melhorias. Por volta das 10:38 da manhã, identificamos a causa raiz como relacionada a uma mudança de configuração de rede que foi capaz de reverter a mudança que levou à mitigação completa por 11:28 da manhã. O problema foi resolvido e o serviço está funcionando normalmente.

Traduzido automaticamente da atualização oficial do incidente.

1. 21 Gwengolo 2026 da 23:26 UTCresolved

   Estamos investigando o aumento das taxas de erro da API na região US-EAST-1.

2. 21 Gwengolo 2026 da 23:44 UTCresolved

   Podemos confirmar o aumento das taxas de erro afetando novos lançamentos de instância, incluindo taxas de erro API elevadas para RunInstances, CreateFleet e fluxos de trabalho de lançamento relacionados ao EC2 na Região US-EAST-1. Os clientes que tentam lançar novas instâncias EC2 podem experimentar falhas de lançamento ou latência de resposta API elevada. Nossos engenheiros estão ativamente envolvidos e trabalhando para recuperar o problema. Estamos a ver sinais iniciais de recuperação. As instâncias existentes permanecem inalteradas. Recomendamos a repetição das chamadas de RunInstances e CreateFleet API. Vamos fornecer uma atualização até 17:30 PDT ou mais cedo.

3. 22 Gwengolo 2026 da 00:24 UTCresolved

   Entre as 15h49 e as 17h06 PDT, tivemos aumento das taxas de erro afetando novos lançamentos de instância na Região US-EAST-1. Durante este tempo, os clientes podem ter experimentado taxas de erro elevadas ao tentar lançar novas instâncias EC2 através de RunInstances, CreateFleet e fluxos de trabalho de lançamento relacionados EC2. Os serviços AWS que lançam as instâncias EC2 em nome de clientes, incluindo a Amazon ECS, a AWS Fargate, a Amazon EMR, entre outros, também foram afetados durante este período. Identificamos a causa básica como uma recente implantação de um subsistema dentro do serviço EC2 responsável pelo processamento de solicitações de lançamento de instância. Iniciamos um retrocesso da implantação problemática e começamos a observar sinais iniciais de recuperação às 16h44. As instâncias existentes permanecem inalteradas. O problema foi resolvido e o serviço está funcionando normalmente.

Traduzido automaticamente da atualização oficial do incidente.

1. 3 Gwengolo 2026 da 21:49 UTCresolved

   A partir de 2:12 PM PDT, começamos a ter taxas de erro de API aumentadas para STS e Sign In quando usamos SAML na região US-WEST-2. Nossa equipe de engenharia foi automaticamente engajada às 2:19 para começar a investigar a causa raiz. Não há trabalho disponível neste momento. Vamos fornecer outra atualização até 3:30 PDT.

2. 3 Gwengolo 2026 da 22:26 UTCresolved

   Estamos vendo sinais precoces de recuperação e continuar a monitorar para recuperação total. Forneceremos outra atualização às 16:15, ou mais cedo se tivermos informações adicionais para compartilhar.

3. 3 Gwengolo 2026 da 23:20 UTCresolved

   Continuamos a ver a recuperação mantendo-se estável para o STS AssumeRoleWithSAML e AssumeRoleWithWebIdentity APIs na região US-WEST-2. As taxas de erro voltaram aos níveis pré-evento, e continuamos monitorando ativamente para confirmar a recuperação completa. Nós forneceremos outra atualização até às 17:15 ou antes.

4. 4 Gwengolo 2026 da 00:07 UTCresolved

   Entre 2:12 PM e 3:18 PM PDT, nós experimentamos aumento das taxas de erro de API afetando o STS AssumeRoleCom o SAML e as APIs AssumeRoleCom o WebIdentity na região US-WEST-2. A causa raiz foi determinada por um problema com um subsistema STS responsável pela comunicação com provedores de identidade externa. Outros serviços da AWS que dependem desses protocolos de federação de identidade também foram afetados. Às 15h18, observamos sinais de recuperação e continuamos monitorando para garantir estabilidade e recuperação total. O problema está resolvido e o serviço está funcionando normalmente neste momento.

Traduzido automaticamente da atualização oficial do incidente.

1. 21 Eost 2026 da 02:02 UTCresolved

   AP-NORTESTEAST-1. Estamos tendo um aumento das taxas de erro afetando as métricas em tempo real na Região AP-NORTEAST-1. Os clientes podem experimentar dados métricos perdidos ou atrasados em tempo real.

2. 21 Eost 2026 da 02:40 UTCresolved

   Amazónia Conectar-se-á com a sua atenção. 10:13 AM 10:34 AM Entre 4:58 PM e 6:34 PDT, nós experimentamos atrasos crescentes afetando as métricas em tempo real para Amazon Connect na região AP-NORTEAST-1, resultando em dados ausentes ou stale. Durante esse tempo, os clientes podem ter experimentado dados em falta dentro dos relatórios de análise, e podem ter observado problemas se acessar métricas em tempo real dentro dos Fluxos de contato, como verificar a equipe de agentes. Identificamos a causa raiz como um problema com o subsistema responsável pela entrega de eventos métricos. Começamos a aplicar as mitigação às 18h13 e mitigamos a questão às 18h34. O problema foi resolvido e o serviço está funcionando normalmente.

Traduzido automaticamente da atualização oficial do incidente.

1. 19 Eost 2026 da 15:15 UTCresolved

   Estamos a investigar uma questão que está a afectar o lançamento de novas instâncias e recursos EC2 numa nova zona de disponibilidade (euw2-az4) na região UE-WEST-2. Durante este período, os clientes afetados podem experimentar problemas ao criar ou modificar recursos na Região. Outros serviços AWS também podem ser impactados. Para recuperação imediata, recomendamos que os clientes usem zonas de disponibilidade alternativas (euw2-az1, euw2-az2 e euw2-az3), quando aplicável. As instâncias e recursos em execução existentes não são afetados. Nós forneceremos outra atualização até 10:00 PDT, ou mais cedo se tivermos informações adicionais para compartilhar.

2. 19 Eost 2026 da 17:03 UTCresolved

   Em 18 de agosto lançamos uma nova Zona de Disponibilidade (euw2-az4) na Região UE-WEST-2. Após o lançamento, começamos a experimentar erros lançando instâncias EC2 na nova Zona de Disponibilidade quando uma sub-rede padrão não está presente. Podemos confirmar que as instâncias e recursos existentes não são afetados. Fluxos de trabalho que obtêm automaticamente uma lista de Zonas de Disponibilidade na Região através da API DescribeAvailabilityZones e depois tentam lançar novas instâncias ou criar recursos na nova Zona de Disponibilidade podem encontrar erros. Para falhas de lançamento da instância EC2, estamos tomando medidas atenuantes para criar automaticamente subredes padrão, onde ainda não está presente, quando um lançamento da instância EC2 está visando a nova Zona de Disponibilidade. Para clientes e fluxos de trabalho que requerem remediação imediata <a href="https://docs.aws.amazon.com/vpc/latest/userguide/work-with-default-vpc.html#create-default-subnet">you may create a default subnet</a> in the new Availability Zone. Isto permitirá que os lançamentos da instância EC2 sejam concluídos com sucesso. Para outros recursos, como as funções da Lambda, onde a nova Zona de Disponibilidade não é suportada atualmente, recomendamos aos clientes atualizar seus fluxos de trabalho para excluir a Zona de Disponibilidade recém-lançada e continuar a criação de recursos usando as outras Zonas de Disponibilidade na Região. Embora não tenhamos uma estimativa exata de quanto tempo nossos esforços de mitigação levarão, vamos mantê-lo atualizado sobre o nosso progresso e fornecer-lhe outra atualização até 1:00 PDT ou mais cedo quando novas informações estiverem disponíveis.

3. 19 Eost 2026 da 18:47 UTCresolved

   Entre 18 de agosto às 17:00 e 19 de agosto às 11:00 PDT, tivemos elevados erros lançando instâncias EC2 em uma recém-lançada Zona de Disponibilidade (euw2-az4) na Região UE-WEST-2. Após o lançamento do novo Availability Zone, começamos a ter erros ao usar um VPC padrão. Descobrimos a causa básica do número no dia 19 de agosto às 9:00 e começamos a implantar uma mudança para resolver o problema às 9:30. Enquanto a mudança estava em andamento, começamos a ver melhorias incrementais em novos lançamentos de instância, com recuperação completa às 11:00. As instâncias e recursos em execução existentes não foram afetados. Alguns serviços regionais, como funções Lambda ou bases de dados Aurora, não estavam disponíveis no lançamento da nova Zona de Disponibilidade e a disponibilidade de serviços será adicionada ao longo do tempo. Os clientes que tentam criar recursos antes que os serviços fiquem disponíveis verão uma mensagem informando que não é suportada na Zona de Disponibilidade. O problema foi resolvido e o serviço está funcionando normalmente.

Traduzido automaticamente da atualização oficial do incidente.

1. 15 Eost 2026 da 03:42 UTCresolved

   Estamos investigando o aumento da perda de pacotes, impactando a conectividade AWS Direct Connect para alguns clientes da região EU-CENTRAL-1.

2. 15 Eost 2026 da 04:42 UTCresolved

   Podemos confirmar a perda de pacotes impactando conexões Direct Connect na região EU-CENTRAL-1. Os engenheiros foram automaticamente engajados e imediatamente começaram a trabalhar para identificar a causa raiz, e identificar múltiplos caminhos paralelos para mitigar o problema. Neste momento, vemos sinais iniciais de recuperação. Forneceremos outra atualização em 60 minutos, ou mais cedo se tivermos informações adicionais para compartilhar.

3. 15 Eost 2026 da 05:55 UTCresolved

   A partir das 19:33 PM PDT, começamos a experimentar um aumento da perda de pacotes impactando a conectividade AWS Direct Connect para alguns clientes na região EU-CENTRAL-1. Embora tenhamos feito progressos, as ligações para o seguinte local Direct Connect ainda estão prejudicadas: Equinix FR5, Frankfurt, DEU. Os clientes que têm redundância multi-site configurada com seus caminhos Connect direto não devem estar observando impacto neste momento. Os clientes que só têm ligações na Equinix FR5, Frankfurt, DEU local continuarão a experimentar problemas de conectividade. Estamos trabalhando ativamente para mitigar o impacto e trabalhar para a recuperação total, mas esperar que a recuperação total está a várias horas de distância. Forneceremos uma atualização em 90 minutos, ou mais cedo se tivermos informações adicionais para compartilhar.

4. 15 Eost 2026 da 07:24 UTCresolved

   Estamos trabalhando ativamente para restaurar a conectividade através do Direct Connect local: Equinix FR5, Frankfurt, DEU. Os clientes que só têm ligações na Equinix FR5, Frankfurt, DEU local continuarão a experimentar problemas de conectividade. Para uma solução alternativa os clientes afetados que têm a opção disponível para failover para VPN são recomendados para fazê-lo para alcançar a recuperação. Para os clientes que usam o Gateway Direct Connect e o Transit Gateway, recomendamos a criação de uma VPN AWS Site-to-Site e anexá-la ao seu Transit Gateway, consulte as etapas <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">aqui</a>. Para outros clientes, recomendamos estabelecer uma VPN AWS Site-to-Site como um caminho de backup temporário, consulte as etapas <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">aqui</a>. A partir deste momento, esperamos que a recuperação esteja a várias horas de distância. Forneceremos outra atualização em 90 minutos, ou mais cedo se tivermos informações adicionais para compartilhar.

5. 15 Eost 2026 da 09:08 UTCresolved

   Continuamos a trabalhar na recuperação da conectividade para conexões AWS Direct Connect na Equinix FR5, Frankfurt, DEU. A causa principal está relacionada com uma questão de infraestrutura de instalação no local que está impactando a infraestrutura de rede. Clientes com conexões exclusivamente neste local continuarão a experimentar perda de pacotes ou degradação da conectividade. Clientes com configurações multi-site ou redundantes em outros locais não são afetados. Para uma solução alternativa, os clientes impactados que têm a opção disponível para failover para VPN são recomendados para fazê-lo. Para os clientes que usam o Gateway Direct Connect e o Transit Gateway, recomendamos a criação de uma VPN AWS Site-to-Site e anexando-a ao seu Transit Gateway, consulte passos <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">aqui</a>. Para outros clientes, recomendamos estabelecer uma VPN AWS Site-to-Site como um caminho de backup temporário, consulte passos <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetupVPNConnections.html">aqui</a>. A partir deste momento, esperamos que a recuperação esteja a várias horas de distância. Forneceremos outra atualização dentro de 2 horas ou assim que tivermos mais informações para compartilhar.

6. 15 Eost 2026 da 11:10 UTCresolved

   A conectividade AWS Direct Connect permanece prejudicada para os clientes com conexões no local Equinix FR5 em Frankfurt, DEU. Clientes com configurações multi-site ou redundantes em outros locais continuam a não ser afetados. Os engenheiros estão trabalhando ativamente para restaurar a conectividade, com esforços em andamento em vários fluxos de trabalho para resolver o problema da instalação subjacente e trazer o equipamento de rede impactado de volta ao serviço. Continuamos a esperar que a recuperação esteja a várias horas de distância. Para uma solução alternativa, os clientes impactados que têm a opção de failover para VPN são recomendados para fazê-lo. Para os clientes que usam o Gateway Direct Connect e o Transit Gateway, recomendamos a criação de uma VPN AWS Site-to-Site e anexando-a ao seu Transit Gateway, consulte passos <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">aqui</a>. Para outros clientes, recomendamos estabelecer uma VPN AWS Site-to-Site como um caminho de backup temporário, consulte passos <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetupVPNConnections.html">aqui</a>. Forneceremos outra atualização dentro de 2 horas ou assim que tivermos mais informações para compartilhar.

7. 15 Eost 2026 da 13:17 UTCresolved

   Os engenheiros continuam trabalhando para restaurar a conectividade na Equinix FR5 em Frankfurt, DEU. O nosso parceiro de co-localização está a trabalhar para resolver o problema da infra-estrutura de instalação subjacente e, embora as melhorias ainda não sejam visíveis pelo cliente, estamos a fazer progressos positivos no sentido da resolução. Para os clientes que necessitam de recuperação imediata, recomendamos falhar em VPN, como descrito em nossas atualizações anteriores. Nós forneceremos outra atualização até 9:30 PDT, ou mais cedo se tivermos informações adicionais para compartilhar.

8. 15 Eost 2026 da 16:27 UTCresolved

   O nosso parceiro de co-localização continua a trabalhar para resolver a questão da infra-estrutura de instalação subjacente no local Equinix FR5 em Frankfurt, DEU. O acesso à área afetada está atualmente restrito devido a preocupações de segurança, que está impactando nossa capacidade de avaliar a condição física do equipamento de rede e fornecer uma linha do tempo de recuperação mais precisa. Com base nas informações atuais, a recuperação completa não é esperada a curto prazo e pode se estender para além de hoje. As conexões AWS Direct Connect neste local permanecem prejudicadas. Os clientes com conexões redundantes através de outros locais permanecem não afetados. Para os clientes que usam o Gateway Direct Connect e o Transit Gateway, recomendamos a criação de uma VPN AWS Site-to-Site e anexando-a ao seu Transit Gateway, consulte passos <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">aqui</a>. Para outros clientes, recomendamos estabelecer uma VPN AWS Site-to-Site como um caminho de backup temporário, consulte passos <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetupVPNConnections.html">aqui</a>. Nós forneceremos outra atualização até 3:30 PDT PM, ou mais cedo se tivermos informações adicionais para compartilhar.

9. 15 Eost 2026 da 22:26 UTCresolved

   Nosso parceiro de co-localização continua trabalhando para restaurar o acesso seguro à área afetada no local Equinix FR5 em Frankfurt, DEU. Assim que o acesso seguro for assegurado, nossos engenheiros poderão avaliar os dispositivos de rede afetados. Continuamos a acompanhar de perto o progresso e compartilharemos uma atualização até 9:30 PM PDT, ou mais cedo quando novas informações estiverem disponíveis.

10. 16 Eost 2026 da 04:37 UTCresolved

    Estamos ativamente envolvidos com nosso parceiro de co-localização para restaurar a conectividade na Equinix FR5 local em Frankfurt, DEU. Desde a nossa última atualização, fizemos progressos incrementais para restaurar o acesso seguro à área afetada no local Equinix FR5 em Frankfurt, DEU. Paralelamente, priorizamos a ordem em que os racks críticos e de alta prioridade serão restaurados, como parte dos esforços de mitigação. Com base em nossa avaliação atual, a recuperação completa não é esperada a curto prazo e pode se estender para além de hoje. As conexões AWS Direct Connect neste local permanecem prejudicadas. Os clientes com conexões exclusivamente neste local continuarão a experimentar perda de pacotes. Clientes com configurações multi-site ou redundantes em outros locais do Direct Connect não são afetados. Para uma solução alternativa, os clientes impactados que têm a opção disponível para failover para VPN são recomendados para fazê-lo. Para os clientes que usam o Gateway Direct Connect e o Transit Gateway, recomendamos a criação de uma VPN AWS Site-to-Site e anexando-a ao seu Transit Gateway, consulte passos <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">aqui</a>. Para outros clientes, recomendamos estabelecer uma VPN AWS Site-to-Site como um caminho de backup temporário, consulte passos <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetupVPNConnections.html">aqui</a>. Continuamos a acompanhar de perto o progresso e compartilharemos uma atualização até 16 de agosto 3:30 PDT, ou mais cedo quando novas informações estiverem disponíveis.

11. 16 Eost 2026 da 10:25 UTCresolved

    Continuamos a trabalhar com o nosso parceiro de co-localização para restaurar a conectividade no local Equinix FR5 em Frankfurt, DEU. Desde a nossa última atualização, fizemos progressos significativos para restaurar o acesso seguro à área afetada. O procedimento de isolamento elétrico está em andamento, com nossas equipes no local na sala elétrica executando a des-energização da infra-estrutura afetada. Uma vez verificado o isolamento e confirmado a segurança, os engenheiros iniciarão uma inspeção física do equipamento de rede impactado para determinar o escopo de substituição necessário. Com base em nossa avaliação atual, a recuperação completa não é esperada em curto prazo devido ao alcance do potencial impactado ao equipamento. As conexões AWS Direct Connect neste local permanecem prejudicadas. Os clientes com conexões exclusivamente neste local continuarão a experimentar perda de pacotes. Clientes com configurações multi-site ou redundantes em outros locais do Direct Connect não são afetados. Para uma solução alternativa, os clientes impactados que têm a opção disponível para failover para VPN são recomendados para fazê-lo. Para os clientes que usam o Gateway Direct Connect e o Transit Gateway, recomendamos a criação de uma VPN AWS Site-to-Site e anexando-a ao seu Transit Gateway, consulte passos <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">aqui</a>. Para outros clientes, recomendamos estabelecer uma VPN AWS Site-to-Site como um caminho de backup temporário, consulte passos <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetupVPNConnections.html">aqui</a>. Continuamos a acompanhar de perto o progresso e compartilharemos uma atualização até 16 de agosto 09:30 PDT, ou mais cedo quando novas informações estiverem disponíveis.

12. 16 Eost 2026 da 16:30 UTCresolved

    O isolamento elétrico na Equinix FR5 em Frankfurt, DEU está agora completo e nossos engenheiros começaram a inspecionar fisicamente o equipamento de rede impactado. Ainda não temos uma linha do tempo para uma resolução completa, enquanto continuamos a avaliar a extensão do impacto no equipamento. As conexões diretas de conexão neste local permanecem prejudicadas. Os clientes com conexões exclusivamente neste local continuarão a experimentar perda de pacotes. Clientes com configurações multi-site ou redundantes em outros locais do Direct Connect não são afetados. Recomendamos que os clientes impactados failover para VPN até que tenhamos mais clareza nos próximos passos e uma linha do tempo de recuperação. Para os clientes que usam o Gateway Direct Connect e o Transit Gateway, você pode criar uma VPN AWS Site-to-Site e anexá-la ao seu Transit Gateway, consulte as etapas <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">aqui</a>. Para outros clientes, recomendamos estabelecer uma VPN AWS Site-to-Site como um caminho de backup temporário, consulte passos <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">aqui</a>. Nós forneceremos outra atualização até 16 de agosto 5:30 PDT, ou mais cedo quando novas informações estiverem disponíveis.

13. 16 Eost 2026 da 22:51 UTCresolved

    Completamos a nossa avaliação dos equipamentos de rede impactados na Equinix FR5 em Frankfurt, UED e agora temos uma compreensão clara do alcance do impacto. Estamos progredindo para restaurar a conectividade e vamos tomar uma abordagem faseada para a remediação. Os clientes com conexões exclusivas neste local continuarão a experimentar perda de pacotes até que a reparação esteja completa. Clientes com configurações multi-site ou redundantes em outros locais do Direct Connect não são afetados. Nós forneceremos outra atualização até 16 de agosto 10:30 PDT PM, ou mais cedo quando novas informações estiverem disponíveis.

14. 17 Eost 2026 da 05:38 UTCresolved

    Continuamos a fazer progressos na nossa recuperação faseada na Equinix FR5 em Frankfurt, UED. Desde nossa última atualização, alguma infraestrutura de rede dependente foi restaurada. A reparação da infra-estrutura restante está em curso, com uma parte da recuperação dependente da entrega de hardware de substituição. A refrigeração foi totalmente restaurada, com condições ambientais estáveis dentro dos limiares normais de funcionamento. Os clientes com conexões exclusivamente neste local continuarão a experimentar perda de pacotes à medida que a remediação progride. Clientes com configurações multi-site ou redundantes em outros locais do Direct Connect não são afetados. As orientações e recomendações de atenuação comunicadas anteriormente permanecem inalteradas neste momento. Nós forneceremos outra atualização até agosto 17 4:30 PDT, ou mais cedo como a reparação progride.

15. 17 Eost 2026 da 11:22 UTCresolved

    Continuamos a fazer progressos na nossa recuperação faseada na Equinix FR5 em Frankfurt, UED. A infraestrutura de rede e os sistemas dependentes continuam a melhorar à medida que trazemos hardware afetado de volta online. Algum hardware de substituição foi entregue e a instalação está continuando como componentes chegam no local. Paralelamente, estamos deslocando o tráfego de rede para permitir que dispositivos restaurados comecem a servir os clientes à medida que eles vêm online. À medida que avançamos através da recuperação, os clientes observarão a restauração ocorrendo em duas etapas. Na primeira fase, as sessões de BGP irão restabelecer-se, mas os prefixos IP ainda não serão anunciados, o que indica que a recuperação ainda está em curso e a infra-estrutura subjacente ainda não está pronta para transportar tráfego. Na segunda etapa, o prefixo IP será retomado, quando a infraestrutura é totalmente remediada e a conectividade restaurada. Embora atualmente não tenhamos um ETA para recuperação total, continuamos a trabalhar o mais rápido e seguro possível para mitigar o impacto para os clientes. Nós forneceremos outra atualização até 17 de agosto 10:30 PDT, ou mais cedo como a reparação progride.

16. 17 Eost 2026 da 16:25 UTCresolved

    Continuamos a trabalhar na remediação faseada de forma incremental no local Equinix FR5 em Frankfurt, DEU. Estamos a ver sinais precoces de recuperação enquanto continuamos a corrigir totalmente a questão. Estamos trabalhando ativamente para trazer o hardware restante afetado de volta on-line e vamos fornecer outra atualização até 12:30 PM PDT, ou mais cedo como a reparação progride.

17. 17 Eost 2026 da 17:59 UTCresolved

    Estamos vendo grandes sinais de recuperação no Equinix FR5 local em Frankfurt, DEU. Nós restauramos a conectividade para a maioria do hardware afetado e a maioria das conexões são totalmente recuperadas e estáveis. Há um pequeno número de clientes que permanecerão afetados até que os dispositivos restantes sejam totalmente restaurados. Nós forneceremos outra atualização até 2:00 PM PDT, ou mais cedo como a reparação progride.

18. 17 Eost 2026 da 21:00 UTCresolved

    Continuamos a trabalhar em trazer hardware afetado de volta online. Desde a nossa última atualização fizemos progressos que não serão visíveis para os clientes, mas é necessário para a recuperação. Estamos trabalhando em paralelo para trazer todos os dispositivos on-line o mais seguro possível. Espera-se que este trabalho demore várias horas para completar e validar. Para clientes que necessitam de soluções alternativas, recomendamos que você considere falhar em VPN. Para os clientes que usam o Gateway Direct Connect e o Transit Gateway, você pode criar uma VPN AWS Site-to-Site e anexá-la ao seu Transit Gateway, consulte as etapas <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">aqui</a>. Para outros clientes, recomendamos estabelecer uma VPN AWS Site-to-Site como um caminho de backup temporário, consulte passos <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">aqui</a>. Nós forneceremos outra atualização até 7:00 PM PDT ou mais cedo quando novas informações estiverem disponíveis.

19. 18 Eost 2026 da 01:50 UTCresolved

    Estamos vendo uma recuperação significativa para a maioria das conexões do cliente nesta fase. Embora ainda não estejamos totalmente recuperados, os esforços de restauração estão progredindo como esperado no local Equinix FR5 em Frankfurt, DEU. A reparação da infra-estrutura remanescente implica a conclusão de substituições de hardware e validação de tráfego, ambas ativamente em andamento. Prevemos uma recuperação mais visível do cliente, uma vez que a infra-estrutura restante é trazida de volta ao serviço. Os clientes com conexões exclusivas neste local continuarão a experimentar perda de pacotes até que a reparação esteja completa. As orientações e recomendações de atenuação comunicadas anteriormente permanecem inalteradas neste momento. Nós forneceremos outra atualização até 17 de agosto 11:00 PDT ou mais cedo.

20. 18 Eost 2026 da 04:01 UTCresolved

    A partir de 14 de agosto 7:33 PDT, experimentamos um aumento da perda de pacotes impactando a conectividade AWS Direct Connect para clientes com conexões no local Equinix FR5 em Frankfurt, DEU. Engenheiros foram automaticamente envolvidos às 7:45 em 14 de agosto e imediatamente começou a investigar mitigação. Por volta das 20h30, identificou-se que o equipamento de rede no local FR5 estava prejudicado devido à entrada de água na instalação de colocação. Como resultado, o sistema de refrigeração foi prejudicado, o que resultou em dispositivos superaquecimento e desligamento. A água também afetou os sistemas de distribuição de energia que desativaram a energia para os dispositivos de rede. Os esforços iniciais de recuperação foram atrasados à medida que as condições ambientais dentro da instalação necessitavam de estabilização antes que os engenheiros pudessem acessar com segurança a área afetada. Durante os dias 15 e 16 de agosto, nossos engenheiros trabalharam em coordenação com o operador da instalação para restaurar dispositivos de rede deficientes, enquanto a questão da infraestrutura subjacente foi abordada. Por volta das 19h26 de 17 de agosto, todos os equipamentos de rede deficientes foram restaurados com sucesso e a conectividade com o local foi verificada como totalmente operacional com recuperação sustentada. Não esperamos que esta questão se repita. Clientes com conexões redundantes em outros locais do Direct Connect mantiveram conectividade através de seus caminhos alternativos ao longo deste evento e não requerem mais nenhuma ação. Os clientes que implementaram o failover VPN como uma solução alternativa agora podem reverter com segurança para seus principais caminhos do Direct Connect. A conectividade foi verificada como estável e totalmente operacional. Os clientes que necessitem de assistência adicional podem entrar em contato com o Suporte AWS através do AWS Management Console ou do <a href="https://console.aws.amazon.com/support">AWS Support Center</a>.

Traduzido automaticamente da atualização oficial do incidente.

1. 31 Gouere 2026 da 17:33 UTCresolved

   Podemos confirmar perda elevada de pacotes de rede, impactando a conectividade AWS Direct Connect na Região AP-SOUTH-1. Nossa equipe de engenharia foi automaticamente engajada às 9:54 para começar a investigar o problema. Não há soluções disponíveis neste momento. Vamos fornecer outra atualização até 11:30 PDT.

2. 31 Gouere 2026 da 18:27 UTCresolved

   Identificamos a causa raiz a ser relacionada a uma mudança feita a um sistema de configuração responsável pela atribuição de rotas aos dispositivos. Começamos o trabalho para reduzir a perda de pacotes que está impactando o AWS Direct Connect na região AP-SOUTH-1, e esperamos que a recuperação ocorra gradualmente nos próximos 30 minutos. Ao ganharmos confiança nesses esforços, procuraremos paralelizar nossos esforços para acelerar a recuperação. Vamos fornecer outra atualização até 12:00 PM PDT.

3. 31 Gouere 2026 da 18:54 UTCresolved

   Entre 9:42 AM e 11:44 PDT, experimentamos uma perda elevada de pacotes de rede impactando a conectividade AWS Direct Connect na Região AP-SOUTH-1. Nossa equipe de engenharia foi automaticamente engajada às 9:46 para começar a investigar. Até 10:51, entendemos que a causa raiz é uma mudança de configuração feita para um sistema responsável pela atribuição de rotas aos dispositivos. À medida que ganhamos confiança em nossas etapas de mitigação, paralelizamos nossos esforços para reduzir ainda mais a perda de pacotes. O problema está resolvido e o serviço está funcionando normalmente.

Traduzido automaticamente da atualização oficial do incidente.

1. 24 Gouere 2026 da 11:40 UTCresolved

   Estamos investigando questões de connectividade impactando vários serviços da AWS na Região EUA-WEST-2.

2. 24 Gouere 2026 da 11:56 UTCresolved

   Estamos vendo sinais iniciais de recuperação e continuamos a trabalhar para recuperação plena.

3. 24 Gouere 2026 da 12:30 UTCresolved

   Continuamos a ver sinais significativos de recuperação como resultado de nossos esforços de mitigação para as questões de conectividade impactando vários serviços AWS na Região EUA-WEST-2. Identificamos a causa raiz como um problema com um dispositivo de rede responsável pelo roteamento de rede da Região para o Metro de Seattle. Os engenheiros terminaram todos os trabalhos de mitigação. À medida que as rotas continuam a ser restauradas, os clientes devem ver uma redução contínua das taxas de erro e dos intervalos de tempo ao se conectarem aos serviços afetados. Estamos monitorando o progresso da recuperação de perto e continuaremos trabalhando até que todas as rotas tenham sido totalmente restauradas e as métricas de serviço retornem aos níveis pré-evento. Forneceremos outra atualização nos próximos 30-45 minutos.

4. 24 Gouere 2026 da 13:01 UTCresolved

   Entre 3:55 AM e 4:15 PDT, experimentamos problemas de conectividade que impactaram a conectividade com a Região US-WEST-2. Esta situação afectou vários serviços da AWS na região. Alguns clientes também podem ter experimentado problemas acessando o Console de Gerenciamento AWS, com timeouts de conexão e páginas sem resposta. A conectividade na região não foi afectada. Nossos engenheiros foram automaticamente engajados às 04:01 PDT, e imediatamente começaram a investigar esta questão. Identificamos a causa raiz como um problema com dispositivos de rede responsáveis pelo roteamento de rede da Região para o Metro de Seattle, e começamos a trabalhar em paralelo em múltiplos caminhos para mitigar o impacto. Tomamos medidas de mitigação que levaram à recuperação inicial às 4h15 PDT. À medida que a rede continuou a estabilizar após nossas ações de mitigação, um breve evento de reconvergência ocorreu entre 4:47 AM e 4:59 AM PDT. Durante este período de reconvergência, alguns clientes podem ter experimentado problemas de conectividade intermitentes para a Região, uma vez que as rotas da rede foram restabelecidas. Por volta das 4:59 AM PDT, todas as rotas foram totalmente restauradas e as métricas de serviço retornaram aos níveis pré-evento. Clientes usando AWS Direct Connect através da EqSe2, Westin Building Exchange, Seattle experimentou uma janela de impacto estendida de 3:55 AM a 5:12 PDT. Esses clientes teriam experimentado problemas de conectividade até que as rotas de rede para este caminho específico fossem totalmente restauradas às 5:12 AM PDT. Os clientes conectados de forma redundante através de outros locais AWS Direct Connect não foram afetados por este evento. O problema foi resolvido e todos os serviços AWS estão funcionando normalmente.

Traduzido automaticamente da atualização oficial do incidente.

1. 17 Gouere 2026 da 08:33 UTCresolved

   Estamos investigando problemas com o Cost Explorer refletindo dados de faturamento estimados imprecisos.

2. 17 Gouere 2026 da 09:07 UTCresolved

   A partir de 16 de julho 7:38 PDT, começamos a exibir dados de faturamento estimados incorretos no Console de Faturamento e Gestão de Custos. As nossas equipas de engenharia estão a investigar a causa principal. Nós forneceremos outra atualização até 3:00 AM PDT ou mais cedo se mais informações estiverem disponíveis.

3. 17 Gouere 2026 da 10:03 UTCresolved

   Continuamos a trabalhar para resolver o problema que afeta os dados estimados de custo e uso exibidos no Console de Faturamento e Gestão de Custos. Identificamos a causa raiz como um problema com o preço unitário dentro do subsistema de cálculo de faturamento estimado e estamos trabalhando em uma mitigação. As estimativas de faturamento exibidas não refletem o uso e os encargos reais. Não são necessárias ações do cliente neste momento. Uma vez que o problema tenha sido mitigado, esperamos que a resolução total leve várias horas enquanto trabalhamos recomputando os dados de faturamento estimados. Nós forneceremos outra atualização até 4:00 AM PDT ou mais cedo se mais informações estiverem disponíveis.

4. 17 Gouere 2026 da 10:52 UTCresolved

   Continuamos a trabalhar para resolver o problema que afeta os dados estimados de custo e uso exibidos no Console de Faturamento e Gestão de Custos. Como anteriormente compartilhado, identificamos a causa raiz como um problema com preços unitários dentro do subsistema de cálculo de faturamento estimado. Para evitar que novas estimativas de faturamento imprecisas sejam exibidas, pausamos cálculos de faturamento estimados. Os clientes que estão atualmente vendo estimativas de fatura normais continuarão a ver essas estimativas, e os clientes que estão vendo estimativas inflacionadas não vão vê-los aumentar ainda mais enquanto trabalhamos para a resolução. As estimativas de faturamento exibidas não refletem o uso e os encargos reais. Continuamos a trabalhar na mitigação total da questão. Uma vez que o problema tenha sido mitigado, esperamos que a resolução total leve várias horas enquanto trabalhamos recomputando os dados de faturamento estimados. Não são necessárias ações do cliente neste momento. Nós forneceremos outra atualização até 5:00 AM PDT ou mais cedo se mais informações estiverem disponíveis.

5. 17 Gouere 2026 da 11:58 UTCresolved

   Continuamos a trabalhar para resolver o problema que afeta os dados estimados de custo e uso exibidos no Console de Faturamento e Gestão de Custos. Estamos trabalhando ativamente em múltiplos caminhos de mitigação em paralelo. O primeiro caminho envolve reverter para o último bem conhecido cálculo de contas estimadas. Com esta abordagem, os clientes só verão dados de custo e uso até 15 de julho, no entanto, os dados de custo inflacionado serão removidos. O segundo caminho envolve o retorno de uma mudança recente para o subsistema de cálculo de faturamento. As estimativas de faturamento exibidas não refletem o uso e os encargos reais. Não são necessárias ações do cliente neste momento. Uma vez que o problema tenha sido mitigado, esperamos que a resolução total leve várias horas enquanto trabalhamos recomputando os dados de faturamento estimados. Nós forneceremos outra atualização até 6:00 PDT ou mais cedo se mais informações estiverem disponíveis.

6. 17 Gouere 2026 da 12:54 UTCresolved

   Continuamos trabalhando em múltiplos caminhos de mitigação em paralelo para resolver o problema afetando os dados de custo e uso estimados exibidos no Console de Faturamento e Gestão de Custos, incluindo o Relatório de Custo e Uso. Estamos avaliando novamente cálculos de faturamento estimados, pois nosso monitoramento interno indica que o subsistema de computação de faturamento está agora produzindo estimativas precisas. Estamos realizando validação adicional antes de prosseguir com este caminho. As estimativas de faturamento exibidas não refletem o uso e os encargos reais. Não são necessárias ações do cliente neste momento. Nós forneceremos outra atualização até 8:00 PDT ou mais cedo se mais informações estiverem disponíveis.

7. 17 Gouere 2026 da 14:53 UTCresolved

   Continuamos a trabalhar para resolver o problema que afeta os dados de custo e uso estimados exibidos no Console de Faturamento e Gestão de Custos, incluindo o Relatório de Custo e Uso. O retrocesso de uma mudança recente não resolveu o problema e continuamos a investigar múltiplos caminhos de mitigação. As atualizações de contas estimadas permanecem pausadas. Estamos no processo de reverter para os últimos dados de faturamento estimados precisos. As estimativas de faturamento exibidas não refletem o uso e os encargos reais. Não são necessárias ações do cliente neste momento. Esperamos que essa mitigação leve várias horas para ser completada enquanto trabalhamos recomputando os dados de faturamento estimados. Nós forneceremos outra atualização até 10:00 PDT ou mais cedo se mais informações estiverem disponíveis.

8. 17 Gouere 2026 da 16:59 UTCresolved

   Identificamos a causa raiz e amenizamos o problema subjacente, fazendo com que dados de custo e uso estimados incorretos sejam exibidos no Console de Faturamento e Gestão de Custos, e Relatórios de Custo e Uso. Começamos a preencher os dados para corrigir os dados de custo para todos os clientes. Esperamos que alguns clientes comecem a ver recuperação dentro das próximas três horas, e recuperação completa para todos os clientes até 18 de julho 12:00 PDT. Até que o preenchimento esteja completo, alguns clientes ainda podem ver dados de custo e uso incorretos. As estimativas de faturamento exibidas não refletem o uso e os encargos reais. Não são necessárias ações do cliente neste momento. Nós forneceremos outra atualização até 1:00, ou mais cedo se as informações estiverem disponíveis.

9. 17 Gouere 2026 da 19:56 UTCresolved

   Nossos esforços para preencher os dados de custo e uso estimados corrigidos ainda estão em andamento. Estamos a progredir mais devagar do que o previsto. Enquanto vemos algumas contas recuperar com os dados de custo e uso corretos, esperamos que todas as contas afetadas sejam recuperadas até 19 de julho 12:00 PDT. Até que o preenchimento esteja completo, alguns clientes ainda podem ver dados de custo e uso incorretos. As estimativas de faturamento exibidas não refletem o uso e os encargos reais. Não são necessárias ações do cliente neste momento. Nós forneceremos outra atualização até 19:00, ou mais cedo se a informação ficar disponível.

10. 18 Gouere 2026 da 01:38 UTCresolved

    Continuamos a fazer progressos constantes para resolver o problema afetando os dados estimados de custo e uso exibidos no Console de Faturamento e Gestão de Custos. Nossos esforços para preencher dados corrigidos permanecem em andamento, e esperamos que todas as contas afetadas sejam totalmente recuperadas até 19 de julho de 12:00 PDT. Até que o backfill esteja completo, alguns clientes ainda podem observar dados de custo e uso incorretos no Console de Faturamento e Gestão de Custos e Relatórios de Custo e Uso. Estas estimativas não reflectem a utilização ou os encargos reais. Os clientes que configuraram seu Relatório de Custo e Uso com a opção "Sobrescrever" não requerem nenhuma ação — seu relatório será atualizado automaticamente com dados corrigidos assim que o backfill terminar. Os clientes que configuraram seu Relatório de Custo e Uso com a opção "Criar novas versões de relatório" mantêm todas as entregas de relatórios anteriores em seu balde S3. A versão do relatório entregue durante a janela impactada pode conter dados imprecisos. Assim que o preenchimento dos dados estiver completo, uma versão corrigida do relatório será entregue sob um novo AssemblyId. Os clientes que usam esta configuração devem atualizar quaisquer processos a jusante (mesas Athena, tubulações Redshift, Amazon QuickSight ou ETL personalizado) para referenciar o último conjuntoId para o período de faturamento afetado, e podem excluir ou arquivar a versão do relatório impactado para evitar o processamento de dados obsoletos. Para identificar o último relatório, os clientes podem seguir os passos em nosso <a href="https://docs.aws.amazon.com/cur/latest/userguide/view-latest-cur.html">documentation</a>. Nós forneceremos outra atualização até 18 de julho, 1:00 PDT AM, ou mais cedo se informações adicionais estiverem disponíveis.

11. 18 Gouere 2026 da 08:05 UTCresolved

    Continuamos a fazer progressos substanciais na resolução do problema, afetando os dados estimados de custo e uso exibidos no Console de Faturamento e Gestão de Custos. Nossos esforços de mitigação estão funcionando como esperado e estamos vendo um número crescente de contas refletindo os dados corretos de custo e uso. Esperamos que todas as contas afetadas sejam totalmente recuperadas até 19 de julho de 12:00 PDT. Até que o backfill esteja completo, alguns clientes ainda podem observar dados de custo e uso incorretos no Console de Faturamento e Gestão de Custos e Relatórios de Custo e Uso. Estas estimativas não reflectem a utilização ou os encargos reais. Nós forneceremos outra atualização até 18 de julho, 7:00 PDT, ou mais cedo se informações adicionais estiverem disponíveis.

12. 18 Gouere 2026 da 13:57 UTCresolved

    Entre 16 de julho às 7:38 PDT e 18 de julho às 6:00 PDT, começamos a exibir dados de faturamento estimados incorretos no Console de Faturamento e Gestão de Custos, incluindo o Relatório de Custo e Uso. Os clientes podem ter recebido alertas errôneos de detecção de anomalias de orçamento e custo, e observaram dados de custo e uso estimados inflacionados. Em 16 de julho às 19:46 PM PDT, nossos alarmes detectaram anomalias de custo, mas não pararam o processo de geração de contas estimado ou alertaram nossas equipes de engenharia. Fomos alertados para esta questão no dia 17 de julho às 12:19 PDT pela escalada do cliente, e imediatamente começou a investigar. Primeiro informamos os clientes através da AWS Health no dia 17 de julho às 1:33. Às 8:24 AM PDT, pausamos novas atualizações para dados de faturamento estimados e desligamos os alertas de anomalia de orçamento e custo como medida de precaução. Identificamos a causa raiz em 17 de julho às 12:00 PM PDT como uma mudança de configuração em nosso sistema de cálculo de contas. Este sistema baseia-se em dados de conversão de unidade para calcular as cargas do item da linha. A mudança de configuração fez com que as atualizações dos dados de conversão da unidade falhassem, resultando em custos inflados de itens de linha, que se propagaram para o console Billing and Cost Management e alertas de anomalia de orçamento e custo desencadeados. Mitigamos o problema no dia 17 de julho às 12:30 PM PDT, que corrigiu a configuração de conversão da unidade e começou a reprocessamento de dados de custo e uso para todas as contas de clientes. Começamos a observar recuperação às 4:19 PM PDT, e a maioria das contas foram totalmente recuperadas até 18 de julho às 6:00 AM PDT. Há um pequeno número de contas ainda processando e vamos postar atualizações para essas contas no Painel de Saúde Pessoal. Corrigimos nossos alarmes para parar imediatamente o processamento e notificar nossas equipes de engenharia quando ocorrerem anomalias. Pedimos desculpas pelo alarme que este incidente causou aos nossos clientes e estamos realizando uma retrospectiva completa para evitar que eventos como este ocorram novamente, bem como melhorar a nossa resposta quando ocorrem incidentes de faturamento. A questão foi resolvida e todos os serviços da AWS estão agora a funcionar normalmente.

Traduzido automaticamente da atualização oficial do incidente.

1. 16 Gouere 2026 da 08:44 UTCresolved

   Estamos investigando erros 5xx aumentados para clientes Cloudfront utilizando conectividade VPC Origins.

2. 16 Gouere 2026 da 09:21 UTCresolved

   A partir das 12:45 AM PDT, estamos experimentando erros 5xx aumentados para clientes CloudFront utilizando conectividade VPC Origins. Confirmamos que os clientes que utilizam outros tipos de origem não são afetados por esta questão. Nossos engenheiros estão envolvidos e estão trabalhando ativamente para mitigar o impacto. Como solução alternativa, os clientes que não necessitam de VPC Origins podem alterar seu tipo de origem para resolver os erros. Forneceremos outra atualização até 3:15 AM PDT, ou mais cedo se mais informações estiverem disponíveis.

3. 16 Gouere 2026 da 10:18 UTCresolved

   Continuamos trabalhando para resolver o aumento de erros de 5xx para clientes CloudFront utilizando conectividade VPC Origins. Os clientes que utilizam outros tipos de origem não são afetados por esta questão. Com base em nossa investigação, acreditamos que a causa raiz está relacionada a um subsistema de processamento de pacotes responsável pelas solicitações de roteamento dos locais de borda da CloudFront para recursos dentro dos VPCs do cliente. Nós continuamos a recomendar que os clientes que são capazes de fazê-lo temporariamente alterar o seu tipo de origem para resolver os erros. Nós forneceremos outra atualização até 4:15 AM PDT, ou mais cedo se informações adicionais estiverem disponíveis.

4. 16 Gouere 2026 da 11:16 UTCresolved

   Continuamos trabalhando para resolver o aumento de erros de 5xx para clientes CloudFront utilizando conectividade VPC Origins. Os clientes que utilizam outros tipos de origem não são afetados por esta questão. Analisamos ainda mais o problema até a capacidade da tabela de roteamento dentro do subsistema de processamento de pacotes responsável pelas solicitações de roteamento dos locais de borda da CloudFront para recursos dentro dos VPCs do cliente. Identificámos e estamos actualmente a testar uma estratégia de mitigação para resolver a questão. Assim que o teste estiver concluído, iremos implantar a mitigação em uma abordagem faseada. Com base nos resultados desses testes, forneceremos um tempo estimado de resolução mais claro em nossa próxima atualização. Nós continuamos a recomendar que os clientes que são capazes de fazê-lo temporariamente alterar o seu tipo de origem para resolver os erros. Nós forneceremos outra atualização até 5:15 AM PDT, ou mais cedo se informações adicionais estiverem disponíveis.

5. 16 Gouere 2026 da 11:27 UTCresolved

   Estamos vendo sinais iniciais de recuperação e continuamos a trabalhar para recuperação plena.

6. 16 Gouere 2026 da 11:57 UTCresolved

   Continuamos a ver sinais significativos de recuperação como resultado de nossos esforços de mitigação, com total recuperação prevista nos próximos 45 minutos.

7. 16 Gouere 2026 da 12:21 UTCresolved

   Entre 12:45 AM e 4:18 PDT, experimentamos erros 5xx aumentados para clientes CloudFront utilizando conectividade VPC Origins. Nossos engenheiros foram automaticamente envolvidos e imediatamente começaram a investigar a causa raiz. Por volta das 2:57 AM PDT, identificamos a causa básica do problema como uma restrição interna na frota que gerencia conexões com origens privadas de VPC. Quando essa restrição foi alcançada, o sistema responsável pela distribuição da configuração de roteamento para nossos processadores de rede não conseguiu carregar os dados de configuração atualizados corretamente, afetando o roteamento das conexões VPC Origin. Às 3:52 AM PDT, tomamos múltiplas ações de mitigação que levaram à recuperação plena às 4:18 AM PDT. Agora que o problema foi atenuado, os clientes que mudaram temporariamente seu tipo de origem podem reverter essas alterações com segurança. Os clientes que utilizam outros tipos de origem não foram afetados por esta questão. O problema foi resolvido e o serviço está funcionando normalmente.

Traduzido automaticamente da atualização oficial do incidente.

1. 15 Gouere 2026 da 23:11 UTCresolved

   Estamos investigando problemas de conectividade elevados com uma única zona de Avalabilidade (euc1-az2) na Região UE-CENTRAL-1.

2. 15 Gouere 2026 da 23:36 UTCresolved

   Estamos vendo sinais iniciais de recuperação e continuamos a trabalhar para uma resolução completa. Continuaremos a fornecer atualizações.

3. 16 Gouere 2026 da 01:24 UTCresolved

   Entre 2:56 PM e 6:07 PM PDT, tivemos problemas de conectividade para um subconjunto de instâncias EC2 em uma única Zona de Disponibilidade (euc1-az2) na Região EU-CENTRAL-1. Durante este tempo, os clientes também podem ter experimentado taxas de erro aumentadas e latências para novos lançamentos de instância na zona afetada, juntamente com algumas APIs AWS que usam as instâncias EC2 afetadas. Alguns Serviços AWS também experimentaram problemas de conectividade e aumentaram as taxas de erro dentro da zona afetada. Os engenheiros foram automaticamente envolvidos e imediatamente começaram a investigar. Como parte de nosso esforço de recuperação, deslocamos o tráfego para longe da área de disponibilidade impactada para os serviços afetados às 3:04. Às 15h05, identificamos a causa raiz como uma mudança recente na rede causando o impacto. Engenheiros imediatamente começaram a reverter esta mudança que terminou às 4:28. Isso resultou na restauração da conectividade de rede para a zona afetada às 4:30 PM. Continuamos a trabalhar até recuperarmos totalmente os impactos às 18:07. Não esperamos que esta questão se repita. O problema foi resolvido e o serviço está funcionando normalmente.

Traduzido automaticamente da atualização oficial do incidente.

1. 6 Gouere 2026 da 12:45 UTCresolved

   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. 6 Gouere 2026 da 13:34 UTCresolved

   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. 6 Gouere 2026 da 14:12 UTCresolved

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

4. 6 Gouere 2026 da 14:53 UTCresolved

   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.

1. 30 Mezheven 2026 da 21:02 UTCresolved

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

2. 30 Mezheven 2026 da 21:21 UTCresolved

   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. 30 Mezheven 2026 da 21:29 UTCresolved

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

4. 30 Mezheven 2026 da 21:53 UTCresolved

   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.

1. 13 Mezheven 2026 da 01:26 UTCresolved

   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. 15 Mezheven 2026 da 18:13 UTCresolved

   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>.

1. 6 Mezheven 2026 da 04:24 UTCresolved

   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.

1. 22 Mae 2026 da 23:38 UTCresolved

   We are investigating increased error rates for Route53 API calls.

2. 23 Mae 2026 da 00:13 UTCresolved

   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.

1. 8 Mae 2026 da 00:25 UTCresolved

   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. 8 Mae 2026 da 00:53 UTCresolved

   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. 8 Mae 2026 da 01:47 UTCresolved

   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. 8 Mae 2026 da 03:06 UTCresolved

   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. 8 Mae 2026 da 05:11 UTCresolved

   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. 8 Mae 2026 da 06:38 UTCresolved

   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. 8 Mae 2026 da 08:32 UTCresolved

   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. 8 Mae 2026 da 10:54 UTCresolved

   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. 8 Mae 2026 da 13:51 UTCresolved

   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. 8 Mae 2026 da 15:58 UTCresolved

    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. 8 Mae 2026 da 16:30 UTCresolved

    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. 8 Mae 2026 da 18:12 UTCresolved

    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. 8 Mae 2026 da 19:29 UTCresolved

    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. 8 Mae 2026 da 23:00 UTCresolved

    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. 9 Mae 2026 da 03:04 UTCresolved

    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.

1. 27 Ebrel 2026 da 11:27 UTCresolved

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

2. 27 Ebrel 2026 da 12:05 UTCresolved

   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.

1. 7 Meurzh 2026 da 19:53 UTCresolved

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

2. 7 Meurzh 2026 da 20:17 UTCresolved

   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. 7 Meurzh 2026 da 20:28 UTCresolved

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

4. 7 Meurzh 2026 da 21:04 UTCresolved

   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.

1. 2 Meurzh 2026 da 05:56 UTCresolved

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

2. 2 Meurzh 2026 da 07:09 UTCresolved

   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. 2 Meurzh 2026 da 09:03 UTCresolved

   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. 2 Meurzh 2026 da 10:41 UTCresolved

   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. 2 Meurzh 2026 da 14:23 UTCresolved

   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. 2 Meurzh 2026 da 18:52 UTCresolved

   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. 2 Meurzh 2026 da 22:29 UTCresolved

   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. 3 Meurzh 2026 da 00:22 UTCresolved

   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. 3 Meurzh 2026 da 06:27 UTCresolved

   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. 3 Meurzh 2026 da 11:10 UTCresolved

    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. 3 Meurzh 2026 da 14:02 UTCresolved

    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. 3 Meurzh 2026 da 16:40 UTCresolved

    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. 30 Ebrel 2026 da 07:07 UTCinvestigating

    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. 15 Gwengolo 2026 da 10:22 UTCinvestigating

    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.