A região que os clientes podem deixar mas nem sempre escapar: AWS US-East-1 e o preço da resiliência

Resumo

• O paradoxo da responsabilidade não é saber se a AWS oferece mais de uma região. Ela oferece. O teste é saber se um cliente pode usar essa diversidade durante um incidente no provedor sem ter que recorrer primeiro a planos de controle degradados, caminhos de identidade, APIs de gerenciamento de DNS, sistemas de monitoramento ou canais de suporte. Uma segunda região que existe mas não é provisionada, autenticada, observável ou acessível sem uma modificação de configuração ao vivo é um inventário, não uma resiliência operacional.
• Em 19 e 20 de outubro de 2025, uma condição de corrida latente no sistema automatizado de gerenciamento de DNS do DynamoDB resultou na perda de todos os endereços IP do endpoint regional público em US-Est-1. Três Enactors DNS operando independentemente em três zonas de disponibilidade não contiveram a falha porque compartilhavam uma sequência de plano regional e uma lógica de limpeza. A automação entrou em um estado inconsistente e exigiu reparo manual.
• A restauração da resolução do endpoint do DynamoDB após cerca de três horas não restaurou a região. O sistema de gerenciamento de hosts do EC2 havia perdido leases e entrado em um colapso por congestionamento; a propagação do estado da rede acumulou um backlog; as verificações de saúde do Network Load Balancer removeram a capacidade saudável cuja configuração não havia chegado; e os serviços dependentes limitaram, falharam ou esvaziaram filas por muitas horas ainda. A AWS descreveu três períodos principais de impacto ao cliente, com a recuperação de alguns Redshift continuando até 21 de outubro.
• O evento não significou que cada máquina da US-Est-1 falhou. As instâncias EC2 existentes permaneceram saudáveis, e alguns planos de dados provisionados estaticamente continuaram a servir. A falha, em vez disso, prejudicou a capacidade de encontrar o DynamoDB, iniciar ou configurar em rede novas capacidades, processar eventos, autenticar certas requisições, substituir componentes com falha e operar as funções de suporte e centro de contato. Essa distinção explica tanto por que alguns clientes sobreviveram quanto por que os designs convencionais de auto scaling falharam mais tarde sob a carga diurna.
• Os registros do setor público concretizam a consequência de continuidade sem apoiar as alegações de uma falha governamental universal. A NOAA declarou que praticamente todos os produtos NESDIS foram afetados e atrasados, não perdidos. O USPTO relatou interrupções intermitentes do Patent Center e orientou os depositantes para outros métodos. Uma plataforma científica da NASA alertou que a alocação de notebooks poderia expirar. Cada caso mostra uma exigência de continuidade diferente: preservar produtos sensíveis ao fator tempo, preservar vias de depósito legais ou preservar o acesso a recursos computacionais alternativos.
• A AWS controla os internos dos serviços gerenciados, a arquitetura dos serviços globais, os algoritmos de recuperação, a publicação de status e as evidências de correção. Os clientes e fornecedores de software downstream controlam o posicionamento das cargas de trabalho, o pré-provisionamento, o mapeamento de dependências, os modos degradados, o monitoramento independente e os procedimentos de continuidade. Os órgãos públicos também controlam a classificação de missão, os requisitos de aquisição e o fallback não digital. A responsabilidade compartilhada não é uma responsabilidade igual: ela segue quem poderia modificar a capacidade com falha antes do evento.

Um produto regional com um problema de fuga não regional

A proposta de venda da nuvem baseia-se em domínios de falha selecionáveis. Um cliente pode distribuir uma aplicação entre zonas de disponibilidade dentro de uma região, replicar dados para outra região e pagar por uma cópia warm ou ativa em outro local. Em teoria, isso torna a resiliência uma propriedade adquirível. Na prática, a compra só se torna real quando o cliente pode exercê-la enquanto o ambiente principal está degradado.

É aqui que começa o paradoxo do plano de controle. Um servidor já em execução pode continuar processando enquanto a API usada para descrevê-lo ou substituí-lo está indisponível. Um registro DNS pode continuar respondendo enquanto a API usada para modificá-lo está fora do ar. Uma réplica em outra região pode estar saudável enquanto a aplicação ainda envia cada requisição para o endpoint regional com falha. Um serviço de suporte pode fazer failover para outra região e ainda assim rejeitar usuários porque uma dependência de metadados de conta retorna uma resposta com aparência autoritativa, mas inválida.

As próprias diretrizes de isolamento de falhas da AWS sobre serviços globais são excepcionalmente explícitas sobre isso. Na partição comercial padrão, IAM, AWS Organizations, Account Management, Route 53 Public DNS, CloudFront e vários planos de controle relacionados são hospedados em uma única região, geralmente US-Est-1. Seus planos de dados podem ser distribuídos globalmente, e essa separação pode preservar o serviço estabelecido.

Mas as diretrizes dizem aos clientes para não confiarem nesses planos de controle durante a recuperação e listam operações em serviços que, de outra forma, são regionais e que ainda dependem do Route 53 ou de outras funções de controle de região única.

