Temos um www.domain.comque resolve para um AWS Load Balancer apoiado pela instância AWS EC2 Nginx.
www.domain.com:8888proxies para um aplicativo web back-end da AWS.
www.domain.com:443serve html estático do disco do EC2, exceto:
/app/caminho que faz proxy para um aplicativo de back-end dinâmico em execução em um EC2- Respostas 404 que também fazem proxy para o mesmo back-end dinâmico EC2 para páginas de erro personalizadas.
Objetivo: ser capaz de servir nosso html estático diretamente do armazenamento S3 no domínio www.domain.com(atualmente sincronizamos os arquivos estáticos do S3 com o disco do servidor Nginx).
Opções consideradas:
O Cloudfront com um grupo de origem de failover cuidará bem do tráfego da porta 443. Mas se nos associarmos
www.domain.comao cloudfront, obviamente nada será ouvidowww.domain.com:8888.Se tivermos um Load Balancer fornecendo os ouvintes,
www.domain.compodemos lidar com o tráfego dinâmico nas portas 443 e 8888. Mas não é óbvio como ter o S3 como grupo-alvo do Load Balancer. Acredito que isso seria possível com um endpoint VPC para S3. Mas isso poderia lidar com failovers 404? (Ref: https://aws.amazon.com/blogs/networking-and-content-delivery/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/ )Embarcamos em um projeto para mover
www.domain.com:8888o tráfego paraalt.domain.com:443e então usamos a opção 1. No entanto, enquanto quisermos preservar links para,www.domain.com:8888acho que estamos proibidos de ter o cloudfront como destino dewww.domain.com.Tenha um proxy Nginx de front-end que faça proxy do tráfego 8888 para um balanceador de carga e do tráfego 443 para o cloudfront. Isso anularia muitos dos pontos positivos do uso do Cloudfront, forçando o tráfego do cliente através de um proxy para chegar lá. Além disso, precisaríamos lidar com a terminação SSL via Lets Encrypt fora do Amazon ACM.
A opção 3 parece ser a opção mais limpa, mas não aconteceria de forma rápida ou fácil.. por isso estamos procurando alternativas.
Existem outras opções que deveríamos considerar?