Resumo

  • Uma alteração de capacidade de rede em uma Zona de Disponibilidade deslocou tráfego do EBS para uma rede de replicação com menor capacidade; a restauração da conectividade desencadeou buscas simultâneas por réplicas e uma tempestade de reespelhamento.
  • A AWS informou que cerca de 13% dos volumes da zona afetada ficaram presos na estabilização e que 0,07% dos volumes dessa mesma zona não puderam ser restaurados em estado consistente. Os números têm significados distintos e não descrevem toda a região nem toda a base da AWS.
  • A responsabilização não termina quando a causa imediata é removida. Ela inclui capacidade ociosa para recuperação, recuo agressivo, isolamento, redução de carga, visibilidade por recurso e comprovação de que medidas corretivas funcionam.

O perímetro do evento

Às 0h47, horário do Pacífico, em 21 de abril de 2011, uma mudança de capacidade na rede primária do EBS desviou tráfego de forma incorreta para a rede de replicação, de menor capacidade. Segundo o relato técnico da AWS, o problema se concentrou em uma Zona de Disponibilidade da região US East. Houve também períodos delimitados de erros e latência nas APIs do EBS em outras partes da região, mas isso não autoriza descrever o episódio como uma falha global da AWS nem como indisponibilidade uniforme de todos os volumes em US East.

Essa distinção geográfica é importante porque o incidente teve duas superfícies. A primeira foi física e localizada: nós de armazenamento perderam conectividade efetiva com seus pares. A segunda apareceu no plano de controle regional: chamadas demoradas ocuparam recursos compartilhados e espalharam degradação de API além do conjunto de armazenamento diretamente afetado. Misturar as duas superfícies produz uma narrativa mais dramática, porém menos útil para projetar controles.

O registro público também não sustenta um único horário de “fim”. Conter nova degradação, recuperar APIs regionais, restaurar operações na zona afetada, reconstruir réplicas, processar filas acumuladas e concluir casos manuais foram marcos diferentes. O trabalho residual durou dias. Continuidade deve ser medida por esses estados, não por uma declaração binária de que o serviço “voltou”.

Como o EBS de 2011 organizava a redundância

No desenho descrito pela AWS para 2011, os volumes do EBS eram mantidos em clusters de armazenamento contidos em uma Zona de Disponibilidade. Os dados eram replicados entre nós. Uma rede primária de alta largura de banda carregava o fluxo normal, enquanto uma rede secundária, de menor capacidade, servia à replicação. Um plano de controle regional coordenava operações como a criação de volumes.

Essa descrição é histórica. Ela não deve ser projetada sobre a arquitetura atual da AWS, sobre controles atuais nem sobre as opções hoje oferecidas aos clientes. Ainda assim, o modelo revela uma pergunta duradoura: a rota de proteção dispõe de capacidade para absorver um evento simultâneo ou apenas para lidar com falhas esparsas?

Uma réplica oferece tolerância enquanto os componentes permanecem dentro do envelope previsto. Quando muitos pares parecem ausentes ao mesmo tempo, cada nó procura uma nova réplica. Se a política permite que todas essas buscas avancem juntas, a redundância deixa de ser somente reserva de estado e se torna demanda concorrente por rede, armazenamento e coordenação.

Do desvio de tráfego ao isolamento dos nós

A mudança na rede primária enviou tráfego para um caminho que não havia sido dimensionado para essa carga. Muitos nós ficaram isolados tanto da conectividade primária efetiva quanto da comunicação de replicação de que dependiam. O gatilho, portanto, foi a mudança de capacidade executada de forma incorreta. Ele não deve ser confundido com toda a causa do impacto prolongado.

O tamanho do incidente foi determinado pelo que ocorreu depois. Ao recuperar conectividade, vários nós concluíram que precisavam localizar novos parceiros para suas réplicas. A procura simultânea consumiu a capacidade livre. A AWS identificou recuo insuficiente e uma condição de corrida de baixa probabilidade como fatores de amplificação. A análise técnica da InfoQ ajuda a explicar o efeito distribuído, mas os fatos internos continuam ancorados no pós-incidente da operadora.

