Quando se trata de verificar se a AWS está indo bem ou está passando por um momento difícil, não basta apenas olhar para uma luz verde ou vermelha: Você tem que cruzar o painel de saúde, sinais em tempo real e avaliações específicas de seus recursosCom essa abordagem combinada, você saberá se o problema é geral, regional ou relacionado à sua própria infraestrutura e poderá agir sem fazer nenhuma tentativa descontrolada.
Neste guia, vou deixar tudo bem estruturado para você verificar o status da AWS com uma cabeça: do AWS Health Dashboard e sua integração com o EventBridge, como visualizar o status de renovação no ACM, interpretar verificações do EC2 e reagir com métricas e alarmes do CloudWatch. Você também descobrirá quais etapas tomar se o console se recusar a carregar, como verificar a página de status pública e por que terceiros, como o Downdetector, são úteis para contexto, mas não para automação.
Painel de saúde da AWS: o ponto de partida
O AWS Health Dashboard exibe interrupções, eventos ativos e manutenção planejada que podem afetar seus serviços e recursos. Faz parte da sua conta, não requer configuração e fornece visibilidade contextual. sobre o que está acontecendo. Se você não estiver conectado a uma instância ou console específico, este é o primeiro lugar para verificar.
Um detalhe que muitas vezes é esquecido: A AWS é regionalSelecione a região correta no seletor do painel Saúde, pois, se você pesquisar a região errada, poderá perder o incidente que o afeta. Essa precisão evita diagnósticos incorretos quando o problema se limita a uma área geográfica específica.
A partir de 2023, ao abrir um evento público no painel Saúde, O URL do navegador inclui um link profundo para o eventoIsso permite que você compartilhe o incidente exato que está visualizando ou o reabra e retorne à mesma visualização com a janela pop-up carregada, facilitando o trabalho em equipe durante um incidente.
Se o console de administração não abrir ou retornar erros do navegador (por exemplo, 404), não se precipite. Primeiro verifique se há um evento ativo relevante no Painel de Saúdee, em seguida, aplique medidas locais, como limpar o cache e os cookies, tentar um navegador diferente e confirmar com sua equipe de TI se sua rede não está bloqueando domínios da Amazon (amazon.com e subdomínios como aws.amazon.com).
Ingestão confiável de eventos: EventBridge é melhor que RSS
Existem feeds RSS com eventos de saúde, mas seu formato pode mudar ao longo do tempo e quebrar suas integraçõesExtrair ou depender de RSS para pipelines críticos é arriscado, para dizer o mínimo.
O robusto é integrar AWS Health com Amazon EventBridgeDessa forma, você recebe eventos com um esquema estável, em tempo real e prontos para serem roteados para Lambda, filas, notificações ou dashboards internos, criando seu circuito de incidentes sem partes frágeis.
Com o EventBridge você ganha rastreabilidade e resiliência: Você pode marcar, enriquecer, correlacionar e automatizar respostas dependendo do serviço, região ou impacto. E se os detalhes da apresentação do feed público mudarem amanhã, sua integração permanecerá intacta.
ACM: Revise renovações de certificados sem problemas
Com o AWS Certificate Manager, você pode verificar se seus certificados estão sendo renovados corretamente e de maneira gerenciada. Um certificado é elegível para renovação automática quando está associado a serviços da AWS (por exemplo, ELB ou CloudFront) ou se foi exportado desde sua emissão ou última renovação.Essa elegibilidade é a base para esquecer as renovações manuais.
Quando o ciclo de renovação começa, o ACM exibe um campo de status nos detalhes do certificado. No console, API ou CLI, você pode verificar o RenewalStatus para saber sua situação. Você também verá status relevantes relacionados ao seu painel de Saúde, caso haja algum problema que exija sua atenção.
Se você preferir comandos, a CLI facilita: A operação describe-certificate retorna os detalhes, incluindo o status de renovação.. Por exemplo:
Exemplo: aws acm describe-certificate --certificate-arn arn:aws:acm:REGION:ACCOUNT:certificate/CERTIFICATE_ID
Na resposta JSON, observe o campo RenewalStatus. Se esse campo ainda não aparecer, o ACM não iniciou a renovação gerenciada.. É uma boa ideia planejar com antecedência: o ACM tenta renovar automaticamente cerca de 60 dias antes do vencimento e, se algo der errado (validação de domínio, por exemplo), Você receberá notificações em Saúde com antecedência: 45, 30, 15, 7, 3 e 1 dia.
Quando o console não carrega: etapas rápidas e eficazes
Erros 404 ou falhas de conexão ao acessar o console da AWS geralmente são solucionáveis. Comece revisando o Painel de Saúde na região onde seus recursos estão localizados. para descartar um evento em andamento que afeta aquele serviço ou console.
Se não houver incidentes abertos, aplique medidas locais: limpar cache e cookies do navegador, tente fazer login com outro navegador e confirme com o administrador do sistema se a rede corporativa não bloqueia amazon.com ou subdomínios como aws.amazon.com.
O problema pode estar limitado a um recurso específico. Por exemplo, uma instância EC2 pode estar passando por manutenção planejada., e o painel Saúde mostrará a janela e o impacto desse evento. Ir até a raiz economiza seu tempo.
Além disso, se o bloqueio for na sua conta, é sempre uma boa ideia ter artigos de ajuda à mão: Crie e ative uma nova conta, faça login no console ou solicite assistência.Ter esses guias localizados reduz o tempo de espera em momentos de estresse.
EC2 em detalhes: verificações de status e o que fazer quando elas falham
O Amazon EC2 realiza verificações automáticas por instância para detectar problemas de plataforma ou software que afetam seus aplicativos. Essas verificações são executadas a cada minuto e marcadas como OK ou prejudicadas, dependendo do resultado.. Eles não podem ser desligados e são seu alerta precoce.
Cada tipo de verificação é suportado por métricas no CloudWatch. Se uma verificação falhar, a métrica associada aumenta e é hora de dar o alarme.Com isso, você pode automatizar notificações e ações para minimizar o tempo de inatividade.
Verificações do sistema (plataforma subjacente)
Essas verificações monitoram a infraestrutura onde sua instância é executada. Quando falham, geralmente é um problema de plataforma que exige intervenção da AWS ou medidas para mover a instância para outro host..
Em casos suportados pelo EBS, a ação eficaz é pare e inicie a instância para realocá-la para um novo hostSe sua instância usar o repositório de instâncias (Linux), você poderá optar por encerrar e substituir, sabendo que volumes efêmeros serão perdidos no desligamento.
A métrica que reflete essa falha é StatusCheckFailed_SystemÉ perfeito para alarmes que acionam runbooks, recuperação automática ou abertura de um caso de suporte se a situação persistir.
Há uma peculiaridade com o Bare Metal: Uma reinicialização do sistema operacional pode causar temporariamente um erro de verificação do sistema.. Quando a instância estiver funcionando novamente, o status retornará para OK sem intervenção adicional.
Verificações de instância (conectividade e software)
Essas verificações analisam a integridade do sistema operacional e da rede da própria instância. O EC2 valida a conectividade enviando solicitações ARP ao NIC para verificar se ele está respondendo.Uma falha aqui geralmente requer ajustes de sua parte.
Se a verificação falhar, é hora de agir: Reinicie a instância, verifique o firewall/iptables, verifique os logs do sistema e certifique-se de que a rede esteja respondendo.Quando a causa é software ou configuração, esperar não é suficiente.
A métrica a ser observada é Instância_StatusCheckFailed. Use-o para acionar alarmes que executam procedimentos de diagnóstico (coleta de logs, reinicializações controladas ou reversões se você detectar que não está se recuperando).
Novamente, no Bare Metal, um erro temporário pode aparecer ao reinicializar o sistema operacional. Quando a instância conclui a inicialização, as verificações normalmente retornam para OK., então não entre em pânico.
Verificações anexadas do EBS (E/S em volumes)
Essas verificações validam se os volumes EBS anexados estão acessíveis e podem concluir operações de entrada/saída. A métrica binária StatusCheckFailed_AttachedEBS indica deterioração quando um ou mais volumes falham..
Um erro nessa frente pode ser devido a problemas computacionais subjacentes ou problemas no EBS. Você pode esperar mitigação da AWS ou tomar medidas: Substitua volumes, pare e inicie a instância para movê-la para outro host ou revise o dimensionamento do IOPS se observar gargalos.
Se sua carga não fizer E/S, mas ocorrer deterioração, Um ciclo de parada e inicialização pode resolver problemas de host que afetam a acessibilidade do volume.. Complemente com métricas nativas do EBS no CloudWatch para detectar padrões de desempenho insatisfatórios.
Em grupos de dimensionamento automático, configure a política para Remover instâncias com falhas persistentes na verificação do EBS anexadaVocê manterá sua frota saudável sem intervenção manual e evitará tempo de inatividade prolongado.
Alarmes e automação: CloudWatch + dimensionamento automático
Com todas as métricas de saúde, o CloudWatch se torna seu sistema nervoso. Defina limites, crie alarmes e orquestre ações: notificações, Lambda, recuperação ou substituição de instância. É a base para respostas automáticas e consistentes.
Se você precisa de continuidade de negócios, considere automatizar e substituir: O dimensionamento automático pode desativar instâncias com falha e iniciar novas, enquanto seus alarmes ativam os canais de notificação apropriados (e-mail, Slack, PagerDuty ou qualquer outro que você usar).
A visão completa vem de fontes correlacionadas: Métricas e logs do CloudWatch, rastreamentos e eventos do AWS Health via EventBridgeCom este bloco, você poderá distinguir se o problema está no seu aplicativo, na instância, no volume ou na plataforma e poderá reagir com precisão.
Fontes oficiais e contextuais para saber se a AWS falha
Quando circulam rumores de uma queda — como o Falha global da AWS que causaram falhas massivas—, o ideal é priorizar fontes oficiais. Verifique a página pública status.aws.amazon.com para ver o status por serviço e região.e use o AWS Health Dashboard se estiver conectado para obter informações específicas da conta.
Fontes terceirizadas fornecem contexto e sinais sociais adicionais. O Downdetector reflete picos em relatórios de usuários, e o The Stack Status resume o status de vários provedores.Eles são úteis para estimar o alcance, embora não substituam os canais oficiais.
No entanto, ele distingue entre visibilidade e automação. Para ingestão programática de eventos, o EventBridge é melhor do que feeds RSS ou scraping., porque formatos externos podem mudar e deixar você no meio de um incidente.
Como as grandes quedas se manifestam e o que você pode esperar
Os incidentes graves tendem a concentrar-se em regiões muito utilizadas (como a Costa Leste dos EUA) e O impacto é sentido nas cadeias: armazenamento, computação, bancos de dados ou DNSNão é incomum ver serviços como S3, EC2, RDS, Route 53 ou Kinesis listados entre aqueles afetados por picos de erros.
Nessas janelas, empresas de streaming, ferramentas de colaboração, comércio eletrônico ou aplicativos móveis podem apresentar latência, erros de autenticação e falhas intermitentes. O padrão é irregular: funciona para alguns usuários, não para outros., de acordo com rotas, pontos de presença e regiões ativas.
Os canais oficiais geralmente publicam atualizações regulares: Identificação preliminar da causa (por exemplo, problemas de resolução de DNS em uma API), implantação de mitigações e recomendações de nova tentativaÀ medida que a recuperação avança, os erros diminuem e o tráfego retorna ao normal.
Em certos países ou setores, você verá manchetes sobre serviços específicos afetados. Plataformas como Netflix, Disney+, Slack, bancos ou aplicativos muito populares podem ser afetados quando a região da qual dependem sofre, e até mesmo empresas na América Latina (como iFood, Mercado Livre ou PicPay em incidentes anteriores) sentiram o tremor.
Impacto econômico e de reputação de uma queda
Além do lado técnico, uma indisponibilidade na nuvem tem um custo real: Perdas por minuto, suporte sobrecarregado, clientes frustrados e pressão da mídiaO efeito de rede é amplificado pela centralização de certos pilares da Internet.
As organizações que operam serviços críticos sabem disso muito bem: Se os fracassos se repetem, a confiança é corroída e recuperar a imagem da marca custa mais do que o próprio reparo técnico.
Essas crises trazem à mesa uma lição óbvia, mas desconfortável: dependemos fortemente de infraestruturas partilhadasProjetar para resiliência e suposições realistas de falhas não é mais opcional.
Estratégias para ser mais resiliente ao próximo incidente
Se o seu negócio não puder ser fechado, existem táticas que reduzem o risco operacional. Considere uma arquitetura multirregional para distribuir a carga entre diferentes zonas da AWS. e evitar um único ponto de falha geográfica.
Quando o caso de uso justificar, avalie a multinuvem. Distribuir a funcionalidade principal para outro provedor (Azure, GCP) oferece uma rede de segurança., embora envolva maior complexidade e custos de coordenação.
Na camada de entrega, uma CDN bem configurada ajuda a resistir a tempestades. Serviços como o CloudFront ou alternativas como o Cloudflare permitem que você forneça conteúdo estático mesmo que sua origem esteja falhando., dando um descanso aos usuários e sistemas.
Nada disso funciona sem organização: Defina um plano de resposta a incidentes com funções, canais, escalonamento e comunicação externaEm momentos difíceis, a clareza economiza minutos preciosos.
Melhores práticas para verificar o status da AWS sem se perder
Centraliza la observabilidad: Use o AWS Health Dashboard para contexto de plataforma e o CloudWatch para métricas operacionaisEssa abordagem dupla evita que você seja surpreendido por qualquer camada.
Com certificados, automatize. Monitore o RenewalStatus no ACM e reaja aos alertas crescentes do painel de saúde para não chegar ao prazo de validade com o pé esquerdo.
Defina alarmes nas principais métricas do EC2. StatusCheckFailed_System, StatusCheckFailed_Instance e StatusCheckFailed_AttachedEBS são essenciais, associado a ações de recuperação, reinicialização, failover ou substituição via Auto Scaling, de acordo com seu SLA.
E se o console resistir, lembre-se da lista de verificação: Verifique os eventos de saúde na região correta, limpe o cache e os cookies, altere o navegador e confirme com o departamento de TI se os domínios da AWS não estão bloqueados. Essas verificações simples resolvem mais do que você imagina.
Recursos relacionados e ajuda de conta
Para expandir e fortalecer suas operações, revise a documentação dos serviços envolvidos. AWS Health e EventBridge para roteamento de eventos, ACM para renovações e a referência CloudWatch/EC2 para métricas e ações., formam um kit poderoso.
- Painel de integridade da AWS: Visibilidade de eventos públicos e específicos da conta, sem necessidade de configuração adicional.
- Amazon Event Bridge: Ingestão confiável de eventos de saúde com regras flexíveis para roteamento para vários destinos.
- Gerenciador de Certificados AWS (ACM): Acompanhamento do status de renovação e notificações escalonadas antes do vencimento.
- Amazon EC2 + CloudWatch: Verificações por minuto, métricas de status e alarmes que acionam respostas automáticas.
Se você tiver dúvidas sobre como acessar ou gerenciar sua conta, consulte os artigos de suporte mais comuns: Como criar e ativar uma nova conta, como fazer login no console e como solicitar ajuda com sua conta e recursos.. Localizá-los acelera o processo quando algo não se encaixa.
Olhar para um único painel nunca conta toda a história: Verificar a integridade da AWS requer a combinação do contexto do Health Dashboard, ingestão confiável com EventBridge, sinais do ACM e verificações do EC2.Com alarmes bem pensados e manuais claros, os diagnósticos chegam mais cedo, as respostas são mais precisas e as operações se tornam muito mais tranquilas, mesmo quando o tráfego aumenta ou há distúrbios regionais.