Portanto, a boa pergunta de responsabilidade não é: 'O cliente comprou uma segunda região?' É:O cliente conseguia entrar, observar, autorizar, rotear e operar a segunda região usando caminhos já ativos e que não exigissem a autoridade degradada?

Este teste é mais rigoroso do que os diagramas de arquitetura. Ele pergunta se a capacidade foi pré-provisionada; se os dados estavam suficientemente atualizados; se as credenciais e políticas de confiança funcionavam; se o controle de failover era uma ação do plano de dados; se a equipe dispunha de comunicações independentes; se as evidências de status vinham de fora do provedor; e se o serviço público por trás do sistema podia tolerar a transição. Ele também pergunta se a AWS manteve seus próprios sistemas de recuperação e informação ao cliente fora da falha que tentava explicar.

Outubro de 2025 forneceu uma resposta detalhada. Algumas partes funcionaram exatamente como a teoria da estabilidade estática prevê. As instâncias EC2 existentes permaneceram disponíveis. As réplicas de tabelas globais do DynamoDB em outras regiões podiam ser contatadas diretamente.

Outras partes expuseram o preço das dependências de controle ocultas: o endpoint do banco de dados regional desapareceu, os leases de hosts expiraram, a capacidade não pôde ser iniciada, as novas instâncias careciam de estado de rede, as verificações de saúde removeram a capacidade do balanceador de carga utilizável, e o acesso ao suporte foi bloqueado apesar do failover regional.

O relógio de outubro de 2025 continha três falhas

O resumo pós-evento da AWS data o evento de 23h48 PT em 19 de outubro a 14h20 em 20 de outubro e separa três períodos: erros de API do DynamoDB, falhas de inicialização e conectividade do EC2, e erros de conexão do Network Load Balancer. Isso é mais preciso do que atribuir ao evento um início e um fim. Diferentes serviços, caminhos de controle e backlogs de clientes se recuperaram em ritmos diferentes.

Medidas externas ajudam a testar o limite do relato do provedor. A análise da falha da Cisco ThousandEyes observou perda de pacotes precoce na borda da AWS perto de Ashburn, seguida mais tarde por timeouts de aplicação e respostas 503 à medida que a falha atravessava as fases de recuperação. Essas observações não podem revelar os internos proprietários, mas apoiam a conclusão de que a alcançabilidade da rede e a disponibilidade da aplicação se recuperaram em momentos diferentes.

Os históricos de eventos públicos da AWS permanecem úteis como um registro de comunicação contemporâneo. Não deve ser tratado como um relatório forense completo. Um histórico de status relata o que o provedor sabia e escolheu publicar em um dado momento; o relatório pós-evento adiciona mecanismos e reconciliação posterior.

A linha do tempo também mostra por que 'DNS foi reparado' é uma declaração de recuperação inadequada. A reparação do DNS restaurou uma rota para o DynamoDB. Ela não restaurou os leases que haviam expirado, as atualizações de rede que haviam se acumulado, as instâncias que não haviam sido criadas, as entregas de eventos que haviam sido limitadas, as sessões do centro de contato que haviam falhado ou os processos do cliente que haviam expirado. A duração da recuperação foi a soma das transições de estado dependentes, não a duração do primeiro defeito.

O gatilho foi DNS; a raiz foi uma autoridade compartilhada sobre o estado

O mecanismo iniciador foi preciso. O DynamoDB mantém centenas de milhares de registros DNS para uma grande frota regional de balanceadores de carga. Um planejador DNS cria planos descrevendo endpoints, balanceadores de carga e pesos. Os Enactors DNS, operando independentemente em três zonas de disponibilidade, aplicam esses planos através do Route 53. Antes de agir, um Enactor verifica se seu plano é mais recente do que o já aplicado.

Um Enactor tornou-se excepcionalmente lento e tentou novamente as atualizações em vários endpoints. Enquanto progredia, o planejador gerou planos mais recentes e outro Enactor aplicou rapidamente um deles. O Enactor mais recente começou então a limpar os planos antigos. Nesse momento, o Enactor atrasado atingiu o endpoint regional principal do DynamoDB e aplicou seu plano mais antigo. Sua verificação de atualidade havia ocorrido muito antes e agora estava obsoleta. A limpeza removeu o plano antigo que acabara de se tornar ativo.

Todos os endereços IP do endpoint desapareceram, e o estado da automação tornou-se suficientemente inconsistente para que os planos posteriores não pudessem ser aplicados.

'Um erro de DNS' descreve o gatilho visível pelo cliente. Isso não explica a falha de controle. As condições mais profundas eram:

• a atualidade era verificada uma vez no início de uma operação de múltiplos endpoints, em vez de atomicamente a cada gravação decisiva;
• um plano mais antigo poderia sobrescrever uma geração mais recente após um atraso prolongado;
• a limpeza podia remover um plano sem provar que ele não estava mais ativo;
• os workers independentes em zonas separadas compartilhavam as mesmas suposições de ordenação e exclusão;
• um plano regional simplificava o gerenciamento para vários tipos de endpoint, aumentando a autoridade anexada ao plano;
• o estado inválido estava fora do envelope de auto-reparação da automação e exigia um humano para restaurá-lo.

