AWS us-east-1: congestão na rede interna

01 · CONTEXTO

Duas redes, uma ponte frágil

Em dezembro de 2021, a região us-east-1 da AWS sofreu um evento longo que atingiu muitos serviços. O post-mortem oficial descreve duas redes: a rede principal, onde rodam os serviços dos clientes, e uma rede interna, que sustenta ferramentas de operação como os dados de monitoramento em tempo real. Entre elas há dispositivos de rede que fazem a ponte. Tudo começou do lado principal, por uma atividade automática de escala de capacidade de um dos serviços da AWS.

1. Em operação normal, os serviços da rede principal falam com a rede interna por dispositivos de rede dedicados a essa ponte.

2. A rede interna abriga o monitoramento e outros serviços de que a operação depende para enxergar e controlar a plataforma.

02 · GATILHO

Da escala automática à tempestade de retries

A atividade de escala gerou um grande pico de conexões que sobrecarregou os dispositivos entre as duas redes. A sobrecarga aumentou latência e erros, o que provocou ainda mais tentativas de conexão e retries, num ciclo de realimentação. O post-mortem aponta ainda um problema latente que impediu esses clientes de recuar (backoff) de forma adequada durante o evento. É o desenho clássico de falta de controle de sobrecarga: quando o cliente insiste mais justamente porque o servidor está lento, a carga extra mantém o gargalo vivo.

1. Uma atividade automática de escala dispara dentro da rede principal.

2. O pico de conexões sobrecarrega os dispositivos que ligam a rede principal à rede interna.

3. Latência e erros geram novas tentativas; sem recuo adequado, as retries somam carga e a congestão persiste.

03 · PLANOS

Plano de controle e plano de dados

O impacto foi desigual. Segundo o post-mortem, instâncias EC2 que já estavam rodando não foram afetadas, e clientes que acessavam S3 e DynamoDB não foram impactados pelo evento. Quem sofreu foram as operações que dependem do caminho congestionado, como criar recursos novos e chamar APIs de controle. Essa separação entre o que já está em execução e o que precisa de coordenação é o que torna uma arquitetura multirregião e padrões de disponibilidade tão importantes: o plano de dados costuma aguentar mais que o plano de controle.

1. As cargas que já estavam em execução continuam servindo o cliente, sem depender do caminho congestionado.

2. O acesso direto a armazenamento de objetos e à tabela NoSQL não foi impactado.

3. As APIs de controle dependem da ponte entre as redes e ficam lentas ou com erro enquanto ela está congestionada.

4. Para aliviar a pressão, a entrega de eventos foi desabilitada por operadores até a situação melhorar.

04 · RESPOSTA

Operar às cegas

A congestão afetou de imediato a disponibilidade dos dados de monitoramento em tempo real das equipes internas. Sem boa visibilidade, diagnosticar e agir ficou mais lento: a própria ferramenta para enxergar o problema dependia do caminho que estava saturado. A AWS desabilitou imediatamente as atividades de escala que originaram o evento. Ainda assim, o post-mortem descreve uma congestão persistente nos dispositivos entre as redes, o que prolongou o impacto. Esse é o ponto central de monitoramento e observabilidade: o canal de observação não deve compartilhar o gargalo com o que ele observa.

05 · LIÇÕES

O que levar para o seu projeto

Entre as mudanças anunciadas está uma nova arquitetura de suporte que roda ativamente em várias regiões da AWS, ou seja, o caminho de ajuda ao cliente deixaria de depender de uma única região. Do ponto de vista de recuperação de desastres, é a lição de não pôr o canal de comunicação e de suporte dentro do mesmo domínio de falha do sistema que ele cobre.

1. Antes, o suporte rodava em uma só região e caía junto com ela.

2. Com uma arquitetura ativa em várias regiões, o tráfego do cliente pode seguir para a região saudável.