AWS 애플리케이션 로드 밸런서 DNS에 대한 A Route53 레코드 세트를 생성했습니다. 내 질문은 AWS Cloudfront 원본에 이 레코드 세트 URL이 포함될 수 있는지 여부입니다.
예: ALB DNS 이름: xxxx.us-east-1.elb.amazonaws.com. 애플리케이션 로드 밸런서 DNS에 대한 Route53의 레코드 세트 항목: www.abc.com
이제 www.abc.com을 cloudfront의 원본으로 설정할 수 있습니까?
답변1
원본 프로토콜을 HTTPS 전용으로 설정하면 CloudFront와 ELB 간의 트래픽이 TLS로 보호되며 실제 원본 도메인 이름은 어느 쪽이든 구성할 수 있습니다. 헤더 Cloudfront-Forwarded-Proto
는 CloudFront와 최종 사용자 사이에 사용되는 프로토콜을 나타냅니다(이 구성에서는 로드 밸런서가 항상 설정하므로 X-Forwarded-Proto: https
).
CloudFront는 자신과 오리진 간의 TLS 협상이 신뢰할 수 있다고 주장합니다. 일반적으로 간과되는 요소는 TLS(SSL) 인증서가 연결 암호화 제공(명백함)과 서버 인증 제공, 즉 서버가 요청된 호스트 이름에 대한 서버로 인증되었음을 증명하는 두 가지 작업을 수행한다는 것입니다. 사기꾼이 아닙니다(덜 명백함). 이것이 바로 서버의 인증서 주체 및/또는 주체 대체 이름이 브라우저 주소 표시줄의 호스트 이름과 일치하지 않는 경우 브라우저 경고가 표시되는 이유입니다.
CloudFront는 이 요구 사항에 대해 제한된 예외를 허용하여 다음 두 조건 중 하나가 충족되는 한 인증서 검증이 성공하도록 허용합니다.
- ELB는 원본 도메인 이름과 일치하는 인증서를 제시해야 합니다.또는
- ELB는
Host
CloudFront가 브라우저에서 ELB로 전달하는 헤더와 일치하는 인증서를 제시해야 합니다.
그렇지 않으면 CloudFront는 를 반환합니다 502 Bad Gateway
.
ELB 호스트 이름을 오리진 도메인 이름으로 사용하는 경우 첫 번째 조건은 가능하지 않습니다. 따라서 CloudFront 콘솔에서는 Host
대상이 ELB인 것으로 확인되면 전달할 헤더를 화이트리스트에 추가하라는 메시지를 표시합니다.
하지만 환경이 이렇다면...
www.example.com
CloudFront를 가리키며 배포의 대체 도메인 이름에 구성되어 있습니다.- 헤더
Host
는 화이트리스트에 구성되어 있으며 - ELB 호스트 이름은 Origin Domain Name으로 설정되며,
- ELB에는 다음에 대한 유효한 인증서가 있습니다.
www.example.com
...한 가지 예외를 제외하고는 작동합니다. dzczcexample.cloudfront.net
CloudFront를 통해 오리진에 액세스하기 위해 브라우저에서 도메인을 사용할 수 없습니다. 일부 구성에서는 실제로 두 번째 진입점을 통해 콘텐츠에 액세스하는 것을 원하지 않기 때문에 이것이 바람직합니다.
그렇지 않은 경우 가장 좋은 방법은 실제로 제안한 대로 수행하는 것입니다. 즉, 제어하는 도메인의 호스트 이름을 DNS의 ELB에 매핑하고 해당 호스트 이름을 CloudFront의 원본 도메인 이름으로 구성하는 것입니다.
CloudFront는 인터넷에 액세스할 수 있는 모든 호스트 이름을 오리진으로 사용할 수 있습니다. 오리진이 AWS 내부에 있을 필요는 없습니다. 임의의 예로 Google Cloud Storage 버킷을 CloudFront의 원본으로 사용할 수 있습니다. CloudFront와 Origin 간의 통합은 느슨합니다. 이는 CloudFront가 ELB에 대해 특별한 인식이 없다는 것을 의미합니다. 단지 공용 DNS를 통해 호스트 이름을 확인하고 연결합니다.
또한 CloudFront 배포만 원본과 통신할 수 있도록 하려면 CloudFront에서 비밀 사용자 지정 원본 헤더를 구성해야 하며 원본은 이 값이 없는 요청을 거부해야 합니다. ELB 보안 그룹을 사용하여 CloudFront 주소 공간에서만 액세스를 허용할 수 있지만 해당 공간은 상당히 자주 커지므로 새 주소 범위를 허용하려면 보안 그룹을 업데이트된 상태로 유지하는 방법이 필요합니다... 하지만 제 생각에는 이는 누구나 기술적으로 CloudFront 배포판을 생성하고 ELB를 포함하여 어디든 가리킬 수 있기 때문에 보안에 대한 잘못된 인식을 제공합니다. 사용자 정의 헤더를 사용하면 이를 방지할 수 있습니다.