Essa taxonomia separa quatro elementos. O gatilho foi o desvio incorreto. A condição contribuinte foi a menor capacidade da rede de replicação. O mecanismo de amplificação foi a busca concorrente, com recuo inadequado e condição de corrida. A vulnerabilidade de recuperação foi a falta de capacidade livre suficiente para satisfazer a onda que o próprio sistema gerou. A separação evita transformar o erro inicial em explicação total.

Por que restaurar conectividade piorou o quadro

Sistemas distribuídos podem apresentar um paradoxo: devolver comunicação não encerra necessariamente a falha. Pode liberar uma massa de trabalho represada. Nesse caso, os nós voltaram a se enxergar e tentaram restaurar simultaneamente o nível de replicação esperado. Cada tentativa parecia protetiva isoladamente; em conjunto, elas disputaram os mesmos recursos escassos.

Esse é o núcleo da tempestade de reespelhamento. A capacidade necessária para criar segurança competiu com a capacidade necessária para sair da emergência. Sem limites de concorrência, filas e recuo suficientemente fortes, uma política local razoável pode produzir instabilidade coletiva. A condição de corrida acrescentou novas tentativas em circunstâncias raras, reforçando o ciclo.

Capacidade de recuperação, portanto, não pode ser calculada apenas pela média. Ela precisa considerar quantos componentes podem entrar no mesmo estado, com que velocidade solicitam trabalho, quanto tempo cada operação ocupa e qual carga deve ser preservada para clientes e para o plano de controle. Reserva que existe apenas no papel, mas não pode ser acessada durante uma avalanche de restauração, não constitui controle efetivo.

A propagação pelo plano de controle regional

Chamadas de criação de volume passaram a levar muito tempo. Enquanto permaneciam abertas, ocupavam threads de um conjunto regional do plano de controle. A exaustão desse conjunto provocou erros e latência nas APIs do EBS fora da zona que concentrava o problema de armazenamento. O compartilhamento regional converteu uma falha localizada em uma degradação de coordenação mais ampla.

O ponto de responsabilidade aqui não é exigir que todo recurso compartilhado seja eliminado. É exigir que o compartilhamento seja explícito, limitado e observável. Operações lentas precisam de timeouts coerentes; filas precisam de tetos; cargas degradadas precisam ser rejeitadas ou reduzidas antes de consumir todos os trabalhadores; e uma zona problemática não deve monopolizar a capacidade de controle destinada às demais.

A AWS relatou que o isolamento do cluster degradado e o estrangulamento de chamadas ajudaram a reduzir a carga. Isso mostra que recuperação operacional não foi um único conserto, mas uma sequência de contenção: impedir novas ampliações, proteger o plano de controle, adicionar capacidade física e então restaurar réplicas em etapas.

Recuperação em lotes e capacidade física

A estabilização exigiu acrescentar capacidade e controlar a velocidade da reconstrução. Recuperar em pequenos lotes reduz a chance de outra onda coordenada, mas prolonga a cauda do incidente. Essa troca precisa ser assumida e comunicada. Acelerar indiscriminadamente pode recriar o colapso; desacelerar sem prioridades deixa clientes sem uma expectativa útil.

Quando o cluster foi estabilizado, a AWS informou que aproximadamente 13% dos volumes da Zona de Disponibilidade afetada estavam presos. Esse percentual não é de clientes, de dados, de toda US East nem de todos os volumes da AWS. Ele descreve um estado específico, em um denominador específico. Depois da estabilização ainda havia restauração de réplicas, processamento de backlog e intervenção manual.

A recuperação gradual também exige critérios de priorização. O registro público não detalha toda a fila nem as decisões de precedência. Por isso, não é possível afirmar quais clientes tiveram prioridade ou se algum critério foi inadequado. O que se pode exigir como prática é que as regras sejam definidas antes da crise, auditáveis durante ela e revisáveis depois.

