O Amazon Web Services está fora do ar?

Como funciona a disponibilidade da AWS

O Amazon Web Services é um conjunto de serviços de nuvem que opera entre contas, regiões e zonas de disponibilidade — não uma única aplicação com um único estado universal de disponibilidade. Um incidente que afeta um serviço ou uma região específica pode deixar outras cargas de trabalho da AWS operando normalmente.

Comece pela página oficial de status do AWS Health. Compare qualquer evento com o serviço, a região, o recurso, a conta ou o ambiente afetado, além do horário aproximado da falha. Se não houver um evento correspondente, investigue causas específicas da conta, da carga de trabalho, da configuração e da conectividade antes de considerar o problema uma indisponibilidade ampla da AWS.

Uma página pública de status saudável não prova que todos os recursos estejam saudáveis. Credenciais, permissões, DNS, roteamento, controles de segurança, seleção de endpoint, alterações de implantação e código da aplicação podem afetar um serviço baseado na AWS.

Solução de problemas de falhas da AWS

1. Verifique se há um incidente de serviço ou regional

Abra a página oficial de status do AWS Health e procure um evento correspondente ao serviço, à região e ao horário aproximado de início da falha. Um evento correspondente torna mais provável a existência de um problema do lado do provedor. Evite alterar repetidamente as configurações de produção ou reimplantar recursos enquanto um incidente estiver sendo investigado.

Se nenhum evento correspondente aparecer, o problema pode estar limitado a uma conta, carga de trabalho, região, recurso ou caminho de rede.

2. Identifique a camada que está falhando

Defina a operação exata que falha: abrir o console da AWS, implantar código, resolver um hostname, chamar um endpoint da AWS, ler dados do armazenamento ou conectar-se a um banco de dados. Verifique se recursos ou serviços não relacionados na mesma região continuam funcionando.

Compare a falha com uma implantação ou alteração de configuração recente. Analise os logs em busca do erro exato da AWS, horário da solicitação, região, identificador do recurso e operação. Uma resposta HTTP 5xx, por si só, não mostra que a AWS está fora do ar; ela pode ter sido gerada pela aplicação, pelo proxy, pelo load balancer ou pelo gateway.

3. Verifique causas relacionadas à conta, às permissões e à configuração

Para uma falha limitada a uma conta, ambiente ou recurso, confirme a região selecionada, o estado do recurso, as credenciais, as permissões, o endpoint, as cotas e as alterações recentes na infraestrutura. Confirme que a aplicação está usando a conta e a região pretendidas. Se uma identidade ou implantação falhar enquanto um caminho conhecido como funcional operar normalmente, investigue o acesso e a configuração antes de considerar o problema generalizado na plataforma.

4. Verifique problemas específicos do navegador e do console

Se o console da AWS ou uma aplicação hospedada falhar em apenas um navegador ou dispositivo, tente uma janela privativa, outro navegador compatível ou outro dispositivo. Registre o erro visível antes de limpar os dados do site. Um problema restrito ao console pode ser independente da saúde dos recursos subjacentes da AWS.

5. Verifique a rede, o DNS e a conectividade

Quando possível, faça o teste a partir de uma segunda rede. Compare a resolução de DNS, a negociação de TLS e o comportamento da conexão para o hostname afetado. Falhas de DNS, recusas de conexão, erros de certificado e timeouts podem resultar de DNS local, configurações de VPN ou proxy, regras de firewall, roteamento, security groups, network ACLs, listeners do load balancer ou da aplicação de destino.

Se a solicitação funcionar a partir de outra rede ou região, investigue o caminho entre o cliente e a AWS em vez de presumir uma indisponibilidade global.

6. Verifique falhas de SDK, CLI, webhook e automação

Registre a categoria completa do erro e a operação. Diferencie erros de autenticação ou autorização de problemas de throttling, validação, endpoint, timeout e erros do lado do servidor. Confirme a região e o endpoint configurados e só tente novamente quando for seguro repetir a operação. Para alterações em produção, preserve os IDs das solicitações e os horários para investigação ou escalonamento ao suporte.