Esta distinção importa porque adicionar um quarto Enactor não resolveria necessariamente um defeito de protocolo compartilhado por todos os Enactors. As zonas de disponibilidade separavam os processos e a infraestrutura; elas não criaram uma correção independente. A redundância multiplicou os atores executando a mesma transição perigosa.

Os compromissos de correção da AWS seguem este diagnóstico. A empresa desativou a automação do planejador e do Enactor em todo o mundo enquanto aguarda modificações, comprometeu-se a corrigir a condição de corrida e a evitar a aplicação de planos incorretos, propôs um limitador de taxa sobre a capacidade que um NLB pode remover durante o failover de zona de disponibilidade, adicionou testes de recuperação do EC2 e prometeu limitação de taxa ciente de filas para a propagação do estado da rede. Essas são medidas mais fortes do que simplesmente expandir a capacidade porque restringem a autoridade e a velocidade de recuperação.

Estes ainda são compromissos em um relatório escrito pelo provedor. Os registros públicos examinados aqui não contêm um registro de encerramento auditado independentemente mostrando a data de implantação, a cobertura de testes, os casos de teste com falha, as exceções restantes e o desempenho sustentado de cada ação. A confiança na narrativa causal pode ser alta enquanto a confiança na eficácia atual da correção permanece menor.

Um servidor saudável não era um serviço recuperável

A AWS corretamente enfatizou que as instâncias EC2 iniciadas antes do evento permaneceram saudáveis. Esse fato impede que a análise escorregue para a afirmação imprecisa de que a US-Est-1 está fisicamente offline. Ele também expõe o risco exato que os clientes estavam comprando.

A AWS define os planos de controle como os sistemas que criam, descrevem, atualizam, excluem e listam recursos, enquanto os planos de dados realizam o trabalho principal do serviço. Suas diretrizes sobre planos de controle e planos de dados explicam por que iniciar uma instância EC2 é uma orquestração complexa envolvendo hosts, interfaces de rede, armazenamento, credenciais e configuração de segurança. A instância em execução é mais simples. Ela pode sobreviver a um período em que essa orquestração não pode criar uma nova.

Esta é a estabilidade estática na prática. Um serviço sobrevive porque não precisa mudar. A fraqueza aparece quando a demanda aumenta, um host falha, uma implantação substitui capacidade, um certificado ou segredo precisa ser renovado, um contêiner termina ou um operador tenta um failover. Então o serviço supostamente estável chama o plano de controle no momento menos indulgente.

A revisão pós-incidente da Buildkite ilustra a falha tardia. A experiência do cliente estava inicialmente estável. À medida que o tráfego comercial americano aumentava, as falhas de inicialização do EC2 impediam o auto scaling, os shards esgotavam suas margens de capacidade diferentes, e a latência e os erros aumentavam horas após o início do incidente da AWS. A Buildkite preservou a capacidade pausando implantações e depois moveu a carga para um shard não utilizado de outra forma. O ativo de resiliência decisivo era a capacidade de computação de reserva já em execução, não a existência de uma política de auto scaling.

A Postman documentou uma segunda forma de acoplamento. Sua revisão de falha indica que os fluxos críticos foram degradados, sua página de status hospedada na AWS atrasou a comunicação, e a criação automatizada de canais de incidente internos dependia de infraestrutura afetada. A Postman aceitou sua própria parcela de responsabilidade e descreveu o trabalho em degradação graciosa, capacidade multi-região, comunicações redundantes e, finalmente, operação ativo-ativo entre regiões e provedores. Esta é a repartição correta: a AWS possui a falha upstream; a Postman possui a decisão de deixar a comunicação e coordenação do cliente herdá-la.

O evento de outubro divide, portanto, as arquiteturas dos clientes em categorias mais úteis do que 'mono-região' e 'multi-região':

1. Em execução, mas dependente de alterações.O serviço existente continua até que o escalonamento, substituição, implantação ou renovação de credenciais exija uma atividade de controle.
2. Multi-zona, mas dependente de controle regional.As falhas de zona física são cobertas, enquanto endpoints regionais compartilhados, planos de controle e sistemas de recuperação permanecem comuns.
3. Multi-região, mas dependente de ativação.Os dados e modelos existem em outro lugar, mas o failover exige provisionamento, alterações no IAM, alterações no Route 53 ou operadores indisponíveis.
4. Multi-região estaticamente estável.A capacidade, caminhos de dados, identidades, verificações de saúde e controles de roteamento já estão disponíveis, com failover usando mecanismos de plano de dados pré-posicionados.
5. Multi-provedor ou manualmente contínuo.Um subconjunto crítico pode operar fora da AWS, ou a função pública continua através de um processo não digital limitado quando a operação em nuvem não é econômica.