Consistência e o resíduo irrecuperável

A AWS informou que 0,07% dos volumes na Zona de Disponibilidade afetada não puderam ser restaurados em estado consistente. Esse é um resultado final distinto dos cerca de 13% que estavam presos no momento da estabilização. Usar os percentuais como se fossem intercambiáveis apagaria tanto a recuperação bem-sucedida de muitos volumes quanto o dano permanente de uma parcela menor.

O conjunto de fontes não revela quantos clientes foram afetados, quantos bytes ou registros foram perdidos, nem o impacto econômico total. “Volume não restaurado de forma consistente” também não permite deduzir o mesmo resultado para todas as aplicações. Snapshots, cópias mantidas pelo cliente e reconstrução em nível de aplicação podem alterar desfechos, mas não há evidência suficiente aqui para quantificá-los.

O limite probatório é parte da análise de responsabilidade. Métricas operacionais da fornecedora ajudam a delimitar o evento, porém não substituem uma mensuração completa do dano. Da mesma forma, créditos de serviço não provam compensação integral. Sem dados adicionais, não cabe concluir negligência, violação contratual, infração regulatória ou responsabilidade jurídica.

RDS, Multi-AZ e dependências encadeadas

O RDS dependia do EBS para armazenamento de banco de dados e logs. A AWS relatou que uma condição até então não encontrada impediu o failover automático de um subconjunto de instâncias Multi-AZ, exigindo intervenção manual. Isso demonstra que duplicar uma instância não elimina toda dependência de armazenamento nem garante que a automação de transição cubra todos os estados.

É igualmente incorreto concluir que Multi-AZ “não funciona”. O incidente mostra uma condição específica e um subconjunto, não uma falha universal. Instâncias de uma única zona, implantações Multi-AZ, volumes EBS e aplicações externas formam populações diferentes. Seus denominadores e trajetórias de recuperação devem permanecer separados.

Para clientes, a questão não é assumir o controle da infraestrutura da fornecedora. É identificar dependências que atravessam limites aparentes: dados, logs, DNS, credenciais, plano de controle, filas e procedimentos humanos. Arquiteturas multizona ou multirregião podem reduzir certos riscos, mas não são apresentadas pelas fontes como proteção contra todo efeito no plano de controle ou em nível de aplicação.

Evidência de impacto a jusante

A Heroku publicou que sofreu uma interrupção generalizada de aplicações, fornecendo evidência direta de uma operadora de plataforma dependente. A cobertura contemporânea da TechCrunch citou serviços públicos como Reddit, Foursquare e Quora e registrou dificuldades relacionadas ao RDS. Essas fontes demonstram alcance econômico e dependência visível, mas não compõem uma lista completa de vítimas.

Também não provam que todos os serviços tiveram o mesmo caminho de falha, a mesma duração ou o mesmo desfecho de dados. Uma aplicação poderia estar indisponível por armazenamento, por banco de dados, por automação própria ou pela combinação desses fatores. Atribuir cada interrupção ao mesmo mecanismo seria ir além das evidências.

O valor das fontes independentes é justamente diferente do pós-incidente da AWS. Elas confirmam que o efeito não ficou confinado à telemetria interna e mostram como dependências de nuvem chegam ao usuário. Não substituem, porém, o acesso da operadora à arquitetura, aos logs e às decisões de recuperação.

Comunicação e visibilidade por recurso

Incidentes longos exigem informações que acompanhem seus múltiplos estados. Um status regional agregado pode dizer que existe degradação, mas não responde se um volume específico está isolado, em reconstrução, aguardando capacidade ou sujeito a recuperação manual. Clientes precisam converter a situação da plataforma em decisões próprias: congelar gravações, ativar contingências, restaurar cópias ou esperar.

A AWS anunciou comunicações mais frequentes e melhor visibilidade, além de melhorias na automação de recuperação. O anúncio é evidência de intenção e de reconhecimento de lacunas; as cinco fontes não verificam de forma independente a implementação ou a eficácia posterior dessas mudanças. Fechar o ciclo requer testes, métricas e documentação atualizados, não apenas uma lista de compromissos.

