Pilot Light e espera aquecida

Quando seu requisito de RTO é mais rigoroso do que algumas horas, Backup e Restore é insuficiente. As duas camadas seguintes de DR — Pilot Light e Warm Standby — mantêm parte ou toda a sua infraestrutura em execução na região de DR continuamente, reduzindo significativamente o tempo de recuperação. Ambas as estratégias envolvem a manutenção contínua de um ambiente de DR e o uso do failover de verificações de integridade do Route 53 para redirecionar o tráfego durante um desastre. A diferença está na quantidade do ambiente de DR que permanece em execução ativa.

Na estratégia Pilot Light, você mantém em execução na região de DR apenas o núcleo crítico do seu sistema — normalmente apenas a camada de banco de dados com replicação contínua. Os servidores da aplicação NÃO estão em execução; em vez disso, você mantém AMIs, modelos de execução ou infraestrutura como código previamente criados, que podem iniciá-los rapidamente. Pense nisso como a chama piloto de um fogão a gás, que queima muito pequena e pode acender a chama completa em poucos minutos quando necessário. O RTO normalmente é de 30 a 60 minutos.

Quando a região primária falha e o failover do Pilot Light é acionado: Etapa 1 — Promova a réplica de leitura do RDS na região de DR para um banco de dados primário independente. Etapa 2 — Inicie instâncias EC2 a partir da AMI ou do modelo de execução previamente criado. Etapa 3 — Crie ou ative o Application Load Balancer e registre as novas instâncias EC2. Etapa 4 — Atualize a configuração da aplicação para apontar para o endpoint do banco de dados promovido. Etapa 5 — O failover da verificação de integridade do Route 53 conclui a alteração do DNS. Tempo total: 30 a 60 minutos.

Na estratégia Warm Standby, uma versão completa, porém reduzida, do seu ambiente de produção é executada continuamente na região de DR. Todas as camadas da aplicação estão ativas — servidores Web, servidores da aplicação e banco de dados — mas com capacidade reduzida (por exemplo, 2 instâncias em vez de 20). Durante o failover, você aumenta a capacidade do ambiente de DR para corresponder à carga de produção. O Route 53 redireciona automaticamente o tráfego por meio do failover da verificação de integridade. O RTO normalmente é inferior a 15 minutos. Warm Standby é a camada de DR mais popular para aplicações essenciais aos negócios.

O Aurora Global Database é a tecnologia de banco de dados ideal para DR com Warm Standby. O cluster da região secundária está sempre em execução, sempre recebendo replicação (atraso de <1 segundo) e pode ser promovido a um primário em menos de 1 minuto — muito mais rapidamente do que a promoção de uma réplica de leitura do RDS (que exige interromper a replicação e aplicar o atraso restante). Por isso, o Aurora Global Database é a opção recomendada quando seu requisito de RTO está na faixa de minutos, e não de dezenas de minutos.

Tanto o Pilot Light quanto o Warm Standby dependem do roteamento de failover do Route 53 para redirecionar o tráfego automaticamente. Configure um registro Primary apontando para o ALB ou endpoint da região de produção, com uma verificação de integridade associada. Configure um registro Secondary apontando para o endpoint da região de DR. Quando o Route 53 detecta que a verificação de integridade primária falhou pelo limite configurado, ele deixa de retornar o registro primário e fornece somente o registro secundário — tudo dentro do período de TTL do DNS.

Para que o Warm Standby alcance sua meta de RTO, o ambiente de DR precisa ser pré-aquecido — totalmente configurado e testado, de modo que aumentar a capacidade durante o failover seja a única ação necessária. Isso significa: as conexões com o banco de dados estão estabelecidas e armazenadas em cache, os arquivos de configuração da aplicação referenciam endpoints da região de DR, as instâncias EC2 estão em serviço atrás do ALB (mesmo que em pequena quantidade) e as verificações de integridade estão passando. Realize exercícios mensais de DR simulando um failover para garantir que o ambiente permaneça atualizado com a configuração de produção.

Manter o ambiente de DR sincronizado com a produção é o desafio operacional mais difícil. Se você configurar a produção manualmente e esquecer de atualizar o DR, seu ambiente de DR poderá não funcionar corretamente durante um desastre real. A solução é usar Infraestrutura como Código (IaC) com os mesmos modelos implantados nas duas regiões. Use AWS CloudFormation StackSets ou Terraform com vários espaços de trabalho para implantar uma infraestrutura idêntica nas duas regiões a partir de uma única base de código. Isso elimina a divergência de configuração.

A diferença de custo entre as duas estratégias é significativa. O Pilot Light custa apenas a réplica do banco de dados (normalmente de 50% a 100% do custo do banco de dados primário), além de um custo mínimo de rede na região de DR. Os servidores da aplicação ficam desligados, portanto não há custos de EC2. O Warm Standby acrescenta o custo de executar instâncias EC2 com capacidade reduzida, um ALB e, possivelmente, um cluster de cache menor — normalmente de 15% a 30% do custo total do ambiente de produção. A questão é saber se o RTO mais rápido do Warm Standby justifica o custo contínuo mais alto.

Depois que a região Primary for restaurada, será necessário ter um plano de retorno para voltar a utilizá-la. O retorno costuma ser a parte mais complicada da DR: durante a interrupção, a região de DR pode ter processado dados novos que precisam ser sincronizados novamente com a região Primary. Para bancos de dados, talvez seja necessário configurar a replicação reversa ou sincronizar novamente os dados da DR com a região Primary. No Route 53, restaure o registro Primary com sua verificação de integridade. Planeje e teste sempre o procedimento de retorno com o mesmo cuidado dedicado ao próprio failover.

Escolha Pilot Light quando: seu RTO permitir de 30 a 60 minutos e você quiser minimizar os custos de DR. O principal risco é o tempo necessário para iniciar e configurar os servidores da aplicação durante um desastre, sob pressão. Escolha Warm Standby quando: seu RTO exigir recuperação em até 15 minutos, sua aplicação for complexa o suficiente para que iniciá-la do zero durante um desastre seja arriscado ou seu compromisso de SLA com os clientes exigir uma recuperação mais rápida. Para a maioria das cargas de trabalho de produção de criticidade média, Warm Standby oferece o equilíbrio adequado.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) abordados nesta lição.

Nesta lição, você aprendeu que: Pilot Light mantém apenas o banco de dados em execução na DR e inicia os servidores da aplicação durante o failover; Warm Standby executa um ambiente completo em escala reduzida, que é ampliado durante o failover; e Infrastructure as Code evita desvios de configuração entre os ambientes Primary e de DR. Planeje e teste sempre os procedimentos de retorno, além do failover. A seguir, exploraremos o modo ativo-ativo em vários sites com DynamoDB Global Tables e Route 53.