Apenas a quarta e quinta categorias respondem diretamente ao paradoxo do plano de controle. As outras ainda podem ser escolhas racionais para cargas de trabalho de menor impacto, mas não devem ser apresentadas como resiliência equivalente.

A automação de recuperação tornou-se o segundo incidente

Uma vez que o DNS do DynamoDB foi restabelecido, o DropletWorkflow Manager do EC2 tentou restabelecer os leases com os hosts físicos que gerenciava. Durante a falha do endpoint, esses leases haviam expirado. Um host sem lease ativo não podia aceitar com segurança uma nova instância. As tentativas da frota levaram tempo suficiente para que o trabalho expirasse e fosse enfileirado novamente. A AWS afirma que o sistema entrou em um colapso por congestionamento e não tinha um procedimento estabelecido para esse estado de recuperação.

Esta é uma admissão importante. A condição de corrida inicial foi uma rara falha de ordenação. A degradação prolongada do EC2 veio de uma classe previsível de carga de recuperação: muitos objetos expirados tentando se tornar atuais juntos. A escala exata pode ter sido excepcional, mas filas, timeouts, tentativas e leases são mecanismos comuns de sistemas distribuídos. Um design de recuperação deve ser testado no tamanho da frota que se espera restaurar, não apenas para desempenho em regime permanente ou perda gradual de hosts.

A fase seguinte tornou a dependência visível para o tráfego em andamento. O Network Manager precisava propagar um backlog de configuração para instâncias novas ou modificadas. Algumas novas instâncias existiam antes de seu estado de rede estar completo. As verificações de saúde do NLB viram falhas, alternaram entre saudável e não saudável, e removeram nós e alvos do DNS. O próprio sistema de controle tornou-se carregado, e o failover automático de zona de disponibilidade removeu a capacidade de balanceadores de carga multi-zona. A AWS desativou a proteção automática às 9h36 para impedi-la de agir sobre evidências enganosas.

Nenhum componente único se comportou irracionalmente isoladamente. O gerenciamento de leases recusou hosts não possuídos. O Network Manager enfileirou a configuração. As verificações de saúde removeram alvos inacessíveis. O failover de zona de disponibilidade removeu capacidade degradada. A cascata surgiu porque cada mecanismo interpretou a recuperação parcial como uma falha local comum. A responsabilidade reside no design entre sistemas: o estado de recuperação deve ser suficientemente bem representado para que um controle de segurança não puna outro sistema por estar temporariamente incompleto.

Os efeitos downstream eram específicos do serviço. O Lambda limitou o trabalho assíncrono e orientado por fila para proteger a invocação síncrona. ECS, EKS e Fargate experimentaram falhas de inicialização e escalonamento. O Amazon Connect viu chamadas de entrada e saída falharem, tons de ocupado, silêncio, falhas de mensagens de áudio e roteamento de chamadas, problemas de conexão da equipe do centro de contato e relatórios atrasados. O STS experimentou dois períodos de altos erros. O Redshift tinha tanto uma dependência regional quanto um defeito que enviava uma requisição de resolução de grupo IAM para a US-Est-1 de todas as regiões;

os usuários de banco de dados locais não foram afetados por essa falha inter-regional em particular.

Este detalhe sobre o Redshift é particularmente revelador. Um recurso pode estar fisicamente localizado fora da US-Est-1 e ainda chamar um endpoint lá devido a uma escolha de implementação. A implantação geográfica e a geografia das dependências não são idênticas. Os clientes precisam do segundo mapa, mas apenas o provedor pode divulgar autoritativamente cada dependência entre serviços interna.

O status e o suporte fazem parte do sistema de segurança

Durante um incidente na nuvem, os clientes precisam decidir se veem seu próprio defeito, uma restrição específica da conta, um evento regional ou uma dependência global. Eles precisam saber se devem fazer failover, congelar implantações, reduzir carga, preservar filas ou invocar continuidade manual. A informação de status é, portanto, um controle operacional, não relações públicas posteriores.

Em outubro de 2025, o centro de suporte da AWS fez failover para outra região. No entanto, um subsistema de metadados de conta retornou respostas que bloquearam usuários legítimos de visualizar ou atualizar os registros. A AWS havia projetado uma solução alternativa para respostas com falha; a dependência retornou respostas inválidas. Das 23h48 às 2h40, os clientes não podiam criar, visualizar ou atualizar registros de suporte através do console ou API.

Este é um problema clássico de falha semântica. Uma dependência pode estar indisponível, lenta, errada, desatualizada ou confiantemente errada. A lógica de failover que lida apenas com um timeout não é independente de um sistema que retorna uma autoridade errada. A continuidade do suporte deve validar o significado do estado da conta, preservar um caminho limitado de último conhecido bom e oferecer uma rota autenticada separadamente para eventos graves do provedor.

