Alta disponibilidade e AWS VPN

Question

Tenho uma pergunta sobre como obter alta disponibilidade em uma VPN da AWS.

Contexto:

Eu tenho um requisito para estabelecer um site para conexão VPN entre meu AWS VPC e uma grande empresa. Esse link de VPN é necessário para oferecer suporte a conexões http de entrada para um aplicativo no meu AWS VPC. Por vários motivos, a grande corporação à qual estou me conectando não me alocará uma sub-rede privada (RFC1918) não conflitante para usar. Em vez disso, eles exigem que eu use o NAT para expor meus serviços pela VPN em um IP público de minha escolha (um que reservarei). Acredito que consegui configurá-lo com sucesso (sujeito a testes) com a combinação certa de regras de roteamento, seguindo este guia (sem um proxy separado), no entanto eu só posso direcionar conexões de entrada para um único IP.

Pergunta:

Gostaria de saber se existe uma maneira de direcionar conexões para um balanceador de carga altamente disponível? Isso permitiria melhor escalabilidade e também alta disponibilidade. Coisas que eu considerei:

• Usando um ELB externo da AWS:
  • Estes não têm endereços IP confiáveis ou um intervalo estreito o suficiente. Eu não seria capaz de adicionar esse intervalo nas regras de roteamento do lado direito, pois esse intervalo poderia entrar em conflito com qualquer outro serviço hospedado na AWS.
• Usando um ELB interno da AWS:
  • Eles têm um registro DNS público e um intervalo previsível, mas estão nos intervalos de IP privados e, portanto, não podem ser usados pelo sistema cliente, pois só podem criar rotas estáticas para IPs públicos não RFC1918.
• Implementando meu próprio balanceador de carga, como o HAproxy:
  • Isso resolveria o problema de escalabilidade, mas ainda deixaria um único ponto de falha no sistema (o próprio nó de HA).
  • Além disso, essa é mais uma máquina que preciso manter.

Alguém sabe se existe uma maneira de referenciar um ELB nas tabelas de roteamento VPC? Ou tem alguma outra sugestão sobre como conseguir isso?

Obrigado

    

Answer 1

A máquina que termina o túnel é um ponto único de falha, não é? Se assim for, correndo HAProxy ali parece ser a coisa a fazer (e eu não estou apenas dizendo isso porque é assim que eu faço, mesmo que seja).

Eu posso contar minhas interrupções de produção causadas por haproxy em uma mão sem usar nenhum dedo (ou polegar). O DNS assíncrono na versão 1.6 (ainda em desenvolvimento até o momento) permitiria que você usasse um ELB interno como back-end para o haproxy, permitindo que você definisse e esquecesse e usasse as integrações existentes do ELB / EC2 para sua capacidade real de dimensionamento .

Os tipos de instância C3, C4, M3, R3 e T2 também suportam o relativamente novo recuperação de instâncias , que interrompe, recria e reinicia sua instância em hardware diferente, mas com os mesmos volumes de id de instância, IP elástico e EBS, se ele parar de responder favoravelmente a verificações de integridade de instâncias.