CloudFront 배포에 다양한 원본 사용 - Amazon CloudFront

CloudFront 배포에 다양한 원본 사용

배포를 만들 때 CloudFront가 파일에 대한 요청을 보내는 원본을 지정합니다. CloudFront에서 여러 원본을 사용할 수 있습니다. 예를 들어 Amazon S3 버킷, MediaStore 컨테이너, MediaPackage 채널, Application Load Balancer 또는 AWS Lambda 함수 URL을 사용할 수 있습니다.

Amazon S3 버킷 사용하기

다음 주제에서는 Amazon S3 버킷을 CloudFront 배포의 원본으로 사용하는 여러 가지 방법을 설명합니다.

표준 Amazon S3 버킷 사용

Amazon S3를 배포의 원본으로 사용하는 경우 CloudFront에서 제공하려는 모든 객체를 Amazon S3 버킷에 배치합니다. Amazon S3에서 지원되는 모든 방식을 사용하여 객체를 Amazon S3 넣을 수 있습니다. 예를 들어 Amazon S3 콘솔이나 API 또는 서드 파티 도구를 사용할 수 있습니다. 다른 표준 Amazon S3 버킷과 마찬가지로 버킷에 계층을 만들어 객체를 저장할 수 있습니다.

기존 Amazon S3 버킷을 CloudFront 오리진 서버로 사용하더라도 버킷은 어떠한 방식으로도 변경되지 않습니다. 평상시처럼 Amazon S3 객체를 저장 및 액세스할 용도로 Standard Amazon S3 가격에 버킷을 계속해서 사용할 수 있습니다. 버킷에 객체를 저장하기 위해서는 정규 Amazon S3 요금이 발생합니다. CloudFront 사용을 위한 요금에 대한 자세한 내용은 Amazon CloudFront 요금을 참조하세요. CloudFront에서 기존 S3 버킷을 사용하는 자세한 방법은 기존 Amazon S3 버킷에 CloudFront 추가 단원을 참조하세요.

중요

버킷을 CloudFront와 함께 사용하려면 DNS 명명 요구 사항을 준수하는 이름을 사용해야 합니다. 자세한 내용은 Amazon Simple Storage Service 사용 설명서버킷 이름 지정 규칙을 참조하세요.

Amazon S3 버킷을 CloudFront의 원본으로 지정하는 경우 다음 형식을 사용하는 것이 좋습니다.

bucket-name.s3.region.amazonaws.com

이 형식으로 버킷 이름을 지정할 경우 다음 CloudFront 기능을 사용할 수 있습니다.

다음 형식을 사용하여 버킷을 지정하지 마세요.

  • Amazon S3 경로 형식: s3.amazonaws.com/bucket-name

  • Amazon S3 CNAME

웹 사이트 엔드포인트로 구성된 Amazon S3 버킷 사용

CloudFront를 사용하여 사용자 지정 원본으로서 웹 사이트 엔드포인트로 구성되는 Amazon S3 버킷을 사용할 수 있습니다. CloudFront 배포를 구성할 때 오리진의 경우 버킷에 대한 Amazon S3 정적 웹 사이트 호스팅 엔드포인트를 입력합니다. 이 값은 Amazon S3 콘솔에서 속성(Properties) 페이지의 정적 웹 사이트 호스팅(Static website hosting) 창에 나타납니다. 예:

http://bucket-name.s3-website-region.amazonaws.com

Amazon S3 정적 웹 사이트 엔드포인트 지정에 대한 자세한 내용은 Amazon Simple Storage Service 사용 설명서웹 사이트 엔드포인트를 참조하세요.

오리진으로서 이 형식으로 된 버킷 이름을 지정할 경우 Amazon S3 리디렉션과 Amazon S3 사용자 지정 오류 문서를 사용할 수 있습니다. 자세한 내용은 Amazon Simple Storage Service 사용 설명서사용자 지정 오류 문서 구성리디렉션 구성을 참조하세요. (CloudFront에서도 사용자 지정 오류 페이지를 제공합니다. 자세한 내용은 특정 HTTP 상태 코드에 대한 사용자 지정 오류 페이지 만들기 단원을 참조하세요.)