Os registros mostram tanto melhoria quanto recorrência. Durante o evento de serviço AWS de 7 de dezembro de 2021, o congestionamento entre as redes principal e interna da AWS degradou o monitoramento, as ferramentas de implantação, os planos de controle, o centro de contato de suporte e o failover do dashboard de status do serviço para uma região de backup. A AWS prometeu uma nova arquitetura de suporte ativa em múltiplas regiões. O centro de suporte de 2025 mudou de região como projetado, o que é uma evidência de progresso arquitetônico. Sua dependência de metadados ainda impediu o serviço de cumprir seu propósito.

Os clientes também devem distinguir o status público da AWS de evidências personalizadas. A documentação atual do dashboard de status AWS indica que a página pública não autenticada mostra eventos de serviço públicos, enquanto as visualizações conectadas fornecem eventos e recursos específicos da conta. A AWS recomenda monitoramento programático via EventBridge. Suas diretrizes para eventos de status públicos e específicos da conta recomendam uma regra de backup para que os eventos possam ser entregues a uma região alternativa.

As diretrizes regionais de regras de eventos da AWS indicam que eventos de status globais como notificações IAM exigem uma regra na US-Est-1, outra razão para testar em vez de assumir independência.

Nenhuma organização deve depender de um único canal. Um arranjo defensável combina o status público do provedor, eventos específicos da conta entregues em mais de uma região, sondas sintéticas de outro provedor ou rede on-premises, métricas de negócio no nível da aplicação e uma página de incidente com hospedagem e identidade independentes. As listas de contato, detalhes de ponte e limites de decisão devem ser recuperáveis sem a conta cloud comum.

O impacto nos serviços públicos foi um problema de continuidade, não um contador de sites

A interrupção de outubro atingiu sistemas públicos de uma forma que torna os totais simples de falhas enganosos. As melhores evidências são específicas do serviço.

A Administração Nacional Oceânica e Atmosférica (NOAA) relatou que suas instalações cloud dos Centros Nacionais de Informação Ambiental começaram a receber alertas de baixa ingestão por volta das 06h57 UTC. Uma mensagem operacional NOAA/NESDIS indicou que praticamente todos os produtos NESDIS foram afetados e que os dados pareciam atrasados, não perdidos. Esta é uma consequência materialmente diferente da destruição permanente de dados. Ainda pode ser grave: os produtos ambientais são sensíveis ao fator tempo, e um atraso de seis horas pode comprimir o tempo disponível para usar as observações em previsões, planejamento ou análise downstream.

O Escritório de Patentes e Marcas dos Estados Unidos (USPTO) indicou que seu Patent Center experimentou interrupções intermitentes e orientou os usuários incapazes de enviar depósitos para outros métodos de depósito. Este aviso demonstra um princípio de continuidade maduro: a função legal ou administrativa é o depósito, não a disponibilidade de uma aplicação web. Uma rota alternativa preserva a função mesmo quando a interface principal está degradada. Os registros não estabelecem quantos usuários invocaram a alternativa, se cada depósito cumpriu seu prazo, ou por que o incidente não foi marcado como resolvido antes de 23 de outubro;

essas questões devem permanecer abertas.

A plataforma científica Fornax da NASA alertou que iniciar um servidor de notebook poderia expirar durante a alocação de recursos computacionais. Isso corresponde diretamente à falha do plano de controle do EC2. Os dados científicos ou notebooks existentes não desapareceram necessariamente para que a pesquisa parasse; a incapacidade de alocar um ambiente de trabalho é suficiente.

Esses registros não provam que todos os serviços governamentais usando a AWS foram afetados, que chamadas de emergência falharam devido a este evento, ou que um resultado de segurança pública ocorreu. Eles mostram por que a aquisição deve olhar além de onde os dados estão armazenados. Um serviço público pode depender da nuvem para geração de produtos, depósito, análise, comunicações ou computação necessária para examinar dados.

O documento de agosto de 2024 da CISA sobre dependências de comunicações de segurança pública alerta que a infraestrutura não governamental pode apresentar risco de continuidade correlacionado e recomenda redundância explícita, procedimentos de falha, backups, pessoal e requisitos de suporte. O guia de dependências de infraestrutura da CISA pergunta se um provedor redundante também é compartilhado por outros sistemas e por quanto tempo uma solução alternativa pode ser mantida. Essas perguntas se aplicam exatamente à arquitetura cloud.

Um órgão público deve classificar a continuidade no nível da missão:

• Que resultado ainda precisa ser produzido se o controle da nuvem estiver indisponível por três, quinze ou quarenta e oito horas?
• Que trabalho pode continuar na capacidade já em execução, e que margem de demanda existe?
• Quais registros podem ser atrasados, e que prazos legais ou de segurança exigem uma via alternativa?
• A equipe consegue se autenticar, comunicar e publicar avisos públicos sem o provedor afetado?
• Uma segunda região está realmente ativa, ou a organização precisa provisioná-la através do plano de controle com falha?
• Um processo manual pode aceitar trabalho, criar um recibo com timestamp e reconciliá-lo posteriormente sem perder integridade?
• O contrato fornece evidências técnicas e vias de suporte, não apenas créditos após o evento?

