Использование AWS Cloudfront для домена, который прослушивает порт, отличный от 443

Question

У нас есть , www.domain.comкоторый преобразуется в балансировщик нагрузки AWS, поддерживаемый экземпляром AWS EC2 Nginx.

www.domain.com:8888прокси-серверы для внутреннего веб-приложения AWS.

www.domain.com:443обслуживает статический HTML с диска EC2, за исключением:

• /app/путь, который проксирует к динамическому бэкэнд-приложению, работающему на EC2
• Ответы 404, которые также проксируют тот же динамический бэкэнд EC2 для пользовательских страниц ошибок.

Цель: обеспечить возможность обслуживания нашего статического HTML-кода непосредственно из хранилища S3 в домене www.domain.com(в настоящее время мы синхронизируем статические файлы S3 с диском сервера Nginx).

Рассматриваемые варианты:

• Cloudfront с отказоустойчивой исходной группой прекрасно разберется с трафиком порта 443. Но если мы подключимся www.domain.comк cloudfront, очевидно, что ничего не будет слушать www.domain.com:8888.

• Если у нас есть балансировщик нагрузки, предоставляющий слушателей, www.domain.comмы можем справиться с динамическим трафиком на портах 443 и 8888. Но не очевидно, как сделать S3 целевой группой балансировщика нагрузки. Я считаю, что это возможно с конечной точкой VPC для S3. Но может ли это справиться с отказами 404? (Ссылка: https://aws.amazon.com/blogs/networking-and-content-delivery/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/ )

• Мы приступаем к проекту по перемещению www.domain.com:8888трафика на alt.domain.com:443, а затем используем вариант 1. Однако, пока мы хотим сохранить ссылки на , www.domain.com:8888я думаю, нам запрещено использовать CloudFront в качестве места назначения www.domain.com.

• Иметь фронтенд-прокси Nginx, который проксирует трафик 8888 на балансировщик нагрузки и трафик 443 на cloudfront. Это сведет на нет многие из плюсов использования Cloudfront, заставляя клиентский трафик проходить через прокси, чтобы попасть туда. Плюс нам нужно будет обрабатывать терминацию SSL через Lets Encrypt за пределами Amazon ACM.

Вариант 3 кажется наиболее чистым, но он не будет реализован быстро и легко, поэтому мы ищем альтернативы.

Есть ли другие варианты, которые нам следует рассмотреть?