Amazon S3 버킷을 CloudFront 원본 서버로 사용해도 버킷은 변경되지 않습니다. 평소처럼 계속해서 사용할 수 있으며 정규 Amazon S3 요금이 발생합니다. CloudFront 사용을 위한 요금에 대한 자세한 내용은 Amazon CloudFront 요금을 참조하세요.

참고

CloudFront API를 사용하여 웹 사이트 엔드포인트로 구성되는 Amazon S3 버킷 포함 배포를 사용하는 경우 웹 사이트가 Amazon S3 버킷에서 호스팅된 경우에도 CustomOriginConfig를 사용하여 구성해야 합니다. CloudFront API를 사용하여 배포를 만드는 방법에 대한 자세한 내용은 Amazon CloudFront API 참조CreateDistribution을 참조하세요.

기존 Amazon S3 버킷에 CloudFront 추가

Amazon S3 버킷에 객체를 저장하는 경우 사용자에게 S3에서 객체를 직접 가져오게 할 수 있고, 아니면 S3에서 객체를 가져와 사용자들에게 배포하도록 CloudFront를 구성할 수 있습니다. 사용자가 객체에 자주 액세스하는 경우 CloudFront를 사용하는 것이 더 비용 효율적일 수 있습니다. 왜냐하면 사용량이 더 많은 경우에는 CloudFront 데이터 전송 가격이 Amazon S3 데이터 전송 가격보다 저렴하기 때문입니다. 또한 CloudFront를 함께 사용할 경우 객체가 사용자 측에 더 가깝게 저장되므로 다운로드 속도도 Amazon S3만 사용할 때보다 더 빠릅니다.

참고

CloudFront에서 Amazon S3 cross-origin 리소스 공유 설정을 지키도록 하려는 경우 Origin 헤더를 Amazon S3로 전달하도록 CloudFront를 구성합니다. 자세한 정보는 요청 헤더 기반의 콘텐츠 캐싱을 참조하십시오.

현재 Amazon S3 버킷(예: DOC-EXAMPLE-BUCKET.s3.us-west-2.amazonaws.com)을 사용하지 않고 고유 도메인 이름(예: example.com)을 사용하여 Amazon S3 버킷에서 콘텐츠를 직접 배포하는 경우, 다음 절차를 이용해 중단 없이 CloudFront를 추가할 수 있습니다.