As diretrizes de planejamento de contingência do NIST permanecem relevantes porque focam no impacto nos negócios, prioridades de recuperação, processamento alternativo e planos testados. A tecnologia mudou; o dever de preservar a função pública não mudou.

US-Est-1 tem um histórico, não um bug recorrente

Seria enganoso descrever cada evento no Norte da Virgínia como o mesmo defeito de plano de controle. Os mecanismos diferem. O valor do histórico é que diferentes gatilhos expuseram repetidamente questões comuns sobre escopo, dependência interna, velocidade de recuperação e visibilidade do cliente.

O resumo de serviço de 2012 é uma declaração inicial do paradoxo: os planos de controle são particularmente importantes durante uma falha porque é quando os clientes tentam criar ou mover recursos. O relatório S3 de 2017 mostrou um comando operacional com mais autoridade do que o pretendido e durações de reinicialização que não haviam sido experimentadas na escala mais recente da região. O relatório Kinesis de 2020 separou explicitamente o gatilho da causa raiz e depois descreveu uma reinicialização controlada da frota de várias horas e uma dependência da ferramenta de status.

O relatório de 2021 expôs a visibilidade reduzida do provedor e a degradação da implantação.

O padrão recorrente não é negligência de um operador nomeado, nem prova que a AWS não aprendeu. É que a escala muda o significado de uma operação segura; componentes redundantes podem compartilhar uma falha lógica; a demanda de recuperação pode ser maior do que a demanda em regime permanente; e as ferramentas de incidente podem compartilhar o destino com a produção. Cada ação pós-evento deve, portanto, ser testada contra o próximo mecanismo, não apenas o último gatilho exato.

Há evidências de aprendizado. O centro de suporte de 2025 tinha failover regional onde a arquitetura de 2021 não protegia a criação de registros. O DynamoDB usava três Enactors DNS independentes. O EC2 preservou instâncias existentes. As réplicas de tabelas globais permaneceram endereçáveis em outro lugar. A AWS publicou um relatório causal excepcionalmente detalhado. A questão restante é se esses controles falham de forma segura quando recebem um estado lento, desatualizado ou inválido, em vez de uma falha limpa.

O que pode realmente ser comprado em resiliência

O pilar de confiabilidade atual da AWS diz aos clientes para definirem objetivos de recuperação, testarem a recuperação de desastres, realizarem dias de exercício, usarem estabilidade estática e confiarem nos planos de dados durante a recuperação. As diretrizes específicas REL11-BP04 identificam antipadrões comuns: modificar registros DNS durante um incidente, dimensionar a capacidade do plano de controle porque os recursos de failover estavam sub-provisionados, ou depender de uma cadeia de APIs de gerenciamento.

Essas diretrizes são tecnicamente sólidas. Elas também definem a conta. A estabilidade estática significa pagar por recursos antes que sejam necessários, restringir implantações que removeriam capacidade de reserva, manter identidades e dados prontos em outra região, e operar um controle de roteamento cujo plano de dados já está distribuído. Um cliente que paga apenas por backups comprou proteção de dados, não continuidade imediata de serviço. Um cliente com uma warm standby comprou reconstrução mais rápida, não imunidade a falhas de plano de controle.

Um cliente com uma active standby comprou capacidade com dependência de escalonamento, a menos que a standby possa suportar a carga prometida conforme provisionada.

As opções de recuperação de desastres da AWS descrevem backup e restauração, warm standby, active standby e modelos ativo-ativo. Elas também aconselham usar apenas operações do plano de dados para máxima resiliência. A implicação deve ser escrita nos casos de negócio: um custo menor geralmente compra mais trabalho do plano de controle no momento da falha. O proprietário da carga de trabalho deve decidir se essa troca é aceitável, e os líderes devem financiar a resposta que corresponde à tolerância de impacto que aprovaram.

Multi-região não é um veredito automático. As réplicas de tabelas globais do DynamoDB fora da US-Est-1 estavam disponíveis durante o evento de 2025, mas as aplicações ainda precisavam de um caminho testado até elas, um comportamento de consistência aceitável, capacidade adequada e uma maneira de reconciliar a réplica recuperada. Políticas de identidade, chaves KMS, segredos, certificados, imagens de contêiner, filas, observabilidade e APIs de terceiros todos requerem a mesma revisão. Um diagrama com dois ícones de banco de dados não prova que uma transação comercial completa pode terminar em ambos os locais.

Multi-cloud também não é um veredito automático. Reconstruir cada serviço gerenciado contra um segundo provedor pode introduzir inconsistência de dados, erros operacionais, custos mais altos e uma plataforma que é exercida apenas durante emergências. A revisão mais recente do GAO sobre aquisição federal de nuvem constatou que agências usando múltiplos provedores também enfrentavam desafios de interoperabilidade, pessoal, ferramentas e gerenciamento.

O relatório registra a formulação mais útil oferecida pelo Departamento de Defesa: gerenciar o risco de concentração e manter consciência arquitetônica e uma estratégia de saída para cargas de trabalho críticas, em vez de tratar qualquer capacidade específica do provedor como intrinsecamente ruim.

