Cloudfront Origin이 Application Load Balancer DNS용으로 생성된 Route 53 레코드 세트가 될 수 있습니까?

Cloudfront Origin이 Application Load Balancer DNS용으로 생성된 Route 53 레코드 세트가 될 수 있습니까?

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는 HostCloudFront가 브라우저에서 ELB로 전달하는 헤더와 일치하는 인증서를 제시해야 합니다.

그렇지 않으면 CloudFront는 를 반환합니다 502 Bad Gateway.

ELB 호스트 이름을 오리진 도메인 이름으로 사용하는 경우 첫 번째 조건은 가능하지 않습니다. 따라서 CloudFront 콘솔에서는 Host대상이 ELB인 것으로 확인되면 전달할 헤더를 화이트리스트에 추가하라는 메시지를 표시합니다.

하지만 환경이 이렇다면...

  • www.example.comCloudFront를 가리키며 배포의 대체 도메인 이름에 구성되어 있습니다.
  • 헤더 Host는 화이트리스트에 구성되어 있으며
  • ELB 호스트 이름은 Origin Domain Name으로 설정되며,
  • ELB에는 다음에 대한 유효한 인증서가 있습니다.www.example.com

...한 가지 예외를 제외하고는 작동합니다. dzczcexample.cloudfront.netCloudFront를 통해 오리진에 액세스하기 위해 브라우저에서 도메인을 사용할 수 없습니다. 일부 구성에서는 실제로 두 번째 진입점을 통해 콘텐츠에 액세스하는 것을 원하지 않기 때문에 이것이 바람직합니다.

그렇지 않은 경우 가장 좋은 방법은 실제로 제안한 대로 수행하는 것입니다. 즉, 제어하는 ​​도메인의 호스트 이름을 DNS의 ELB에 매핑하고 해당 호스트 이름을 CloudFront의 원본 도메인 이름으로 구성하는 것입니다.

CloudFront는 인터넷에 액세스할 수 있는 모든 호스트 이름을 오리진으로 사용할 수 있습니다. 오리진이 AWS 내부에 있을 필요는 없습니다. 임의의 예로 Google Cloud Storage 버킷을 CloudFront의 원본으로 사용할 수 있습니다. CloudFront와 Origin 간의 통합은 느슨합니다. 이는 CloudFront가 ELB에 대해 특별한 인식이 없다는 것을 의미합니다. 단지 공용 DNS를 통해 호스트 이름을 확인하고 연결합니다.

또한 CloudFront 배포만 원본과 통신할 수 있도록 하려면 CloudFront에서 비밀 사용자 지정 원본 헤더를 구성해야 하며 원본은 이 값이 없는 요청을 거부해야 합니다. ELB 보안 그룹을 사용하여 CloudFront 주소 공간에서만 액세스를 허용할 수 있지만 해당 공간은 상당히 자주 커지므로 새 주소 범위를 허용하려면 보안 그룹을 업데이트된 상태로 유지하는 방법이 필요합니다... 하지만 제 생각에는 이는 누구나 기술적으로 CloudFront 배포판을 생성하고 ELB를 포함하여 어디든 가리킬 수 있기 때문에 보안에 대한 잘못된 인식을 제공합니다. 사용자 정의 헤더를 사용하면 이를 방지할 수 있습니다.

관련 정보