Utilizando AWS Cloudfront para un dominio que escucha en un puerto que no es 443

Utilizando AWS Cloudfront para un dominio que escucha en un puerto que no es 443

Tenemos un www.domain.comque se resuelve en un AWS Load Balancer respaldado por una instancia de AWS EC2 Nginx.

www.domain.com:8888proxy a una aplicación web backend de AWS.

www.domain.com:443sirve html estático desde el disco de EC2 excepto:

  • /app/ruta que representa una aplicación backend dinámica que se ejecuta en un EC2
  • Respuestas 404 que también representan el mismo backend dinámico EC2 para páginas de error personalizadas.

Objetivo: poder servir nuestro html estático directamente desde el almacenamiento S3 bajo el dominio www.domain.com(actualmente sincronizamos los archivos estáticos de S3 con el disco del servidor Nginx).

Opciones consideradas:

  • Cloudfront con un grupo de origen de conmutación por error se encargará muy bien del tráfico del puerto 443. Pero si nos asociamos www.domain.comcon Cloudfront, obviamente nada nos escuchará www.domain.com:8888.

  • Si tenemos un Load Balancer que proporciona los oyentes, www.domain.compodemos manejar el tráfico dinámico en los puertos 443 y 8888. Pero no es obvio cómo tener S3 como grupo objetivo del Load Balancer. Creo que esto podría ser posible con un punto final de VPC para S3. Pero, ¿podría esto hacer frente a las conmutaciones por error 404? (Ref: https://aws.amazon.com/blogs/networking-and-content-delivery/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/)

  • Nos embarcamos en un proyecto para mover www.domain.com:8888el tráfico alt.domain.com:443y luego usamos la opción 1. Sin embargo, mientras queramos preservar los enlaces, www.domain.com:8888creo que no podemos tener Cloudfront como destino www.domain.com.

  • Tenga un proxy Nginx frontal que envíe 8888 tráfico a un Load Balancer y 443 tráfico a Cloudfront. Esto anularía muchos de los puntos positivos de usar Cloudfront al forzar el tráfico del cliente a través de un proxy para llegar allí. Además, necesitaríamos manejar la terminación SSL a través de Lets Encrypt fuera de Amazon ACM.

La opción 3 parece la más limpia, pero no sucedería rápida ni fácilmente... así que estamos buscando alternativas.

¿Hay otras opciones que deberíamos considerar?

información relacionada