A resposta prática é a independência seletiva. Mantenha o caminho mais crítico em termos de tempo estaticamente estável entre regiões. Preserve um pequeno modo somente leitura ou de captura de entrada quando o serviço completo for muito caro. Use formatos de dados abertos e exportações testadas para funções que podem exigir outro provedor. Mantenha um processo manual ou offline onde obrigações legais e públicas permitirem. Não gaste um orçamento de resiliência igual para uma página de informações públicas, uma instrução de pagamento de benefícios, um trabalho de análise interna e uma função de despacho de segurança;

suas consequências diferem.

A responsabilidade segue a capacidade que poderia ter alterado o resultado

'Responsabilidade compartilhada' pode se tornar uma névoa se usada para dividir cada falha igualmente. O próprio modelo de resiliência da AWS atribui a resiliência da infraestrutura cloud e dos serviços gerenciados à AWS, enquanto os clientes escolhem a configuração, posicionamento, replicação, backup e arquitetura da carga de trabalho. A divisão só é útil quando traduzida em capacidades de controle concretas.

Essa repartição evita dois erros. Os clientes não podem corrigir o Enactor DNS do DynamoDB nem criar um procedimento de recuperação EC2 dentro da AWS. A AWS não pode decidir se um portal de depósito municipal merece operação ativo-ativo ou se uma agência pública tem um processo de entrada manual aceitável. Uma empresa SaaS downstream não pode culpar a AWS por hospedar sua própria página de status no mesmo domínio de falha, mas também não pode descobrir os internos não divulgados do provedor apenas por disciplina arquitetônica.

A responsabilidade também muda com a abstração do serviço. Um cliente gerenciando EC2 tem mais escolhas e mais trabalho. Um cliente comprando DynamoDB delega mais operações de plataforma e deve esperar que a AWS gerencie o DNS interno do serviço e a recuperação corretamente. O cliente ainda controla a replicação e o failover da aplicação. O serviço gerenciado não elimina o dever de continuidade do cliente; ele reduz os internos que o cliente pode controlar e aumenta o dever do provedor de divulgar limites de falha utilizáveis.

Os créditos precificam uma métrica de serviço, não a consequência pública

A responsabilidade comercial tem uma camada contratual estreita e uma camada operacional mais ampla. O SLA atual do DynamoDB compromete-se com níveis de disponibilidade regionais mensais, com um objetivo mais alto para uso qualificante de tabelas globais. O recurso indicado é geralmente um crédito de serviço, sujeito a elegibilidade, cálculos, exclusões, logs e uma reclamação apresentada através do suporte AWS.

Esse mecanismo pode impor um compromisso de serviço mensurável. Ele não reembolsa o custo total de produtos ambientais atrasados, trabalho de desenvolvimento perdido, chamadas de clientes com falha, transações downstream perdidas ou pessoal público desviado para processamento manual. Um SLA também não determina se um cliente em particular projetou de forma responsável. Os termos contratuais variam, e esta análise não conclui que a AWS deve danos a um cliente além de um acordo aplicável.

O evento de 2025 expõe uma ironia processual sem provar um defeito legal: o processo de crédito padrão usa o centro de suporte, enquanto as funções de registro de suporte estavam indisponíveis durante a fase inicial do DynamoDB. Os clientes tinham janelas de reclamação posteriores, então o bloqueio temporário não impediu necessariamente uma reclamação. Isso mostra por que as evidências necessárias para um crédito devem ser coletadas fora da pilha de monitoramento afetada.

CloudWatch, logs de aplicação, sondas sintéticas, eventos do provedor, registros de transações do cliente e notas manuais de incidente devem ser mantidos de forma independente.

A escala do provedor aumenta a expectativa de governança. O Formulário 10-K 2025 da Amazon reporta vendas líquidas da AWS de US$ 128,725 bilhões, um aumento de 20%, e reconhece separadamente riscos relacionados a interrupção do sistema e redundância incompleta. A receita não é prova de culpa. É prova de capacidade, alcance e uma relação econômica na qual os controles de confiabilidade, relatórios pós-evento transparentes e garantia de correção são obrigações centrais do produto, não complementos de caridade.

Que evidências mudariam a conclusão

A conclusão atual é que a AWS forneceu resiliência substancial de infraestrutura e plano de dados, mas que o evento de outubro de 2025 expôs suposições comuns evitáveis na automação DNS regional e caminhos de recuperação insuficientemente preparados. Os clientes podiam comprar resiliência significativa, mas apenas pré-posicionando o serviço e evitando dependências do plano de controle que a própria AWS documenta. Algumas dependências inter-regionais e de suporte permaneceram menos independentes do que os clientes poderiam razoavelmente inferir apenas da geografia.

Vários tipos de evidências tornariam este julgamento mais favorável:

