www.domain.comAWS EC2 Nginx 인스턴스가 지원하는 AWS Load Balancer를 확인하는 것이 있습니다 .
www.domain.com:8888AWS 백엔드 웹 애플리케이션으로 프록시됩니다.
www.domain.com:443다음을 제외하고 EC2 디스크에서 정적 HTML을 제공합니다.
/app/EC2에서 실행되는 동적 백엔드 애플리케이션으로 프록시되는 경로- 사용자 지정 오류 페이지에 대해 동일한 동적 백엔드 EC2로 프록시되는 404 응답입니다.
목표: 도메인 아래 S3 저장소에서 직접 정적 HTML을 제공할 수 있습니다 www.domain.com(현재 S3 정적 파일을 Nginx 서버의 디스크로 동기화합니다).
고려된 옵션:
장애 조치 원본 그룹이 있는 Cloudfront는 포트 443 트래픽을 훌륭하게 처리합니다. 그러나 cloudfront와 연결하면
www.domain.com분명히 아무것도 수신하지 않습니다www.domain.com:8888.리스너를 제공하는 Load Balancer가 있는 경우
www.domain.com포트 443 및 8888의 동적 트래픽을 처리할 수 있습니다. 그러나 S3를 Load Balancer 대상 그룹으로 사용하는 방법은 명확하지 않습니다. 저는 이것이 S3용 VPC 엔드포인트를 사용하면 가능할 수 있다고 생각합니다. 하지만 이것이 404 장애 조치를 처리할 수 있을까요? (참조: https://aws.amazon.com/blogs/networking-and-content-delivery/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/)www.domain.com:8888우리는 트래픽을 으로 이동한 다음 옵션 1을 사용하는 프로젝트에 착수했습니다alt.domain.com:443. 그러나 링크를 보존하려는 한www.domain.com:8888Cloudfront를 의 대상으로 사용하는 것은 금지되어 있다고 생각합니다www.domain.com.8888 트래픽을 로드 밸런서로 프록시하고 443 트래픽을 cloudfront로 프록시하는 프런트엔드 Nginx 프록시가 있습니다. 이렇게 하면 클라이언트 트래픽이 프록시를 통해 강제로 Cloudfront에 도달하게 되므로 Cloudfront 사용의 많은 이점이 무효화됩니다. 또한 Amazon ACM 외부의 Lets Encrypt를 통해 SSL 종료를 처리해야 합니다.
옵션 3은 가장 깔끔한 옵션처럼 보이지만 빠르고 쉽게 발생하지 않으므로 대안을 찾고 있습니다.
고려해야 할 다른 옵션이 있습니까?