Página AWS ELB "desculpe, o site está inativo"

Eu tenho um site básico-ish ELB v2. Nenhum cluster ou qualquer coisa ainda. Sou bastante inexperiente com a AWS.

Minha pilha é nginx / uwsgi / django + alguns outros serviços.

Fiquei me perguntando se alguém pensava em fazer uma página no estilo "desculpe, o site está inativo ..." (o texto personalizado que eu posso atualizar o tempo de inatividade planejado é um bônus!) Sempre que houver um tempo de inatividade por qualquer motivo e a saúde de a instância é vermelha. Não parece que a Amazon ofereça esse recurso - estou perdendo alguma coisa? Existe uma maneira de criar uma instância minúscula e separada que só é veiculada se a principal for vermelha ou algo assim?

Obrigado!

A solução simples e legal aqui é colocar seu ELB atrás do CloudFront.

Se o servidor de origem (neste caso, o ELB) gerar um erro 5XX (ou 4XX, se desejar), o CloudFront poderá retornar uma página de erro personalizada , que você poderá configurar para que o CloudFront seja buscado em um bucket S3, criando uma segunda origem apontando para o bucket e criando um roteamento de comportamento de cache (por exemplo) /errors/static/*para o bucket.

Isso funciona melhor do que o failover do Route 53 por um motivo importante ... uma falha fatal, se você desejar ... os navegadores são péssimos em armazenar em cache as pesquisas de DNS por muito mais tempo do que o esperado. O DNS TTL não é relevante.

Essencialmente, quando um navegador tem uma entrada DNS na mão, ele continua tentando usá-lo ... normalmente, até que todas as janelas do navegador sejam fechadas.

Portanto, se o site for desativado para um visitante que já estava no site, é improvável que ele veja o site alternativo.

Pior ainda, se um visitante acessar o site pela primeira vez enquanto estiver inativo, ele "permanecerá" na página de manutenção até fechar todas as janelas do navegador.

Se você usa DNS de failover, isso é realmente bom apenas se o destino de failover ainda for seu aplicativo, talvez um pouco mais longe.

Você pode desativar o cache do CloudFront, se não precisar dele.

Você também pode configurar o erro do CloudFront em cache TTL para um valor diferente de zero, se desejar parar de martelar o site enquanto estiver inativo e tentando se recuperar. Para uma determinada página que gera um erro, ela continuará mostrando a página de erro e não incomodará o servidor com mais solicitações para essa página até que o CachingTTL de erro expire.

Use o DNS da Route53 e o roteamento de failover . Você deve conseguir um bucket S3 que hospeda um site estático de uma única página. Eu não acho que você pode fazer isso apenas com ELB.

A Amazon tem uma postagem no blog que mostra como fazer isso aqui .

Atualização: como Michael diz, há uma desvantagem no cache do DNS do navegador, veja a resposta para obter mais informações. A rota 53 é provavelmente uma opção mais simples que o CloudFront, mas o CF tem outras vantagens, desempenho e, em alguns casos de uso, pode reduzir custos.

Várias soluções já foram mencionadas, incluindo CloudFront e Route53. O CloudFront é uma excelente solução e, na minha experiência, não diminuiu as coisas, mas gera um custo adicional. E o Route53 tem os problemas de cache do DNS já mencionados.

Até que o ALB suporte páginas de erro personalizadas prontas para uso (o que pode ou não acontecer), há potencialmente uma nova solução após o recente anúncio das respostas fixas do ALB , mas não é necessário apontar e clicar: você pode configurar uma função Lambda que adiciona temporariamente uma regra para o seu balanceador de carga, fornecendo uma resposta fixa com o conteúdo da sua 'página de erro'.

Além de escrever o Lambda, você precisará encontrar uma maneira de ativá-lo 'on' e 'off', que pode ser por meio de uma verificação de integridade do Route53 ou de saúde do grupo-alvo do balanceador de carga (provavelmente via alarme do CloudWatch -> SNS - > Lambda).

Não é exatamente simples, mas provavelmente funcionaria bem depois de configurado!

Conforme escrito por @Tim e @Micheal, você pode usar o DNS do Route53 e o roteamento de failover , ou o CloudFront com páginas de erro personalizadas . Ambos os métodos têm seus prós e contras.

Se você ainda não está usando o Cloudfront, acho que o Route53 é uma solução mais simples. Consulte a postagem atualizada do blog da AWS (que agora inclui um método mais simples para a integração do ELB).

O CloudFront é muito mais complicado de configurar e levará cerca de 15 minutos para cada atualização. O Cloudfront também armazena em cache (conforme o esperado), portanto, não está claro se isso será mais lento para responder do que os problemas de cache DNS com o Route 53.

Observe que, se o site do ELB responder apenas ao SSL, você não poderá usar a solução S3 simples, conforme descrito no blog da AWS 3 . Nesse caso, você precisará adicionar o Cloudfront na frente do bucket S3 para adicionar o SSL, tornando a solução de roteamento de falhas do DNS mais complicada.