• um registro de encerramento público datado para a correção da condição de corrida DNS, aplicação de atualidade por endpoint, proteção contra exclusão de planos ativos e recuperação automática de um estado de plano inconsistente;
• resultados de injeção de falhas mostrando que Enactors atrasados, gerações obsoletas, limpeza concorrente, gravações parciais do Route 53 e falha de recuperação não podem remover o endpoint regional;
• testes EC2 em escala realista da US-Est-1 mostrando que a reconstrução completa de leases termina em um prazo limitado sem colapso por congestionamento;
• evidências de profundidade de fila e controle de admissão para o Network Manager, incluindo comportamento sob um backlog regional maior que o de outubro;
• testes NLB provando que os limitadores de taxa impedem transições de saúde falsas de remover muita capacidade multi-zona;
• um inventário de dependências de serviço identificando operações de controle globais ou de região única que podem afetar cargas de trabalho fora da US-Est-1, com alterações rastreadas ao longo do tempo;
• exercícios demonstrados de suporte e status AWS nos quais identidade, metadados de conta, console, entrega EventBridge e uma região falham cada um independentemente;
• métricas de recuperação orientadas ao cliente que separam reparo de endpoint, reparo de plano de controle, estabilidade de plano de dados, limpeza de backlog e reconciliação de recursos;
• amostragem de garantia independente da conclusão e sustentabilidade das ações corretivas para incidentes graves.

As evidências também poderiam tornar a conclusão menos favorável. A repetição da mesma condição de corrida após a reativação da automação, outra recuperação de frota sem procedimento estabelecido, chamadas inter-regionais não documentadas para a US-Est-1, ou falha de status e suporte através do mesmo caminho de metadados indicariam que a correção tratou sintomas em vez de limites de autoridade. Uma falha mais curta por si só não resolveria a questão; um padrão de carga de trabalho sortudo pode ocultar um controle perigoso.

As evidências do cliente também importam. Uma agência pública que pode mostrar um dia de exercício regional completo, comunicações independentes, dados atuais em uma região secundária, capacidade pré-provisionada, serviço manual limitado e reconciliação bem-sucedida de prazos converteu a diversidade da nuvem em continuidade. Um cliente que rotula backups ou modelos como 'multi-região' sem exercício cronometrado não o fez.

A AWS publica um padrão útil para saber quando publicará resumos públicos pós-evento, incluindo eventos amplos envolvendo falhas significativas do plano de controle ou impacto na infraestrutura. Esses registros são valiosos. Uma garantia mais forte ligaria cada relatório grave a um registro de ações durável, para que clientes e compradores públicos possam distinguir uma correção anunciada de um controle testado, concluído e sustentado.

A conclusão de responsabilidade

A falha de outubro de 2025 começou com duas peças de automação em desacordo sobre o tempo. Uma aplicou lentamente um plano antigo; a outra aplicou um novo plano e removeu o antigo; juntas, elas apagaram o endereço de um serviço de banco de dados regional. O incidente longo veio de tudo que confiava naquele endereço e no estado que se degradou durante sua ausência.

A AWS possui essa cadeia dentro da nuvem. Ela projetou o protocolo de plano, a autoridade de limpeza, os leases de hosts, as filas de recuperação, as verificações de saúde, as dependências de serviço e o caminho de suporte. Seu relatório pós-evento é tecnicamente específico, suas correções imediatas correspondem aos mecanismos divulgados, e sua preservação de instâncias EC2 existentes valida o valor da separação do plano de controle.

A questão de responsabilidade não resolvida é a prova de que as correções funcionam em escala regional e que as dependências inter-regionais ocultas são tornadas suficientemente visíveis para que os clientes possam agir.

Os clientes possuem uma cadeia diferente. Eles decidem se a demanda de pico pode ser atendida pela capacidade em execução, se as réplicas podem ser alcançadas sem uma nova ação de controle, se o status e a coordenação de incidentes são independentes, e se o negócio ou a função pública pode degradar-se com segurança. Os shards esgotados da Buildkite e a rota de status degradada da Postman não foram causas da falha da AWS; foram multiplicadores de impacto controlados pelo cliente.

Os produtos atrasados da NOAA, a via de depósito alternativa do USPTO e o aviso de alocação da NASA mostram por que o multiplicador deve ser avaliado em termos operacionais, não por número de servidores.

O teste central agora pode ser respondido. Os clientes podem comprar resiliência regional na AWS, mas uma segunda região não é prova suficiente da compra. O produto utilizável é um caminho de recuperação completo: já provisionado, já autorizado, já observável, já roteável e praticado sem o plano de controle primário. Onde os controles globais ou os internos do provedor ainda convergem para a US-Est-1, a AWS deve remover a dependência, tornar clara sua alternativa de plano de dados segura, ou afirmar a limitação claramente.

A concentração da nuvem é frequentemente discutida em termos de participação de mercado. A concentração mais imediata é a autoridade executável: um plano, um endpoint, uma resposta de metadados, uma interpretação de saúde ou uma dependência de suporte que pode fazer muitos sistemas redundantes se comportarem da mesma maneira. A responsabilidade começa nomeando essa autoridade antes do próximo incidente e, em seguida, provando que um caminho separado ainda existe quando ela está errada.