Amazon S3에서 콘텐츠를 이미 배포하고 있는 경우 CloudFront를 추가하려면

  1. CloudFront 배포를 만듭니다. 자세한 정보는 배포 만들기 단계(개요)을 참조하십시오.

    배포를 생성할 때 Amazon S3 버킷의 이름을 오리진 서버로 지정합니다.

    중요

    버킷을 CloudFront와 함께 사용하려면 DNS 명명 요구 사항을 준수하는 이름을 사용해야 합니다. 자세한 내용은 Amazon Simple Storage Service 사용 설명서버킷 이름 지정 규칙을 참조하세요.

    Amazon S3에서 CNAME을 사용하려는 경우 배포에 대한 CNAME도 지정합니다.

  2. Amazon S3 버킷 안에 공개 읽기 가능 객체의 링크를 포함하는 테스트 웹 페이지를 생성하고 해당 링크를 테스트합니다. 이 초기 테스트에서는 객체 URL에서 배포의 CloudFront 도메인 이름을 사용합니다(예: https://d111111abcdef8.cloudfront.net/images/image.jpg).

    CloudFront URL의 형식에 대한 자세한 내용은 CloudFront에서 파일에 대한 URL 형식 사용자 지정 단원을 참조하세요.

  3. Amazon S3 CNAME을 사용할 경우 애플리케이션은 Amazon S3 버킷에서 객체를 참조할 때 버킷 이름(예: DOC-EXAMPLE-BUCKET.s3.amazonaws.com) 대신에 도메인 이름(예: example.com)을 사용합니다. 객체를 참조할 때 배포의 CloudFront 도메인 이름(예: d111111abcdef8.cloudfront.net) 대신에 고유 도메인 이름을 계속 사용하려면 설정을 해당 DNS 서비스 공급자로 업데이트해야 합니다.

    Amazon S3 CNAME이 작동하려면 DNS 서비스 공급자에게 고유한 도메인에 대한 CNAME 리소스 레코드 세트가 반드시 있어야 합니다. 이 리소스 레코드 세트는 현재 도메인에 대한 쿼리를 Amazon S3 버킷으로 라우팅합니다. 예를 들어 사용자가 이 객체를 요청하는 경우:

    https://example.com/images/image.jpg

    요청이 자동으로 재라우팅되어 사용자에게 표시되는 객체는 다음과 같습니다.

    https://DOC-EXAMPLE-BUCKET.s3.amazonaws.com/images/image.jpg

    쿼리를 Amazon S3 버킷 대신에 CloudFront 배포로 라우팅하려면 DNS 서비스 공급자가 제공하는 방법을 사용하여 도메인의 CNAME 리소스 레코드 세트를 업데이트해야 합니다. 이 업데이트된 CNAME 레코드가 DNS 쿼리를 고유 도메인에서 배포의 CloudFront 도메인 이름으로 리디렉션합니다. 자세한 내용은 DNS 서비스 공급자가 제공하는 설명서를 참조하십시오.

    참고

    Route 53을 DNS 서비스로 사용하는 경우 CNAME 리소스 레코드 세트 또는 별칭 리소스 레코드 세트를 사용할 수 있습니다. 리소스 레코드 세트 편집에 대한 자세한 내용은 레코드 편집을 참조하세요. 별칭 리소스 레코드 세트에 대한 자세한 내용은 별칭 및 비-별칭 레코드 간의 선택을 참조하세요. 두 주제는 모두 Amazon Route 53 개발자 안내서에 나와 있습니다.

    CloudFront에 CNAME 사용에 대한 자세한 내용은 대체 도메인 이름(CNAME)을 추가하여 파일에 대해 사용자 지정 URL 사용 단원을 참조하세요.

    일반적으로 더 빠를 수도 있지만 CNAME 리소스 레코드 세트를 업데이트한 후 DNS 시스템 전체에 변경 사항이 전파되는 데는 최대 72시간이 걸릴 수 있습니다. 이 시간 동안은 일부 콘텐츠 요청이 Amazon S3 버킷으로 계속 라우팅되며 그 밖의 요청은 CloudFront로 라우팅됩니다.

Amazon S3 버킷을 다른 AWS 리전으로 이동

Amazon S3를 CloudFront 배포에 대한 원본으로 사용하고 있고 버킷을 다른 AWS 리전으로 옮기는 경우, 다음 두 조건이 참일 때 CloudFront가 그 레코드를 업데이트하여 새 리전을 사용하는 데 최대 1시간이 걸릴 수 있습니다.

  • CloudFront 원본 액세스 ID(OAI)를 사용하여 버킷에 대한 액세스를 제한하고 있습니다.

  • 인증을 위해 서명 버전 4가 필요한 Amazon S3 리전으로 버킷을 옮깁니다.

OAI를 사용할 때 CloudFront는 그 리전(다른 값들 중에서)을 사용해 버킷에서 객체를 요청할 때 사용하는 서명을 계산합니다. OAI에 대한 자세한 내용은 원본 액세스 ID(OAI)를 사용하여 Amazon S3 콘텐츠에 대한 액세스 제한 단원을 참조하십시오. 서명 버전 2를 지원하는 AWS 리전의 목록은 Amazon Web Services 일반 참조서명 버전 2 서명 과정을 참조하세요.

CloudFront의 레코드에 대한 더 빠른 업데이트를 강제하려면, CloudFront 콘솔에서 일반(General) 탭의 설명(Comment) 필드를 업데이트하는 등의 작업을 통해 CloudFront 배포를 업데이트할 수 있습니다. 배포를 업데이트하는 경우 CloudFront는 버킷이 있는 리전을 즉시 확인합니다. 모든 엣지 로케이션에 변경 사항을 전파하는 데 몇 분 밖에 걸리지 않습니다.

MediaStore 컨테이너 또는 MediaPackage 채널 사용

CloudFront를 사용하여 비디오를 스트리밍하려면 MediaStore 컨테이너로 구성된 Amazon S3 버킷을 설정하거나 MediaPackage로 채널 및 엔드포인트를 생성할 수 있습니다. 그런 다음 CloudFront에서 배포를 만들고 구성하여 비디오를 스트리밍합니다.

자세한 내용 및 단계별 지침은 다음 단원을 참조하십시오.

Application Load Balancer 사용

원본이 하나 이상의 Amazon EC2 인스턴스에서 호스트되는 하나 이상의 HTTP 서버(웹 서버)인 경우 Application Load Balancer를 사용하여 인스턴스에 트래픽을 분산할 수 있습니다. 뷰어가 로드 밸런서에 직접 액세스하지 않고 CloudFront를 통해서만 웹 서버에 액세스할 수 있도록 하는 방법을 비롯하여 Application Load Balancer를 CloudFront의 원본으로 사용하는 방법에 대한 자세한 내용은 Application Load Balancer에 대한 액세스 제한 단원을 참조하세요.

Lambda 함수 URL 사용

Lambda 함수 URL은 AWS Lambda 함수를 위한 전용 HTTPS 엔드포인트입니다. Lambda 함수 URL을 사용하여 서버리스 웹 애플리케이션을 AWS Lambda 내에서 완전히 구축할 수 있습니다. API 게이트웨이 또는 Application Load Balancer와 통합할 필요 없이 함수 URL을 통해 Lambda 웹 애플리케이션을 직접 호출할 수 있습니다.

함수 URL이 포함된 Lambda 함수를 사용하여 서버리스 웹 애플리케이션을 구축하는 경우 CloudFront를 추가하여 다음과 같은 이점을 얻을 수 있습니다.

  • 콘텐츠를 뷰어에 더 가깝게 캐시하여 애플리케이션 속도 향상

  • 웹 애플리케이션에 대한 사용자 지정 도메인 이름 사용

  • CloudFront 캐시 동작을 사용하여 서로 다른 URL 경로를 서로 다른 Lambda 함수로 라우팅

  • CloudFront 지리적 제한 또는 AWS WAF(또는 둘 다)를 사용하여 특정 요청 차단

  • CloudFront에 AWS WAF를 사용하면 악성 봇으로부터 애플리케이션을 보호하고, 일반적인 애플리케이션 악용을 방지하며, DDoS 공격으로부터 보호를 강화할 수 있습니다.

Lambda 함수 URL을 CloudFront 배포의 원본으로 사용하려면 Lambda 함수 URL의 전체 도메인 이름을 원본 도메인으로 지정합니다. Lambda 함수 URL 도메인 이름은 다음 형식을 사용합니다.

function-URL-ID.lambda-url.AWS-Region.on.aws

CloudFront 배포의 원본으로 Lambda 함수 URL을 사용하는 경우 함수 URL에 공개적으로 액세스할 수 있도록 해야 합니다. 이렇게 하려면 함수 URL의 AuthType 파라미터를 NONE으로 설정하고 리소스 기반 정책에서 lambda:InvokeFunctionUrl 권한을 허용합니다. 자세한 내용은 AWS Lambda 개발자 가이드Using the NONE AuthType(NONE AuthType 사용)을 참조하세요. 한편, CloudFront가 원본으로 보내는 요청에 사용자 지정 원본 헤더를 추가하고 헤더가 요청에 없는 경우 오류 응답을 반환하는 함수 코드를 작성할 수도 있습니다. 이렇게 하면 Lambda 함수 URL을 직접 사용하지 않고 CloudFront를 통해서만 웹 애플리케이션에 액세스할 수 있습니다.

Lambda 함수 URL에 대한 자세한 내용은 AWS Lambda 개발자 가이드에서 다음 주제를 참조하세요.

  • Lambda 함수 URL - Lambda 함수 URL 기능에 대한 일반적인 개요

  • Lambda 함수 URL 호출 - 서버리스 웹 애플리케이션 코딩에 사용할 요청 및 응답 페이로드에 대한 세부 정보 포함

Amazon EC2(또는 기타 사용자 지정 원본) 사용

사용자 지정 오리진은 웹 서버와 같은 HTTP 서버입니다. HTTP 서버는 Amazon EC2 인스턴스 또는 다른 곳에서 호스트하는 HTTP 서버가 될 수 있습니다. 웹 사이트 엔드포인트로서 구성된 Amazon S3 오리진은 또한 사용자 지정 오리진으로 간주됩니다.

고유 HTTP 서버를 사용자 지정 원본으로 사용하는 경우 서버의 DNS 이름, HTTP 및 HTTPS 포트, 원본에서 객체를 가져올 때 CloudFront에서 사용하려는 프로토콜을 지정합니다.

사용자 지정 원본을 사용할 경우 비공개 콘텐츠를 제외하고 대부분의 CloudFront 기능이 지원됩니다. 서명된 URL을 사용하여 사용자 지정 원본으로부터 콘텐츠를 배포할 수는 있지만, CloudFront에서 사용자 지정 원본을 액세스하려면 원본이 공개적으로 액세스 가능한 상태여야 합니다. 자세한 정보는 서명된 URL과 서명된 쿠키를 사용하여 프라이빗 콘텐츠 제공을 참조하십시오.

CloudFront를 통한 Amazon EC2 인스턴스 및 기타 사용자 지정 오리진 사용에 대한 이러한 지침을 따르세요.

  • 동일한 CloudFront 오리진에 대한 콘텐츠를 서비스하는 모든 서버의 동일한 콘텐츠를 호스팅 및 서비스합니다. 자세한 내용은 오리진 설정 주제에서 배포를 만들거나 업데이트할 때 지정하는 값 단원을 참조하세요.

  • AWS Support 또는 CloudFront에서 이 값을 디버깅에 사용해야 할 경우 모든 서버에 X-Amz-Cf-Id 헤더 항목을 로그합니다.

  • 사용자 지정 원본이 수신 대기하는 HTTP 및 HTTPS 포트에 대한 요청을 제한합니다.

  • 구현 시 모든 서버의 클록을 동기화합니다. CloudFront는 로그 및 보고용으로 서명된 URL 및 서명된 쿠키에 대해 UTC(협정 세계시)를 사용합니다. 또한 CloudWatch 지표를 사용하여 CloudFront 활동을 모니터링하는 경우 CloudWatch에서도 UTC를 사용한다는 점에 유의하세요.

  • 이중화 서버를 사용하여 오류를 처리합니다.

  • 프라이빗 콘텐츠를 제공하기 위한 사용자 지정 오리진 사용에 대한 자세한 내용은 사용자 지정 오리진의 파일에 대한 액세스 제한을 참조하십시오.

  • 요청 및 응답 동작과 지원되는 HTTP 상태 코드에 대한 자세한 내용은 요청 및 응답 동작 단원을 참조하십시오.

Amazon EC2를 사용자 지정 원본으로 사용하는 경우 다음을 수행하는 것이 좋습니다.

  • 웹 서버용 소프트웨어를 자동으로 설치하는 Amazon Machine Image를 사용합니다. 자세한 내용은 Amazon EC2 설명서를 참조하세요.

  • Elastic Load Balancing 로드 밸런서를 사용하여 여러 Amazon EC2 인스턴스 간 트래픽을 처리하고 Amazon EC2 인스턴스에 대한 변경으로부터 애플리케이션을 격리할 수 있습니다. 예를 들어, 로드 밸런서를 사용하는 경우 애플리케이션을 변경하지 않고도 Amazon EC2 인스턴스를 추가 및 삭제할 수 있습니다. 자세한 내용은 Elastic Load Balancing 설명서를 참조하세요.

  • CloudFront 배포를 생성할 때 오리진 서버의 도메인 이름으로 로드 밸런서의 URL을 지정합니다. 자세한 정보는 배포 생성을 참조하십시오.

CloudFront 오리진 그룹 사용

예를 들어 고가용성이 필요할 때 시나리오에 대한 오리진 장애 조치를 구성하려면 CloudFront 오리진에 대한 오리진 그룹을 지정할 수 있습니다. 오리진 장애 조치를 사용하여 CloudFront에 대한 기본 오리진과, 기본 오리진이 특정 HTTP 상태 코드 실패 응답을 반환할 때 CloudFront가 자동으로 전환하는 두 번째 오리진을 지정합니다.

원본 그룹을 설정하는 단계를 비롯한 자세한 내용은 CloudFront 오리진 장애 조치를 통한 고가용성 최적화 단원을 참조하세요.