CloudFront

CloudFront 서명된 URL과 서명된 쿠키는 동일한 기본 기능을 제공합니다. 이를 통해 콘텐츠에 액세스할 수 있는 사람을 제어할 수 있습니다. CloudFront를 통해 프라이빗 콘텐츠를 제공하고 서명된 URL을 사용할지 또는 서명된 쿠키를 사용할지 결정하려는 경우 다음을 고려하십시오.

다음 경우에 서명된 URL을 사용하십시오.

- RTMP 배포판을 사용하고 싶습니다. 서명된 쿠키는 RTMP 배포에 지원되지 않습니다.

- 개별 파일에 대한 액세스를 제한하려는 경우(예: 응용 프로그램의 설치 다운로드).

- 사용자가 쿠키를 지원하지 않는 클라이언트(예: 사용자 지정 HTTP 클라이언트)를 사용하고 있습니다.

다음 경우에 서명된 쿠키를 사용하십시오.

- HLS 형식의 비디오에 대한 모든 파일 또는 웹사이트의 구독자 영역에 있는 모든 파일과 같이 제한된 여러 파일에 대한 액세스를 제공하려고 합니다.

- 현재 URL을 변경하고 싶지 않습니다.

따라서 이 시나리오의 정답은 다음과 같은 옵션입니다. 서명된 쿠키를 사용하여 사용자가 콘텐츠에 액세스해야 하는지 여부를 결정하기 위해 애플리케이션을 수정하여 CloudFront 배포의 개인 파일에 액세스할 수 있는 사람을 제어합니다. 회원의 경우 필요한 Set-Cookie 헤더를 뷰어에게 보내면 해당 사용자에게만 콘텐츠가 잠금 해제됩니다.

옵션: 사용자 요청과 자동으로 일치하는 원본 프로토콜 정책으로 Match Viewer를 사용하도록 CloudFront 배포를 구성합니다. 이렇게 하면 요청이 유료 회원인 경우 비공개 콘텐츠에 대한 액세스가 허용되고 회원이 아닌 경우 거부됩니다. 일치 뷰어는 다음에 따라 HTTP 또는 HTTPS를 사용하여 오리진과 통신하도록 CloudFront를 구성하는 오리진 프로토콜 정책이기 때문입니다. 뷰어 요청의 프로토콜입니다. CloudFront는 최종 사용자가 HTTP 및 HTTPS 프로토콜을 모두 사용하여 요청하는 경우에도 객체를 한 번만 캐시합니다.

위 설명에서 볼 수 있듯이 서명된 URL은 주로 개별 파일에 대한 액세스를 제공하는 데 사용되기 때문에 구성원에게만 개인 파일을 볼 수 있도록 허용하는 사용자 정의 정책으로 서명된 URL 생성이라는 옵션은 올바르지 않습니다. 또한 시나리오에서는 현재 URL을 변경하고 싶지 않다고 명시적으로 명시되어 있으므로 서명된 쿠키를 구현하는 것이 서명된 URL보다 더 적합합니다.