Uma vasta interrupção da Amazon Web Services na nuvem que começou na manhã de segunda-feira ilustrou as frágeis interdependências da internet, enquanto grandes plataformas de comunicação, finanças, saúde, educação e governo ao redor do mundo sofreram interrupções. À medida que o dia avançava, a AWS diagnosticou e começou a trabalhar para corrigir o problema, que se originou da crítica região US-EAST-1 da empresa, baseada no norte da Virgínia. Mas a cascata de impactos levou tempo para ser completamente resolvida.
Pesquisadores que refletiram sobre o incidente destacaram particularmente a duração da interrupção de segunda-feira, que começou por volta das 3 da manhã ET na segunda-feira, 20 de outubro. A AWS disse em atualizações de status que, às 18h01 ET na segunda-feira, “todos os serviços da AWS voltaram às operações normais.” A interrupção foi diretamente provocada pelas interfaces de programação de aplicativos do banco de dados DynamoDB da Amazon e, de acordo com a empresa, “impactou” 141 outros serviços da AWS. Vários engenheiros de rede e especialistas em infraestrutura enfatizaram à WIRED que erros são compreensíveis e inevitáveis para os chamados “hiperscaladores” como AWS, Microsoft Azure e Google Cloud Platform, dada sua complexidade e tamanho. Mas eles também notaram que essa realidade não deve simplesmente isentar os provedores de nuvem quando há períodos prolongados de inatividade.
“A palavra ‘hindsight’ é fundamental. É fácil descobrir o que deu errado depois do fato, mas a confiabilidade geral da AWS mostra como é difícil prevenir cada falha,” diz Ira Winkler, diretor de segurança da informação da empresa de confiabilidade e cibersegurança CYE. “Idealmente, isso será uma lição aprendida, e a Amazon implementará mais redundâncias que poderiam evitar um desastre como este de acontecer no futuro — ou pelo menos evitar que permaneçam fora do ar por tanto tempo.”
A AWS não respondeu a perguntas da WIRED sobre o longo prazo da recuperação para os clientes. Um porta-voz da AWS afirma que a empresa planeja publicar um de seus “resumos pós-evento” sobre o incidente.
“Não acho que esta foi apenas uma interrupção do tipo ‘coisas acontecem’. Eu esperaria uma remediação total muito mais rápida,” diz Jake Williams, vice-presidente de pesquisa e desenvolvimento da Hunter Strategy. “Para dar a eles o devido crédito, falhas em cascata não são algo que eles têm muita experiência, porque eles não têm interrupções com frequência. Então, isso é a seu crédito. Mas é muito fácil entrar na mentalidade de dar uma passada de pano para essas empresas, e não devemos esquecer que elas criam essa situação ao tentar ativamente atrair cada vez mais clientes para sua infraestrutura. Os clientes não têm controle sobre se estão se excedendo ou o que podem ter acontecendo financeiramente.”
O incidente foi causado por um culpado familiar em interrupções na web — problemas de resolução do “sistema de nomes de domínio”. O DNS é essencialmente o mecanismo de telefone da internet para direcionar navegadores da web aos servidores corretos. Como resultado, problemas de DNS são uma fonte comum de interrupções porque podem fazer com que solicitações falhem e impeçam que o conteúdo carregue.
“A computação em nuvem é uma maravilha, mas o coração dela é uma lista interminável de serviços e dependências complexas que estão sempre a uma configuração de distância da falha,” diz Mark St. John, diretor de operações e cofundador da startup de segurança de sistemas Neon Cyber.
Falando de maneira geral sobre hiperscaladores, St. John ecoou o ponto de Williams de que, em troca da arquitetura madura e da base segura das plataformas de nuvem, os clientes cedem o controle de sua infraestrutura digital subjacente e a extensão em que seu provedor de nuvem está ou não investindo em resiliência e planejamento de contingências em um determinado momento. “Em uma certa escala, a validação operacional para prestadores de serviço não pode ser uma vítima do corte de custos,” diz St. John.
Pensando especificamente sobre a interrupção de segunda-feira, um arquiteto de rede sênior de uma grande empresa de tecnologia, que solicitou anonimato porque não está autorizado a falar com a imprensa, também enfatizou que o tempo que a AWS levou para diagnosticar e remediar os problemas foi notável.
“É extraordinário que eles não tenham mais falhas,” disse ele, “mas neste caso foi estranho que o que era basicamente um serviço central — DynamoDB e o DNS em torno disso — levou tanto tempo para detectar e chegar à raiz do problema.