Responsabilidade da operadora e do cliente

A operadora tinha autoridade sobre a mudança de rede, o desenho de replicação, a capacidade livre, o recuo, a condição de corrida, os limites do plano de controle e a comunicação em nível de recurso. Esses são controles que clientes individuais não poderiam alterar. A responsabilidade operacional da AWS inclui projetar o envelope de recuperação e demonstrar que uma falha não consome os recursos reservados para repará-la.

Clientes, por sua vez, controlam decisões como classificação de cargas, políticas próprias de cópia, testes de restauração, tolerância a indisponibilidade e caminhos alternativos em nível de aplicação. Essa divisão não transfere para eles a causa de uma falha da plataforma. Ela reconhece que continuidade é uma composição de controles e que cada parte deve responder pelo que tinha autoridade, informação, recursos e tempo para fazer.

O registro não identifica uma pessoa culpada nem revela a cadeia interna de aprovação da mudança. Atribuir culpa individual seria especulação. Uma análise justa deve concentrar-se no desenho dos controles, nos sinais disponíveis e na capacidade institucional de limitar danos.

Medidas anunciadas e testes de garantia

A AWS anunciou buffers maiores de capacidade de recuperação, recuo mais agressivo, correção da condição de corrida, timeouts e redução de carga melhores, isolamento mais forte entre zonas, controles automatizados de recuperação, melhorias nas ferramentas Multi-AZ e comunicações mais frequentes. Cada medida corresponde a uma parte observada do mecanismo, o que torna o conjunto tecnicamente coerente.

Coerência, entretanto, não equivale a comprovação. Uma garantia útil perguntaria: quantas reconstruções simultâneas o sistema suporta antes de afetar clientes? Quanto da capacidade fica realmente disponível durante uma falha correlacionada? Um cluster degradado pode esgotar threads regionais? O recuo permanece eficaz quando milhares de componentes retomam ao mesmo tempo? O isolamento é testado sob carga realista? Quanto tempo leva para identificar o último recurso sem réplica consistente?

Essas perguntas transformam promessas em critérios observáveis. Exercícios devem incluir recuperação, e não apenas failover inicial. Telemetria precisa separar contenção, restauração de API, reconstrução de dados e resolução manual. Exceções devem ter responsáveis e prazo. Só então capacidade de recuperação deixa de ser uma suposição e se torna controle de responsabilidade.

O que permanece desconhecido

Não sabemos a contagem exata de clientes, bytes, registros ou prejuízos. Não sabemos a sequência completa de aprovações internas, nem há base para declarar violação legal ou contratual. As fontes não demonstram que todas as medidas anunciadas foram implantadas, continuam em uso ou correspondem à arquitetura atual.

Esses desconhecidos não enfraquecem a principal conclusão; delimitam-na. O episódio permite afirmar que uma mudança incorreta acionou isolamento, que a recuperação concorrente amplificou a demanda, que a capacidade livre e o recuo foram insuficientes para a onda e que recursos regionais compartilhados propagaram degradação de API. Permite ainda observar impactos a jusante e um pequeno resíduo de volumes não restaurados consistentemente, sempre com seus denominadores corretos.

Conclusão

Redundância sem um envelope de recuperação testado pode falhar no momento em que mais importa. O caso do EBS em 2011 mostrou que reconectar componentes não basta: o sistema precisa controlar o trabalho que a reconexão libera. Capacidade ociosa, limites de concorrência, recuo, isolamento e redução de carga são mecanismos de continuidade e também mecanismos de responsabilidade.

A prestação de contas adequada não depende de procurar um culpado antes das evidências. Ela pergunta quem controlava cada decisão, quais condições ampliaram o gatilho, que impacto foi medido e como o encerramento pode ser comprovado. Para fornecedores e clientes, a lição comum é manter responsabilidades distintas, tornar dependências visíveis e testar não apenas a passagem para a contingência, mas o caminho inteiro de volta.

Fontes