# 배포 구성
<a name="distribution-working-with"></a>

Amazon CloudFront 배포를 생성하여 CloudFront에 어디로부터 콘텐츠를 전송하고자 하는지와 이러한 콘텐츠 전송을 추적 및 관리하는 방법에 대한 세부 정보를 알립니다.

CloudFront 배포를 만들면 CloudFront가 콘텐츠 오리진 유형에 따라 대부분의 배포 설정을 자동으로 구성합니다. 재구성 설정에 대한 자세한 내용은 [사전 구성된 배포 설정 참조](template-preconfigured-origin-settings.md) 섹션을 참조하시기 바랍니다. 선택적으로 배포 설정을 수동으로 편집하도록 선택할 수 있습니다. 자세한 내용은 [모든 배포 설정 참조](distribution-web-values-specify.md) 섹션을 참조하세요.

다음과 같은 설정을 구성할 수 있습니다.
+ **콘텐츠 오리진** - CloudFront가 배포할 파일을 가져오는 Amazon S3 버킷, AWS Elemental MediaPackage 채널, AWS Elemental MediaStore 컨테이너, Elastic Load Balancing 로드 밸런서 또는 HTTP 서버. 배포당 최대 25개 오리진의 조합을 지정할 수 있습니다.
+ **액세스** - 파일을 모든 사람이 사용할 수 있도록 할지 아니면 일부 사용자로만 액세스를 제한할지 여부
+ **보안** - AWS WAF 보호를 활성화하고 사용자가 HTTPS를 사용하여 콘텐츠에 액세스하도록 지정할지 여부 다중 테넌트 배포의 경우 AWS WAF V2 웹 액세스 제어 목록(ACL)만 지원됩니다.
+ **캐시 키** - *캐시 키*에 포함할 값(있는 경우) 캐시 키는 지정된 배포에 대한 캐시의 각 파일을 고유하게 식별합니다.
+ **오리진 요청 설정** - CloudFront가 오리진에 전송하는 요청에 HTTP 헤더, 쿠키 또는 쿼리 문자열을 포함할지 여부
+ **지리적 제한** - CloudFront에서 특정 국가의 사용자가 콘텐츠에 액세스하는 것을 차단할지 여부
+ **로그** - CloudFront가 뷰어 활동을 표시하는 표준 로그 또는 실시간 액세스 로그를 생성할지 여부입니다.

자세한 내용은 [모든 배포 설정 참조](distribution-web-values-specify.md) 섹션을 참조하세요.

현재 각 AWS 계정에 대해 생성할 수 있는 배포의 최대 수는 [배포의 일반 할당량](cloudfront-limits.md#limits-web-distributions) 섹션을 참조하세요. 배포당 제공할 수 있는 최대 파일 수는 없습니다.

배포를 사용하여 HTTP 또는 HTTPS를 통해 다음 콘텐츠를 제공할 수 있습니다.
+ HTTP 또는 HTTPS를 사용하는 정적 및 동적 다운로드 콘텐츠입니다(예: HTML, CSS, JavaScript 및 이미지 파일).
+ Apple HTTP Live Streaming(HLS) 및 Microsoft Smooth Streaming 등과 같은 다양한 형식의 온디맨드 비디오. (다중 테넌트 배포의 경우 스무스 스트리밍이 지원되지 않음) 자세한 내용은 [CloudFront를 사용한 온디맨드 비디오 제공](on-demand-video.md) 섹션을 참조하세요.
+ 실시간으로 발생하는 모임, 회의 또는 콘서트 같은 라이브 이벤트 제공. 라이브 스트리밍의 경우 CloudFormation 스택을 사용하여 배포를 자동으로 생성할 수 있습니다. 자세한 내용은 [CloudFront 및 AWS Media Services를 사용하여 동영상 스트리밍 제공](live-streaming.md) 섹션을 참조하세요.

다음 주제에서는 CloudFront 배포에 대한 자세한 내용과 해당 비즈니스 요건에 맞게 배포를 구성하는 방법을 제공합니다. 배포 생성에 대한 자세한 내용은 [배포 생성](distribution-web-creating-console.md) 단원을 참조하세요.

**Topics**
+ [다중 테넌트 배포의 작동 방식 이해](distribution-config-options.md)
+ [배포 생성](distribution-web-creating-console.md)
+ [사전 구성된 배포 설정 참조](template-preconfigured-origin-settings.md)
+ [모든 배포 설정 참조](distribution-web-values-specify.md)
+ [배포 테스트](distribution-web-testing.md)
+ [배포 업데이트](HowToUpdateDistribution.md)
+ [배포 태깅](tagging.md)
+ [배포 삭제](HowToDeleteDistribution.md)
+ [CloudFront 배포에 다양한 오리진 사용](DownloadDistS3AndCustomOrigins.md)
+ [CloudFront 배포에 IPv6 활성화](cloudfront-enable-ipv6.md)
+ [CloudFront 지속적 배포를 사용하여 CDN 구성 변경을 안전하게 테스트](continuous-deployment.md)
+ [대체 도메인 이름(CNAME)을 추가하여 사용자 지정 URL 사용](CNAMEs.md)
+ [CloudFront 배포에 WebSocket 사용](distribution-working-with.websockets.md)
+ [허용 목록에 사용할 애니캐스트 고정 IP 요청](request-static-ips.md)
+ [CloudFront 배포에 gRPC 사용](distribution-using-grpc.md)

# 다중 테넌트 배포의 작동 방식 이해
<a name="distribution-config-options"></a>

여러 배포 테넌트에서 재사용할 수 있는 설정을 사용하여 CloudFront 다중 테넌트 배포를 만들 수 있습니다. 다중 테넌트 배포를 사용하면 CloudFront가 콘텐츠 오리진 유형에 따라 배포 설정을 구성하도록 할 수 있습니다. 재구성 설정에 대한 자세한 내용은 [사전 구성된 배포 설정 참조](template-preconfigured-origin-settings.md) 섹션을 참조하시기 바랍니다.

표준 배포 대신 다중 테넌트 배포를 사용하면 다음과 같은 이점이 있습니다.
+ 운영 부담을 줄입니다.
+ 웹 관리자 및 소프트웨어 공급자가 최종 사용자에게 콘텐츠를 제공하는 여러 웹 애플리케이션에서 CloudFront 배포를 관리하기 위한 재사용 가능한 구성입니다.
+ 자동화된 인증서 관리, 통합 보안 제어 및 규모에 맞는 간편한 구성 제어를 제공하기 위해 다른 AWS 서비스와의 통합을 개선했습니다.
+ 구현 전반에 걸쳐 일관된 리소스 패턴을 유지합니다. 공유해야 하는 설정을 정의한 다음, 재정의할 설정을 사용자 지정합니다.
+ 배포 테넌트 수준에서 특정 요구 사항을 충족하도록 사용자 지정 가능한 오리진 및 보안 설정입니다.
+ 배포 테넌트를 서로 다른 계층에 정리합니다. 예를 들어 일부 배포 테넌트에 Origin Shield가 필요하고 일부는 필요하지 않은 경우 배포 테넌트를 서로 다른 다중 테넌트 배포로 그룹화할 수 있습니다.
+ 여러 도메인에서 공통 DNS 구성을 공유합니다.

표준 배포와 달리 다중 테넌트 배포에는 CloudFront 라우팅 엔드포인트가 없으므로 직접 액세스할 수 없습니다. 따라서 연결 그룹 및 하나 이상의 배포 테넌트와 함께 사용해야 합니다. 표준 배포에는 자체 CloudFront 엔드포인트가 있으며 최종 사용자가 직접 액세스할 수 있지만 템플릿으로 다른 배포에 사용할 수 없습니다.

다중 테넌트 배포 할당량에 대한 자세한 내용은 [다중 테넌트 배포의 할당량](cloudfront-limits.md#limits-template) 섹션을 참조하시기 바랍니다.

**Topics**
+ [작동 방식](#how-template-distribution-works)
+ [용어](#template-distributions-concepts)
+ [지원되지 않는 기능](#unsupported-saas)
+ [배포 테넌트 사용자 지정](tenant-customization.md)
+ [CloudFront 배포 테넌트에 대한 인증서 요청](managed-cloudfront-certificates.md)
+ [사용자 지정 연결 그룹 생성(선택 사항)](custom-connection-group.md)
+ [다중 테넌트 배포로 마이그레이션](template-migrate-distribution.md)

## 작동 방식
<a name="how-template-distribution-works"></a>

*표준 배포*의 배포에는 오리진 구성, 캐시 동작, 보안 설정 등 웹 사이트 또는 애플리케이션에서 사용 설정하려는 모든 설정이 포함됩니다. 별도의 웹 사이트를 만들고 동일한 설정을 많이 사용하려면 매번 새 배포를 만들어야 합니다.

CloudFront 다중 테넌트 배포는 초기 다중 테넌트 배포를 만들 수 있다는 점에서 다릅니다. 각 새 웹 사이트에서 소스 배포의 정의된 값을 자동으로 상속하는 배포 테넌트를 만듭니다. 그런 다음 배포 테넌트에 대한 특정 설정을 사용자 지정합니다.

**개요**

1. 시작하려면 먼저 다중 테넌트 배포를 만듭니다. CloudFront는 콘텐츠 오리진 유형에 따라 배포 설정을 구성합니다. VPC 오리진을 제외한 모든 오리진에서 설정을 사용자 지정할 수 있습니다. VPC 오리진 설정은 VPC 오리진 리소스 자체에서 사용자 지정됩니다. 사용자 지정할 수 있는 다중 테넌트 배포 설정에 대한 자세한 내용은 [사전 구성된 배포 설정 참조](template-preconfigured-origin-settings.md) 섹션을 참조하시기 바랍니다.
   + 다중 테넌트 배포에 사용하는 TLS 인증서는 배포 테넌트에서 상속될 수 있습니다. 다중 테넌트 배포 자체는 라우팅할 수 없으므로 연결된 도메인 이름이 없습니다.

1. 기본적으로 CloudFront에서는 연결 그룹을 만듭니다. 연결 그룹은 콘텐츠에 대한 뷰어 요청이 CloudFront에 연결되는 방식을 제어합니다. 연결 그룹에서 일부 라우팅 설정을 사용자 지정할 수 있습니다.

   연결 그룹을 직접 수동으로 만들어 이를 변경할 수 있습니다. 자세한 내용은 [사용자 지정 연결 그룹 생성(선택 사항)](custom-connection-group.md) 섹션을 참조하세요.

1. 그런 다음 하나 이상의 배포 테넌트를 만듭니다. 배포 테넌트는 뷰어가 콘텐츠에 액세스할 수 있는 '출입구'입니다. 각 배포 테넌트는 다중 테넌트 배포를 참조하며 CloudFront에서 만든 연결 그룹과 자동으로 연결됩니다. 배포 테넌트는 개별 도메인 또는 하위 도메인을 지원합니다.

1. 그런 다음 가상 도메인 및 오리진 경로 등 일부 배포 테넌트 설정을 사용자 지정할 수 있습니다. 자세한 내용은 [배포 테넌트 사용자 지정](tenant-customization.md) 섹션을 참조하세요.

1. 마지막으로 DNS 호스트의 DNS 레코드를 업데이트하여 트래픽을 배포 테넌트로 라우팅해야 합니다. 이렇게 하려면 연결 그룹에서 CloudFront 엔드포인트 값을 가져오고 CloudFront 엔드포인트를 가리키는 CNAME 레코드를 만듭니다.

**Example 예제**  
다음 그래픽은 다중 테넌트 배포, 배포 테넌트, 연결 그룹이 함께 작동하여 여러 도메인의 뷰어에게 콘텐츠를 제공하는 방법을 보여줍니다.  

1. 다중 테넌트 배포는 각 배포 테넌트에서 상속된 설정을 정의합니다. 다중 테넌트 배포를 템플릿으로 사용합니다.

1. 다중 테넌트 배포에서 만든 각 배포 테넌트에는 자체 도메인이 있습니다.

1. 배포 테넌트는 다중 테넌트 배포를 만들 때 CloudFront에서 만든 연결 그룹에 자동으로 추가됩니다. 연결 그룹은 뷰어 요청이 CloudFront 네트워크에 연결되는 방식을 제어합니다.

![\[다중 테넌트 배포가 배포 테넌트와 작동하는 방식.\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/images/template_distribution.png)


자세한 다중 테넌트 배포 만들기 설명은 [콘솔에서 CloudFront 배포 생성](distribution-web-creating-console.md#create-console-distribution) 섹션을 참조하시기 바랍니다.

## 용어
<a name="template-distributions-concepts"></a>

다음 개념은 다중 테넌트 배포의 구성 요소를 설명합니다.

**다중 테넌트 배포**  
캐시 동작, 보안 보호 및 오리진을 포함하여 모든 배포 테넌트에 대한 모든 공유 구성 설정을 지정하는 블루프린트 멀티 테넌트 배포입니다. 다중 테넌트 배포는 트래픽을 직접 제공할 수 없습니다. 연결 그룹 및 배포 테넌트와 함께 사용해야 합니다.

**표준 배포**  
다중 테넌트 기능이 없는 배포입니다. 이러한 배포는 단일 웹 사이트 또는 앱을 지원하는 데 가장 적합합니다.

**배포 테넌트**  
배포 테넌트는 다중 테넌트 배포 구성을 상속합니다. 일부 구성 설정은 배포 테넌트 수준에서 사용자 지정할 수 있습니다. 배포 테넌트 도메인 또는 하위 도메인을 포함하면 배포 테넌트에는 다중 테넌트 배포에서 상속할 수 있는 유효한 TLS 인증서가 있어야 합니다.  
배포 테넌트는 연결 그룹과 연결되어야 합니다. CloudFront는 배포 테넌트를 만들 때 연결 그룹을 만들고 해당 연결 그룹에 배포 테넌트를 자동으로 할당합니다.

**멀티테넌시**  
구성과 인프라를 공유하면서 다중 테넌트 배포를 사용하여 여러 도메인의 콘텐츠를 제공할 수 있습니다. 이 접근 방식을 사용하면 여러 도메인(테넌트라고 함)이 자체 사용자 지정을 유지하면서 다중 테넌트 배포의 공통 설정을 공유할 수 있습니다.

**연결 그룹**  
뷰어에게 콘텐츠를 제공하는 CloudFront 라우팅 엔드포인트를 제공합니다. 배포 테넌트 도메인 또는 하위 도메인에 대해 만든 CNAME 레코드에 해당하는 CloudFront 라우팅 엔드포인트를 가져오려면 각 배포 테넌트를 연결 그룹에 연결해야 합니다. 연결 그룹은 여러 배포 테넌트 간에 공유할 수 있습니다. 연결 그룹은 IPv6 및 애니캐스트 IP 목록 설정 등의 배포 테넌트의 라우팅 설정을 관리합니다.

**파라미터**  
오리진 경로 및 도메인 이름과 같은 자리 표시자 값의 키-값 페어 목록입니다. 다중 테넌트 배포에서 파라미터를 정의하고 배포 테넌트 수준에서 해당 파라미터의 값을 제공할 수 있습니다. 배포 테넌트에 파라미터 값을 입력해야 하는지 여부를 선택합니다.  
배포 테넌트에서 선택 사항 파라미터 값을 제공하지 않으면 다중 테넌트 배포의 기본값이 값으로 사용됩니다.

**CloudFront 라우팅 엔드포인트**  
연결 그룹의 표준 DNS입니다(예: `d123.cloudfront.net`). 배포 테넌트 도메인 또는 하위 도메인의 CNAME 레코드에 사용됩니다.

**사용자 지정**  
배포 테넌트가 다중 테넌트 배포와 *다른* 설정을 사용하도록 사용자 지정할 수 있습니다. 각 배포 테넌트에서 다른 AWS WAF 웹 액세스 제어 목록(ACL), TLS 인증서 및 지리적 제한 사항을 지정할 수 있습니다.

## 지원되지 않는 기능
<a name="unsupported-saas"></a>

다음 기능은 다중 테넌트 배포에 사용할 수 없습니다. 표준 배포와 동일한 설정을 사용하여 새 멀티 테넌트 배포를 만들면 일부 설정을 사용할 수 없으니 참고하시기 바랍니다.

**참고**  
현재 AWS Firewall Manager 정책은 표준 배포에만 적용됩니다. Firewall Manager는 향후 릴리스에서 다중 테넌트 배포에 대한 지원을 추가할 예정입니다.
표준 배포와 달리 *배포 테넌트* 수준에서 도메인 이름(별칭)을 지정합니다. 자세한 내용은 [CloudFront 배포 테넌트에 대한 인증서 요청](managed-cloudfront-certificates.md) 및 [CreateDistributionTenant](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistributionTenant.html) API 작업을 확인하시기 바랍니다.
+ [지속적 배포](continuous-deployment.md)
+ [오리진 액세스 ID(OAI)](private-content-restricting-access-to-s3.md#private-content-restricting-access-to-s3-oai) - [오리진 액세스 제어(OAC)](private-content-restricting-access-to-origin.md)를 대신 사용합니다.
+ [전용 IP 사용자 지정 SSL 지원](DownloadDistValuesGeneral.md#DownloadDistValuesClientsSupported) - `sni-only` 메서드만 지원됩니다.
+ [AWS WAF 클래식(V1) 웹 ACL](DownloadDistValuesGeneral.md#DownloadDistValuesWAFWebACL) - AWS WAF V2 웹 ACL만 지원됩니다.
+ [표준 로깅(레거시)](standard-logging-legacy-s3.md)
+ [최소 TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL)
+ [기본 TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesDefaultTTL)
+ [최대 TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL)
+ [ForwardedValues](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ForwardedValues.html)
+ [PriceClass](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html)
+ [신뢰할 수 있는 서명자 ](DownloadDistValuesCacheBehavior.md#DownloadDistValuesTrustedSigners)
+ [스무스 스트리밍](DownloadDistValuesCacheBehavior.md#DownloadDistValuesSmoothStreaming)
+ [AWS Identity and Access Management(IAM) 서버 인증서](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_server-certs.html)
+ [전용 IP 주소](cnames-https-dedicated-ip-or-sni.md#cnames-https-dedicated-ip)
+ [최소 프로토콜 버전 SSLv3](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy)

다음 설정은 다중 테넌트 배포 또는 배포 테넌트에서 구성할 수 없습니다. 대신 연결 그룹에서 원하는 값을 설정합니다. 연결 그룹에 연결된 모든 배포 테넌트는 이러한 설정을 사용합니다. 자세한 내용은 [사용자 지정 연결 그룹 생성(선택 사항)](custom-connection-group.md) 섹션을 참조하세요.
+ [IPv6 활성화(뷰어 요청)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6)
+ [애니캐스트 고정 IP 목록](request-static-ips.md)

# 배포 테넌트 사용자 지정
<a name="tenant-customization"></a>

다중 테넌트 배포를 사용하는 경우 배포 테넌트는 다중 테넌트 배포 구성을 상속합니다. 하지만 배포 테넌트 수준에서 일부 설정을 사용자 지정할 수 있습니다.

다음을 사용자 지정할 수 있습니다.
+ **파라미터** - 파라미터는 오리진 도메인 또는 원본 경로에 사용할 수 있는 키-값 페어입니다. [파라미터가 배포 테넌트와 작동하는 방식](#tenant-customize-parameters)을(를) 참조하세요.
+ **AWS WAF 웹 ACL(V2)** - 배포 테넌트에 대해 별도의 웹 ACL을 지정할 수 있습니다. 그러면 다중 테넌트 배포에 사용되는 웹 ACL이 *재정의*됩니다. 특정 배포 테넌트에 대해 이 설정을 사용 해제할 수도 있습니다. 즉, 배포 테넌트는 다중 테넌트 배포에서 웹 ACL 보호를 상속하지 않습니다. 자세한 내용은 [AWS WAF 웹 ACL](DownloadDistValuesGeneral.md#DownloadDistValuesWAFWebACL) 섹션을 참조하세요.
+ **지리적 제한 **- 배포 테넌트에 지정하는 지리적 제한은 다중 테넌트 배포에 대한 모든 지리적 제한을 *재정의*합니다. 예를 들어 다중 테넌트 배포에서 독일(DE)을 차단하면 모든 연결된 배포 테넌트도 DE를 차단합니다. 그러나 특정 배포 테넌트에 대해 DE를 허용하면 해당 배포 테넌트 설정이 다중 테넌트 배포에 대한 설정을 재정의합니다. 자세한 내용은 [콘텐츠의 지리적 배포 제한](georestrictions.md) 섹션을 참조하세요.
+ **무효화 경로 **- 배포 테넌트에 대해 무효화하려는 콘텐츠의 파일 경로를 지정합니다. 자세한 내용은 [파일 무효화](Invalidation_Requests.md) 섹션을 참조하세요.
+ **사용자 지정 TLS 인증서** - 배포 테넌트에 지정하는 AWS Certificate Manager(ACM) 인증서는 다중 테넌트 배포에 제공된 인증서를 보완합니다. 하지만 동일한 도메인이 다중 테넌트 배포 및 배포 테넌트 인증서 모두에 포함되는 경우 테넌트 인증서가 사용됩니다. 자세한 내용은 [CloudFront 배포 테넌트에 대한 인증서 요청](managed-cloudfront-certificates.md) 섹션을 참조하세요.
+ **도메인 이름** - 배포 테넌트당 하나 이상의 도메인 이름을 지정해야 합니다.

## 파라미터가 배포 테넌트와 작동하는 방식
<a name="tenant-customize-parameters"></a>

파라미터는 자리 표시자 값에 사용할 수 있는 키-값 페어입니다. 다중 테넌트 배포에 사용할 파라미터를 정의하고 필요 여부를 지정합니다.

다중 테넌트 배포에서 파라미터를 정의할 때 해당 파라미터를 배포 테넌트 수준에서 입력해야 하는지 여부를 선택합니다.
+ 다중 테넌트 배포에서 *필요*에 따라 파라미터를 정의하는 경우 배포 테넌트 수준에서 입력해야 합니다. (상속되지 않음)
+ 파라미터가 *필요하지 않은* 경우 배포 테넌트에서 상속된 다중 테넌트 배포에 기본값을 제공할 수 있습니다.

다음 속성에 파라미터를 사용할 수 있습니다.
+ 오리진 도메인 이름
+ 오리진 경로

다중 테넌트 배포에서는 위의 각 속성에 대해 최대 2개의 파라미터를 정의할 수 있습니다.

## 파라미터 예시
<a name="examples-parameters"></a>

도메인 이름 및 오리진 경로에 파라미터를 사용하려면 다음 예시를 참조하세요.

**도메인 이름 파라미터**

다중 테넌트 배포 구성에서 다음 예시와 같이 오리진 도메인 이름에 대한 파라미터를 정의할 수 있습니다.

**Amazon S3**
+ `{{parameter1}}.amzn-s3-demo-logging-bucket.s3.us-east-1.amazonaws.com`
+ `{{parameter1}}–amzn-s3-demo-logging-bucket.s3.us-east-1.amazonaws.com`

**사용자 지정 오리진**
+ `{{parameter1}}.lambda-url.us-east-1.on.aws`
+ `{{parameter1}}.mediapackagev2.ap-south-1.amazonaws.com`

배포 테넌트를 생성할 때 `parameter1`에 사용할 값을 지정합니다.

```
"Parameters": [
  {
    "Name": "parameter1",
    "Value": "mycompany-website"
  }
]
```

다중 테넌트 배포에 지정된 이전 예시를 사용하면 배포 테넌트의 오리진 도메인 이름이 다음으로 확인됩니다.
+ `mycompany-website.amzn-s3-demo-bucket3.s3.us-east-1.amazonaws.com`
+ `mycompany-website–amzn-s3-demo-bucket3.s3.us-east-1.amazonaws.com`
+ `mycompany-website.lambda-url.us-east-1.on.aws`
+ `mycompany-website.mediapackagev2.ap-south-1.amazonaws.com`

**오리진 경로 파라미터**

마찬가지로 다음 예시와 같이 다중 테넌트 배포에서 오리진 경로에 대한 파라미터를 정의할 수 있습니다.
+ `/{{parameter2}}`
+ `/{{parameter2}}/test`
+ `/public/{{parameter2}}/test`
+ `/search?name={{parameter2}}`

배포 테넌트를 생성할 때 `parameter2`에 사용할 값을 지정합니다.

```
"Parameters": [
  {
    "Name": "parameter2",
    "Value": "myBrand"
  }
]
```

다중 테넌트 배포에 지정된 이전 예시를 사용하면 배포 테넌트의 오리진 경로가 다음으로 확인됩니다.
+ `/myBrand`
+ `/myBrand/test`
+ `/public/myBrand/test`
+ `/search?name=myBrand`



**Example 예제**  
고객을 위해 여러 웹 사이트(테넌트)를 만들려는 경우 각 배포 테넌트 리소스가 올바른 값을 사용하는지 확인해야 합니다.  

1. 다중 테넌트 배포를 만들고 배포 테넌트 구성에 2개의 파라미터를 포함합니다.

1. 오리진 도메인 이름에서 *customer-name*이라는 파라미터를 만들고 필수로 지정합니다. S3 버킷 앞에 파라미터를 입력하면 다음과 같이 표시됩니다.

   `{{customer-name}}.amzn-s3-demo-bucket3.s3.us-east-1.amazonaws.com`.

1. 오리진 경로에서 *my-theme*이라는 두 번째 파라미터를 만들고 기본값이 *기본*인 선택 사항을 지정합니다. 오리진 경로는 `/{{my-theme}}`으로 표시됩니다.

1. 배포 테넌트를 만들 때는 다음과 같이 합니다.
   + 도메인 이름의 경우 다중 테넌트 배포에서 필수로 표시되는 *customer-name*의 값을 지정해야 합니다.
   + 오리진 경로의 경우 선택적으로 *my-theme*의 값을 지정하거나 기본값을 사용할 수 있습니다.

# CloudFront 배포 테넌트에 대한 인증서 요청
<a name="managed-cloudfront-certificates"></a>

배포 테넌트를 만들면 테넌트는 다중 테넌트 배포에서 공유 AWS Certificate Manager(ACM) 인증서를 상속합니다. 이 공유 인증서는 다중 테넌트 배포와 연결된 모든 테넌트에 HTTPS를 제공합니다.

CloudFront 배포 테넌트를 만들거나 업데이트하여 도메인을 추가할 때 ACM에서 관리형 CloudFront 인증서를 추가할 수 있습니다. 그런 다음 CloudFront는 사용자를 대신하여 ACM에서 HTTP 검증 인증서를 가져옵니다. 이 테넌트 수준 ACM 인증서를 사용자 지정 도메인 구성에 사용할 수 있습니다. CloudFront는 갱신 워크플로를 간소화하여 인증서를 최신 상태로 유지하고 콘텐츠 전송을 중단 없이 보호합니다.

**참고**  
인증서를 소유하고 있지만 CloudFront 리소스*에만* 사용할 수 있으며 프라이빗 키는 내보낼 수 *없습니다*.

배포 테넌트를 만들거나 업데이트할 때 인증서를 요청할 수 있습니다.

**Topics**
+ [도메인 및 인증서 추가(분산 테넌트)](#vanity-domain-tls-tenant)
+ [도메인 설정 완료](#complete-domain-ownership)
+ [도메인을 CloudFront로 가리키기](#point-domains-to-cloudfront)
+ [도메인 고려 사항(배포 테넌트)](#tenant-domain-considerations)
+ [와일드카드 도메인(배포 테넌트)](#tenant-wildcard-domains)

## 도메인 및 인증서 추가(분산 테넌트)
<a name="vanity-domain-tls-tenant"></a>

다음 절차에서는 도메인을 추가하고 배포 테넌트의 인증서를 업데이트하는 방법을 보여줍니다.

**도메인 및 인증서를 추가하려면(배포 테넌트) 다음과 같이 합니다.**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. **SaaS**에서 **배포 테넌트**를 선택합니다.

1. 배포 테넌트를 검색합니다. 검색 창의 드롭다운 메뉴를 사용하여 도메인, 이름, 배포 ID, 인증서 ID, 연결 그룹 ID 또는 웹 ACL ID를 기준으로 필터링합니다.

1. 배포 테넌트 이름을 선택합니다.

1. **도메인**에서 **도메인 관리**를 선택합니다.

1. **인증서**에서 배포 테넌트에 대한 **사용자 지정 TLS 인증서**를 원하는지 선택합니다. 인증서는 도메인 이름을 사용할 권한이 있는지 확인합니다. 미국 동부(버지니아 북부) 리전에서 인증서를 가져와야 합니다.

1. **도메인**에서 **도메인 추가**를 선택하고 도메인 이름을 입력합니다. 도메인에 따라 입력한 도메인 이름 아래에 다음 메시지가 표시됩니다.
   + 이 도메인은 인증서의 적용을 받습니다.
   + 이 도메인은 검증 보류 중인 인증서의 적용을 받습니다.
   + 이 도메인은 인증서의 적용을 받지 않습니다. (즉, 도메인 소유권을 확인해야 합니다.)

1. **배포 테넌트 업데이트**를 선택합니다.

   테넌트 세부 정보 페이지의 **도메인**에서 다음 필드를 볼 수 있습니다.
   + **도메인 소유권** - 도메인 소유권의 상태입니다. CloudFront가 콘텐츠를 제공할 수 있으려면 먼저 TLS 인증서 검증을 사용하여 도메인 소유권을 확인해야 합니다.
   + **DNS 상태** - 트래픽을 올바르게 라우팅하려면 도메인의 DNS 레코드가 CloudFront를 가리켜야 합니다.

1. 도메인 소유권이 확인되지 않은 경우 테넌트 세부 정보 페이지의 **도메인**에서 **도메인 설정 완료**를 선택한 다음, 다음 절차를 완료하여 DNS 레코드가 CloudFront 도메인 이름을 가리키도록 합니다.

## 도메인 설정 완료
<a name="complete-domain-ownership"></a>

다음 절차에 따라 배포 테넌트의 도메인을 소유하고 있는지 확인합니다. 도메인에 따라 다음 절차 중 하나를 선택합니다.

**참고**  
도메인이 이미 Amazon Route 53 별칭 레코드가 있는 CloudFront를 가리키는 경우 도메인 이름 앞에 `_cf-challenge.`를 사용하여 DNS TXT 레코드를 추가해야 합니다. 이 TXT 레코드는 도메인 이름이 CloudFront에 연결되어 있는지 확인합니다. 각 도메인에 대해 이 단계를 반복합니다. 다음은 TXT 레코드를 업데이트하는 방법을 보여줍니다.  
레코드 이름: `_cf-challenge.DomainName`
레코드 유형: `TXT`
레코드 값: `CloudFrontRoutingEndpoint`
예를 들어 TXT 레코드는 `_cf-challenge.example.com TXT d111111abcdef8.cloudfront.net`과 같을 수 있습니다.  
CloudFront 라우팅 엔드포인트는 콘솔의 배포 테넌트 세부 정보 페이지에서 찾거나 *Amazon CloudFront API 참조*의 [ListConnectionGroups](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListConnectionGroups.html) API 작업을 사용하여 찾을 수 있습니다.

**작은 정보**  
SaaS 공급자이고 고객(테넌트)이 DNS에 TXT 레코드를 직접 추가할 필요 없이 인증서를 발급하도록 허용하려면 다음을 수행합니다.  
도메인 `example-saas-provider.com`을 소유한 경우 `customer-123.example-saas-provider.com`과 같이 테넌트에 하위 도메인을 할당합니다.
DNS에서 DNS 구성에 `_cf-challenge.customer-123.example-saas-provider.com TXT d111111abcdef8.cloudfront.net` TXT 레코드를 추가합니다.
그런 다음 고객(테넌트)은 자체 DNS 레코드를 업데이트하여 도메인 이름을 제공된 하위 도메인에 매핑할 수 있습니다.  
`www.customer-domain.com CNAME customer-123.example-saas-provider.com`

------
#### [ I have existing traffic ]

도메인이 가동 중지 시간을 허용할 수 없는 경우 이 옵션을 선택합니다. 오리진/웹 서버에 액세스할 수 있어야 합니다. 다음 절차에 따라 도메인 소유권을 검증합니다.

**기존 트래픽이 있을 때 도메인 설정을 완료하려면 다음과 같이 합니다.**

1. **웹 트래픽 지정**에서 **기존 트래픽이 있음**을 선택한 후 **다음**을 선택합니다.

1. **도메인 소유권 확인**에서 다음 옵션 중 하나를 선택합니다.
   + **기존 인증서 사용** - 기존 ACM 인증서를 검색하거나 나열된 도메인을 포함하는 인증서 ARN을 입력합니다.
   + **수동 파일 업로드** - 웹 서버에 파일을 업로드할 수 있는 직접 액세스 권한이 있는 경우 선택합니다.

     각 도메인에 대한 **토큰 위치**에서 검증 토큰이 포함된 일반 텍스트 파일을 만들고 기존 서버의 지정된 **파일 경로**에서 오리진에 업로드합니다. 예를 들어 이 파일에 대한 경로는 다음(`/.well-known/pki-validation/acm_9c2a7b2ec0524d09fa6013efb73ad123.txt`)과 같을 수 있습니다. 이 단계를 완료하면 ACM은 토큰을 확인한 다음, 도메인에 대한 TLS 인증서를 발급합니다.
   + **HTTP 리디렉션** - 웹 서버에 파일을 업로드할 수 있는 직접 액세스 권한이 없거나 CDN 또는 프록시 서비스를 사용하는 경우 선택합니다.

     각 도메인에서 기존 서버에 301 리디렉션을 만듭니다. **다음에서 리디렉션**에서 잘 알려진 경로를 복사하고 **다음으로 리디렉션**에서 지정된 인증서 엔드포인트를 가리킵니다. 리디렉션은 다음 예제와 비슷할 수 있습니다.

     ```
     If the URL matches: example.com/.well-known/pki-validation/leabe938a4fe077b31e1ff62b781c123.txt
     Then the settings are:Forwarding URL
     Then 301 Permanent Redirect:To validation.us-east-1.acm-validations.aws/123456789012/.well-known/pki-validation/leabe938a4fe077b31e1ff62b781c123.txt
     ```
**참고**  
**인증서 상태 확인**을 선택하여 ACM이 도메인에 대한 인증서를 발급하는 경우를 확인할 수 있습니다.

1. **다음**을 선택합니다.

1. [도메인을 CloudFront로 가리키기](#point-domains-to-cloudfront)의 단계를 완료합니다.

------
#### [ I don't have traffic ]

새 도메인을 추가하는 경우 이 옵션을 선택합니다. CloudFront에서 인증서 검증을 관리합니다.

**트래픽이 없는 경우 도메인 설정을 완료하려면 다음과 같이 합니다.**

1. **웹 트래픽 지정**에서 **아직 트래픽이 없음**을 선택합니다.

1. 각 도메인 이름에서 [도메인을 CloudFront로 가리키기](#point-domains-to-cloudfront)의 단계를 완료합니다.

1. 각 도메인 이름에서 DNS 레코드를 업데이트한 후 **다음**을 선택합니다.

1. 인증서가 발급될 때까지 기다립니다.
**참고**  
**인증서 상태 확인**을 선택하여 ACM이 도메인에 대한 인증서를 발급하는 경우를 확인할 수 있습니다.

1. **제출**을 선택합니다.

------

## 도메인을 CloudFront로 가리키기
<a name="point-domains-to-cloudfront"></a>

DNS 레코드를 업데이트하여 각 도메인의 트래픽을 CloudFront 라우팅 엔드포인트로 라우팅합니다. 여러 도메인 이름을 가질 수 있지만 모두 이 엔드포인트로 확인되어야 합니다.

**도메인을 CloudFront로 가리키려면 다음과 같이 합니다.**

1. d111111abcdef8.cloudfront.net 등의 CloudFront 라우팅 엔드포인트 값을 복사합니다.

1. DNS 레코드를 업데이트하여 각 도메인의 트래픽을 CloudFront 라우팅 엔드포인트로 라우팅합니다.

   1. 도메인 등록 또는 DNS 공급자의 관리 콘솔에 로그인합니다.

   1. 도메인의 DNS 관리 섹션으로 이동합니다.
      + **하위 도메인** - CNAME 레코드를 만듭니다. 예제:
        + **이름** - 하위 도메인(예: `www` 또는 `app`)
        + **값/대상** - CloudFront 라우팅 엔드포인트
        + **레코드 유형** - CNAME
        + **TTL** – 3600(또는 사용 사례에 적합한 것)
      + **apex/루트 도메인의 경우** - 루트 또는 apex 도메인 수준에서는 표준 CNAME 레코드를 사용할 수 없으므로 고유한 DNS 구성이 필요합니다. 대부분의 DNS 공급자는 ALIAS 레코드를 지원하지 않기 때문에 Route 53에서 ALIAS 레코드를 생성하는 것이 좋습니다. 예제:
        + **이름** - apex 도메인(예: `example.com`)
        + **레코드 유형** - A
        + **별칭** - 예
        + **별칭 대상** - CloudFront 라우팅 엔드포인트
        + **라우팅 정책** - 단순(또는 사용 사례에 적합한 것)

   1. DNS 변경 사항이 채워졌는지 확인합니다. (이는 일반적으로 TTL이 만료될 때 발생합니다. 경우에 따라 24\$148시간이 걸릴 수 있습니다.) `dig` 또는 `nslookup` 등의 도구를 사용합니다.

      ```
      dig www.example.com
      # Should eventually return a CNAME pointing to your CloudFront routing endpoint
      ```

1. CloudFront 콘솔로 이동하여 **제출**을 선택합니다. 도메인이 활성 상태이면 CloudFront는 도메인이 트래픽을 처리할 준비가 되었음을 나타내도록 도메인 상태를 업데이트합니다.

자세한 내용은 DNS 공급자의 설명서를 참조하세요.
+ [Cloudflare](https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/)
+ [ClouDNS](https://www.cloudns.net/wiki/article/9/)
+ [DNSimple](https://support.dnsimple.com/categories/dns/)
+ [Gandi.net](https://www.gandi.net/)
+ [GoDaddy](https://www.godaddy.com/help/manage-dns-records-680)
+ [Google Cloud DNS](https://cloud.google.com/dns/docs/records)
+ [Namecheap](https://www.namecheap.com/support/knowledgebase/article.aspx/767/10/how-to-change-dns-for-a-domain/)

## 도메인 고려 사항(배포 테넌트)
<a name="tenant-domain-considerations"></a>

도메인이 활성 상태이면 도메인 제어가 설정되고 CloudFront는 이 도메인에 대한 모든 뷰어 요청에 응답합니다. 활성화되면 도메인을 비활성화하거나 비활성 상태로 변경할 수 없습니다. 이미 사용 중인 동안에는 도메인을 다른 CloudFront 리소스와 연결할 수 없습니다. 도메인을 다른 배포와 연결하려면 [UpdateDomainAssociation](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDomainAssociation.html) 요청을 사용하여 도메인을 한 CloudFront 리소스에서 다른 CloudFront 리소스로 이전합니다.

도메인이 비활성 상태이면 CloudFront는 도메인에 대한 뷰어 요청에 응답하지 않습니다. 도메인이 비활성 상태일 때 다음 사항에 유의합니다.
+ 보류 중인 인증서 요청이 있는 경우 CloudFront는 잘 알려진 경로에 대한 요청에 응답합니다. 요청이 보류 중인 동안에는 도메인을 다른 CloudFront 리소스와 연결할 수 없습니다.
+ 보류 중인 인증서 요청이 없는 경우 CloudFront는 도메인에 대한 요청에 응답하지 않습니다. 도메인을 다른 CloudFront 리소스와 연결할 수 있습니다.
+ 배포 테넌트당 *보류 중인 인증서 요청은 하나*만 가질 수 있습니다. 추가 도메인에 대해 다른 인증서를 요청하려면 먼저 보류 중인 기존 요청을 취소해야 합니다. 기존 인증서 요청을 취소해도 연결된 ACM 인증서는 삭제되지 않습니다. ACM API를 사용하여 인증서를 삭제할 수 있습니다.
+ 배포 테넌트에 새 인증서를 적용하면 이전 인증서의 연결이 해제됩니다. 인증서를 재사용하여 다른 배포 테넌트의 도메인에 적용할 수 있습니다.

DNS 검증 인증서 갱신과 마찬가지로 인증서 갱신이 성공하면 알림이 전송됩니다. 하지만 사용자는 조치를 취할 필요가 없습니다. CloudFront는 도메인의 인증서 갱신을 자동으로 관리합니다.

**참고**  
인증서 리소스를 만들거나 업데이트하기 위해 ACM API 작업을 호출할 필요가 없습니다. [CreateDistributionTenant](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistributionTenant.html) 및 [UpdateDistributionTenant](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistributionTenant.html) API 작업을 사용하여 관리형 인증서 요청에 대한 세부 정보를 지정하여 인증서를 관리할 수 있습니다.

## 와일드카드 도메인(배포 테넌트)
<a name="tenant-wildcard-domains"></a>

다음과 같은 경우 배포 테넌트에 와일드카드 도메인이 지원됩니다.
+ 상위 다중 테넌트 배포에서 상속된 공유 인증서에 와일드카드가 포함된 경우
+ 배포 테넌트에 유효한 기존 사용자 지정 TLS 인증서를 사용하는 경우

# 사용자 지정 연결 그룹 생성(선택 사항)
<a name="custom-connection-group"></a>

기본적으로 CloudFront는 다중 테넌트 배포를 만들 때 연결 그룹을 만듭니다. 연결 그룹은 콘텐츠에 대한 뷰어 요청이 CloudFront에 연결되는 방식을 제어합니다.

기본값 연결 그룹을 그대로 사용하는 것이 좋습니다. 그러나 엔터프라이즈 애플리케이션을 격리하거나 배포 테넌트 그룹을 별도로 관리해야 하는 경우 사용자 지정 연결 그룹을 만들도록 선택할 수 있습니다. 예를 들어 DDoS 공격이 발생하는 경우 배포 테넌트를 별도의 연결 그룹으로 이전해야 할 수 있습니다. 이렇게 하면 다른 배포 테넌트가 영향을 받지 않도록 보호할 수 있습니다.

## 사용자 지정 연결 그룹 생성(선택 사항)
<a name="create-connection-group"></a>

필요에 따라 배포 테넌트에 대한 사용자 지정 연결 그룹을 만들도록 선택할 수 있습니다.

**사용자 지정 연결 그룹을 만들려면 다음과 같이 합니다(선택 사항).**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 탐색 창에서 **설정**을 선택합니다.

1. **연결 그룹** 설정을 켭니다.

1. 탐색 창에서 **연결 그룹**을 선택한 다음 **연결 그룹 생성**을 선택합니다.

1. **연결 그룹 이름**에 연결 그룹의 이름을 입력합니다. 연결 그룹을 만든 후에는 이 이름을 업데이트할 수 없습니다.

1. **IPv6**에서 이 IP 프로토콜을 사용 설정할지 여부를 지정합니다. 자세한 내용은 [IPv6 활성화(뷰어 요청)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6) 섹션을 참조하세요.

1. **애니캐스트 고정 IP 목록**에서, IP 주소 집합에서 배포 테넌트로 트래픽을 전송할지 여부를 지정합니다. 자세한 내용은 [애니캐스트 고정 IP 목록](request-static-ips.md)을 참조하시기 바랍니다.

1. (선택 사항) 연결 그룹에 태그를 추가합니다.

1. **연결 그룹 생성**을 선택합니다.

연결 그룹이 만들어지면 지정한 설정과 ARN 및 엔드포인트를 찾을 수 있습니다.
+ ARN은 다음 예제(`arn:aws:cloudfront::123456789012:connection-group/cg_2uVbA9KeWaADTbKzhj9lcKDoM25`)와 비슷하게 표시됩니다.
+ 엔드포인트는 다음 예제(d111111abcdef8.cloudfront.net)와 비슷하게 표시됩니다.

사용자 지정 연결 그룹을 만든 후 편집하거나 삭제할 수 있습니다. 연결 그룹을 삭제하려면 먼저 모든 연결된 배포 테넌트를 삭제해야 합니다. 다중 테넌트 배포를 만들 경우 CloudFront에서 만든 기본 연결 그룹은 삭제할 수 없습니다.

**중요**  
배포 테넌트의 연결 그룹을 변경하면 CloudFront는 배포 테넌트에 대한 트래픽을 계속 전달하지만 지연 시간이 증가합니다. 새 연결 그룹에서 CloudFront 라우팅 엔드포인트를 사용하도록 배포 테넌트의 DNS 레코드를 업데이트하는 것이 좋습니다.  
DNS 레코드를 업데이트할 때까지 CloudFront는 웹 사이트가 현재 DNS를 가리키고 있는 라우팅 엔드포인트에 대해 정의된 설정을 기반으로 라우팅합니다. 예를 들어 기본값 연결 그룹이 애니캐스트 고정 IP를 사용하지 않지만 새로운 사용자 지정 연결 그룹은 사용한다고 가정합니다. CloudFront가 사용자 지정 연결 그룹의 배포 테넌트에 애니캐스트 고정 IP를 사용하기 전에 DNS 레코드를 업데이트해야 합니다.

# 다중 테넌트 배포로 마이그레이션
<a name="template-migrate-distribution"></a>

CloudFront 표준 배포가 있으며 다중 테넌트 배포로 마이그레이션하려는 경우 다음 단계를 따르세요.

**표준 배포에서 다중 테넌트 배포로 마이그레이션하려면**

1. [지원되지 않는 기능](distribution-config-options.md#unsupported-saas)을(를) 검토합니다.

1. 지원되지 않는 기능을 제외하고 표준 배포와 동일한 구성으로 다중 테넌트 배포를 생성합니다. 자세한 내용은 [콘솔에서 CloudFront 배포 생성](distribution-web-creating-console.md#create-console-distribution) 섹션을 참조하세요.

1. 배포 테넌트를 생성하고 소유한 대체 도메인 이름을 추가합니다.
**주의**  
표준 배포와 연결된 현재 도메인 이름은 사용하지 *마세요*. 대신 자리 표시자 도메인을 추가합니다. 나중에 도메인을 이동합니다. 배포 테넌트 생성에 대한 자세한 내용은 [콘솔에서 CloudFront 배포 생성](distribution-web-creating-console.md#create-console-distribution) 섹션을 참조하세요.

1. 배포 테넌트 도메인에 대한 기존 인증서를 제공합니다. 이 인증서는 자리 표시자 도메인과 이동하려는 도메인에 적용됩니다.

1. 콘솔의 배포 테넌트 세부 정보 페이지에서 CloudFront 라우팅 엔드포인트를 복사합니다. 또는 *Amazon CloudFront API 참조*의 [ListConnectionGroups](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListConnectionGroups.html) API 작업을 사용하여 이를 찾을 수 있습니다.

1. 도메인 소유권을 확인하려면 배포 테넌트의 CloudFront 라우팅 엔드포인트를 가리키는 DCV TXT 레코드를 밑줄( \$1 ) 접두사를 사용하여 생성합니다. 자세한 내용은 [도메인을 CloudFront로 가리키기](managed-cloudfront-certificates.md#point-domains-to-cloudfront) 섹션을 참조하세요.

1. 변경 사항이 전파되면 이전에 표준 배포에 사용한 도메인을 사용하도록 배포 테넌트를 업데이트합니다.
   + **콘솔** - 자세한 지침은 [도메인 및 인증서 추가(분산 테넌트)](managed-cloudfront-certificates.md#vanity-domain-tls-tenant) 섹션을 참조하세요.
   + **API** - *Amazon CloudFront API 참조*의 [UpdateDomainAssociation](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDomainAssociation.html) API 작업을 사용합니다.
**중요**  
이렇게 하면 콘텐츠의 캐시 키가 재설정됩니다. 그런 다음 CloudFront는 새 캐시 키를 사용하여 콘텐츠 캐싱을 시작합니다. 자세한 내용은 [캐시 키 이해](understanding-the-cache-key.md) 섹션을 참조하세요.

1. 도메인이 배포 테넌트의 CloudFront 라우팅 엔드포인트를 가리키도록 DNS 레코드를 업데이트합니다. 이 단계를 완료하면 도메인이 배포 테넌트에 트래픽을 제공할 준비가 됩니다. 자세한 내용은 [도메인을 CloudFront로 가리키기](managed-cloudfront-certificates.md#point-domains-to-cloudfront) 섹션을 참조하세요.

1. (선택 사항) 도메인을 배포 테넌트에 성공적으로 마이그레이션한 후에는 배포 테넌트의 도메인 이름에 적용되는 다른 CloudFront 관리형 인증서를 사용할 수 있습니다. 관리형 인증서를 요청하려면 별도의 TXT 레코드를 생성하여 인증서를 발급하고 [도메인 설정 완료](managed-cloudfront-certificates.md#complete-domain-ownership)의 단계를 따릅니다.

# 배포 생성
<a name="distribution-web-creating-console"></a>

이 항목에서는 CloudFront 콘솔을 사용하여 배포를 생성하는 방법을 설명합니다.<a name="create-download-distribution-task-list"></a>

**개요**

1. 하나 이상의 Amazon S3 버킷을 만들거나 HTTP 서버를 오리진 서버로 구성합니다. **오리진은 콘텐츠의 원본 버전을 저장하는 장소입니다. CloudFront에서 파일에 대한 요청을 가져오면, 이 요청은 엣지 로케이션에서 배포할 파일을 가져오는 오리진이 됩니다. Amazon S3 버킷 및 HTTP 서버를 결합하여 오리진 서버로 사용할 수 있습니다.
   + Amazon S3를 사용 중인 경우 버킷의 이름은 전부 소문자로만 구성되어야 하며 공백을 포함할 수 없습니다.
   + Amazon EC2 서버나 다른 사용자 지정 서버를 사용 중인 경우, [Amazon EC2(또는 기타 사용자 지정 오리진) 사용](DownloadDistS3AndCustomOrigins.md#concept_CustomOrigin) 섹션을 검토하세요.
   + 현재 하나의 배포에 대해 생성할 수 있는 오리진의 최대 수를 살펴보고 더 높은 할당량을 요청하려면 [배포의 일반 할당량](cloudfront-limits.md#limits-web-distributions) 섹션을 참조하세요.

1. 오리진 서버에 콘텐츠를 업로드합니다. 객체를 공개적으로 읽기 가능하도록 설정할 수도 있고, CloudFront 서명된 URL을 사용하여 콘텐츠에 대한 액세스를 제한할 수도 있습니다.
**중요**  
이 경우, 오리진 서버의 보안을 보장하는 것은 사용자의 책임입니다. CloudFront에서 서버에 대한 액세스 권한을 보유해야 하며 콘텐츠를 안전하게 보호할 수 있도록 보안 설정이 적용되어 있어야 합니다.

1. CloudFront 배포 생성:
   + CloudFront 콘솔에서 배포를 생성하는 자세한 절차는 [콘솔에서 CloudFront 배포 생성](#create-console-distribution) 섹션을 참조하세요.
   + CloudFront API를 사용하여 배포를 생성하는 방법에 대한 자세한 내용은 **Amazon CloudFront API 참조의 [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)을 참조하세요.

1. (선택 사항) CloudFront 콘솔을 사용하여 배포를 생성한 경우, 캐시 동작 또는 배포에 대한 오리진을 추가로 생성합니다. 동작과 오리진에 대한 자세한 내용은 [다중 테넌트 배포를 업데이트하려면 다음과 같이 합니다.](HowToUpdateDistribution.md#HowToUpdateDistributionProcedure) 섹션을 참조하세요.

1. 배포를 테스트합니다. 테스트에 대한 자세한 내용은 [배포 테스트](distribution-web-testing.md) 섹션을 참조하세요.

1. 3단계에서 배포를 만든 뒤 CloudFront에서 반환된 도메인 이름을 사용하여 콘텐츠에 액세스하는 웹 사이트 또는 애플리케이션을 작성합니다. 예를 들어 CloudFront에서 d111111abcdef8.cloudfront.net을 배포의 도메인 이름으로 반환할 경우, Amazon S3 버킷 또는 HTTP 서버의 루트 디렉터리에 있는 `image.jpg` 파일의 URL은 `https://d111111abcdef8.cloudfront.net/image.jpg`가 됩니다.

   배포를 만들 때 하나 이상의 대체 도메인 이름(CNAME)을 지정한 경우, 자체 도메인 이름을 사용할 수 있습니다. 이 경우 `image.jpg`에 대한 URL은 `https://www.example.com/image.jpg`가 될 수 있습니다.

   다음을 참조하십시오.
   + 서명된 URL을 사용하여 콘텐츠에 대한 액세스를 제한하려는 경우 [서명된 URL과 서명된 쿠키를 사용하여 프라이빗 콘텐츠 제공](PrivateContent.md) 단원을 참조하십시오.
   + 압축된 콘텐츠를 제공하려는 경우 [압축된 파일 제공](ServingCompressedFiles.md) 단원을 참조하십시오.
   + Amazon S3 및 사용자 지정 오리진에 대한 CloudFront 요청 및 응답 동작과 관련한 자세한 내용은 [요청 및 응답 동작](RequestAndResponseBehavior.md) 단원을 참조하세요.

**Topics**
+ [콘솔에서 CloudFront 배포 생성](#create-console-distribution)
+ [CloudFront가 콘솔에 표시하는 값](#distribution-web-values-returned)
+ [추가 링크](#distribution-helpful-links)
+ [CloudFront 표준 배포에 도메인 추가](add-domain-existing-distribution.md)

## 콘솔에서 CloudFront 배포 생성
<a name="create-console-distribution"></a>

배포를 만들면 CloudFront가 콘텐츠 오리진 유형에 따라 배포 설정을 구성합니다. 재구성 설정에 대한 자세한 내용은 [사전 구성된 배포 설정 참조](template-preconfigured-origin-settings.md) 섹션을 참조하시기 바랍니다. 여러 배포 테넌트에서 재사용할 수 있는 설정을 사용하여 다중 테넌트 배포를 만들 수도 있습니다. 자세한 내용은 [다중 테넌트 배포의 작동 방식 이해](distribution-config-options.md) 섹션을 참조하세요. 또는 자체 배포 설정을 수동으로 구성할 수 있습니다.

------
#### [ Multi-tenant ]<a name="CreatingDownloadDistributionsConsoleProcedure"></a>

**다중 테넌트 배포를 만들려면 다음과 같이 합니다.**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 탐색 창에서 **배포**를 선택한 후 **배포 생성**을 선택합니다.

1. **다중 테넌트 아키텍처**, **다음**을 선택합니다.

1. 다중 테넌트 배포에 **배포 이름**을 입력합니다. 이름은 `Name` 키 값으로 표시됩니다. 이 값은 나중에 변경할 수 있습니다. 다중 테넌트 배포에 최대 50개의 태그를 추가할 수 있습니다. 자세한 내용은 섹션을 참조하세요[배포 태깅](tagging.md)

1. (선택 사항) **와일드카드 인증서**에서 루트 도메인 아래의 모든 하위 도메인을 포함하는 AWS Certificate Manager(ACM) 인증서(예: *\$1.example.com*)를 선택합니다. 미국 동부(버지니아 북부) 리전에서 인증서를 가져와야 합니다.

1. **다음**을 선택합니다.

1. **오리진 지정** 페이지에서 CloudFront에서 가져올 콘텐츠의 오리진 유형을 선택합니다. CloudFront는 다중 테넌트 배포의 해당 오리진 유형에 대한 권장 설정을 사용합니다. 권장 설정에 대한 자세한 내용은 [사전 구성된 배포 설정 참조](template-preconfigured-origin-settings.md) 섹션을 참조하시기 바랍니다.

1. **오리진**의 선택한 오리진 유형에서 사용할 오리진을 선택하거나 입력합니다.

1. **오리진 경로**에 슬래시(`/`) 문자를 입력한 다음 오리진 경로를 입력합니다.

1. (선택 사항) 파라미터를 추가하려면 오리진 도메인 이름 또는 오리진 경로 중 하나에서 **파라미터 삽입**을 선택합니다. 각 필드에 최대 2개의 파라미터를 입력할 수 있습니다.

   1. **새 파라미터 생성**을 선택합니다.

   1. **새 파라미터 생성** 대화 상자의 **파라미터 이름**에 파라미터의 고유한 이름과 설명(선택 사항)을 입력합니다.

   1. **필수 파라미터**에서 확인란을 선택하여 배포 테넌트 수준에서 이 파라미터 값을 필수로 설정합니다. 필요하지 않은 경우 배포 테넌트가 상속할 **기본값**을 입력합니다.

   1. **파라미터 생성(Create parameter)**을 선택합니다. 해당 필드에 이 파라미터가 나타납니다.

1. **옵션**에서 다음 옵션 중 하나를 선택합니다.
   + **권장 오리진 설정 사용** - 선택한 오리진 유형의 기본 권장 캐시 및 오리진 설정을 사용합니다.
   + **오리진 설정 사용자 지정** - 캐시 및 오리진 설정을 사용자 지정합니다. 이 옵션을 선택하는 경우 표시되는 고유한 값을 지정합니다.

1. **다음**을 선택합니다.

1. **보안 보호 활성화** 페이지에서 AWS WAF 보안 보호 기능을 사용 설정할지 여부를 선택합니다. 나중에 특정 배포 테넌트에 대해 웹 ACL을 사용자 지정할 수 있습니다. 자세한 내용은 [새 배포에 AWS WAF 활성화](WAF-one-click.md#enable-waf-new-distribution) 섹션을 참조하세요.

1. **다음**, **배포 생성**을 차례로 선택합니다.

1. **배포** 페이지의 리소스 목록에 다중 테넌트 배포가 나타납니다. **모든 배포** 드롭다운을 선택하여 표준 배포 또는 다중 테넌트 배포별로 필터링할 수 있습니다. 또한 **유형** 열을 선택하여 표준 배포 또는 다중 테넌트 배포별로 필터링할 수 있습니다.

기본적으로 CloudFront에서는 연결 그룹을 만듭니다. 연결 그룹은 콘텐츠에 대한 뷰어 요청이 CloudFront에 연결되는 방식을 제어합니다. 연결 그룹에서 일부 라우팅 설정을 사용자 지정할 수 있습니다. 자세한 내용은 [다중 테넌트 배포의 작동 방식 이해](distribution-config-options.md) 섹션을 참조하세요.

다중 테넌트 배포를 템플릿으로 사용하여 추가 배포 테넌트를 만들 수 있습니다.

**테넌트 배포를 만들려면 다음과 같이 합니다.**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 탐색 창에서 다음 중 하나를 수행합니다.
   + **배포**를 선택하고 다중 테넌트 배포를 선택한 다음 **테넌트 생성**을 선택합니다.
   + **배포 테넌트**를 선택한 다음 **테넌트 생성**을 선택합니다.

1. **배포 테넌트 이름**에 이름을 입력합니다. AWS 계정에서 중복되지 않는 이름이어야 하며, 만들고 나면 변경할 수 없습니다.

1. **템플릿 배포**의 목록에서 다중 테넌트 배포 ID를 선택합니다.

1. **태그 관리**에서 배포 테넌트에 대해 최대 50개의 키-값 페어를 추가합니다. 자세한 내용은 [배포 태깅](tagging.md) 섹션을 참조하세요. **** 

1. **다음**을 선택합니다.

1. **도메인 추가** 페이지의 **인증서**에서 배포 테넌트에 대한 **사용자 지정 TLS 인증서를** 원하는지 선택합니다. 인증서는 도메인 이름을 사용할 권한이 있는지 확인합니다. 미국 동부(버지니아 북부) 리전에서 인증서를 가져와야 합니다.

1. **도메인**에 도메인의 이름을 입력합니다.
**참고**  
인증서에 포함되지 않는 도메인 이름을 입력한 경우 도메인을 소유하고 있는지 확인해야 합니다. 지금은 배포 테넌트를 만들고 나중에 도메인 소유권을 확인할 수 있습니다. 자세한 내용은 [CloudFront 배포 테넌트에 대한 인증서 요청](managed-cloudfront-certificates.md) 섹션을 참조하세요.

1. **다음**을 선택합니다.

1. **파라미터 정의** 페이지에 다중 테넌트 배포에 지정한 파라미터가 나타납니다. 필수 파라미터에서 파라미터 이름 옆에 값을 입력하고 변경 사항을 저장합니다.

1. 다른 파라미터를 추가하려면 **파라미터 추가**를 선택하고 이름과 값을 입력합니다.

1. **다음**을 선택합니다.

1. (선택 사항) **보안 사용자 지정**에서 **배포 설정 재정의**를 선택한 경우 사용 사례에 맞는 옵션을 선택합니다.

1. (선택 사항) **지리적 제한 사용자 지정**에서 **배포 설정 재정의**를 선택한 경우 배포 테넌트에 적합한 **제한 유형** 및 **국가**를 선택합니다. 자세한 내용은 [콘텐츠의 지리적 배포 제한](georestrictions.md) 섹션을 참조하세요.

1. **다음**을 선택합니다.

1. **배포 테넌트 생성**을 선택합니다.

**배포 테넌트** 페이지에서 모든 배포 테넌트를 확인할 수 있습니다. 다음 항목을 기준으로 필터링할 수 있습니다.

**연결**
+ 배포 ID
+ 인증서 ID
+ 연결 그룹 ID
+ 웹 ACL ID

**속성**
+ 이름
+ 도메인

배포 테넌트를 편집하여 특정 설정을 사용자 지정할 수 있습니다. 자세한 내용은 [배포 테넌트 사용자 지정](tenant-customization.md) 섹션을 참조하세요.

------
#### [ Standard ]

**표준 배포를 만들려면 다음과 같이 합니다.**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 탐색 창에서 **배포**를 선택한 후 **배포 생성**을 선택합니다.

1. 표준 배포에 **배포 이름**을 입력합니다. 이름은 태그로서 `Name` 키의 값으로 표시됩니다. 이 값은 나중에 변경할 수 있습니다. 표준 배포에 최대 50개의 태그를 추가할 수 있습니다. 자세한 내용은 [배포 태깅](tagging.md) 섹션을 참조하세요.

1. **단일 웹사이트 또는 앱**, **다음**을 선택합니다.

1. (선택 사항) **도메인 설정**에 AWS 계정에서 Route 53에 이미 등록된 도메인을 입력하거나 새 도메인을 등록합니다. 설정 단계를 완료하세요.
   + 도메인이 Route 53 이외의 DNS 공급자를 사용하는 경우에도 도메인을 추가할 수 있지만 배포를 생성한 후 추가해야 합니다. 배포 생성을 계속하려면 지금 도메인 설정을 건너뜁니다. 나중에 도메인 및 TLS 인증서를 수동으로 구성해야 합니다. 자세한 내용은 [CloudFront 표준 배포에 도메인 추가](add-domain-existing-distribution.md) 섹션을 참조하세요.

1. **다음**을 선택합니다.

1. **오리진 지정** 페이지에서 CloudFront에서 가져올 콘텐츠의 오리진 유형을 선택합니다. CloudFront는 배포의 해당 오리진 유형에 대한 권장 설정을 사용합니다. 권장 설정에 대한 자세한 내용은 [사전 구성된 배포 설정 참조](template-preconfigured-origin-settings.md) 섹션을 참조하시기 바랍니다.

1. **오리진**에서 오리진을 선택하거나 입력합니다.

1. **설정**에서 다음 옵션 중 하나를 선택합니다.
   + **권장 오리진 설정 사용** - 선택한 오리진 유형의 기본 권장 캐시 및 오리진 설정을 사용합니다.
   + **오리진 설정 사용자 지정** - 캐시 및 오리진 설정을 사용자 지정합니다. 이 옵션을 선택하는 경우 고유한 값을 지정합니다.

1. **다음**을 선택합니다.

1. **보안 보호 활성화** 페이지에서 AWS WAF 보안 보호 기능을 사용 설정할지 여부를 선택합니다.

1. **다음**을 선택합니다.

1. (선택 사항) 도메인에 Route 53을 사용하는 경우 **TLS 인증서** 페이지가 표시됩니다. CloudFront가 AWS 계정의 `us-east-1` AWS 리전에서 도메인에 대한 기존 AWS Certificate Manager(ACM) 인증서를 찾을 수 없는 경우 인증서를 자동으로 생성하거나 수동으로 생성하도록 선택할 수 있습니다. 인증서가 생성되면 **다음**을 선택합니다.

1. 배포 세부 정보를 검토하고 **배포 생성**을 선택합니다.

1. CloudFront에서 배포를 생성하면 배포에 대한 **상태** 열의 값이 **진행 중**에서 배포된 날짜와 시간으로 변경됩니다.

   CloudFront가 배포에 할당하는 도메인 이름이 배포 목록에 나타납니다. 선택한 배포에 대한 [**General**] 탭에도 나타납니다.
**작은 정보**  
[대체 도메인 이름(CNAME)을 추가하여 사용자 지정 URL 사용](CNAMEs.md)의 단계를 따르면 CloudFront에서 할당한 이름 대신 대체 도메인 이름을 사용할 수 있습니다.

1. 배포가 완료되면 새 CloudFront URL(d111111abcdef8.cloudfront.net) 또는 CNAME를 사용하여 콘텐츠에 액세스할 수 있는지 확인합니다. 자세한 내용은 [배포 테스트](distribution-web-testing.md) 섹션을 참조하세요.

1. 트래픽을 배포에 전송할 준비가 되면 CloudFront를 가리키도록 DNS 레코드를 업데이트해야 합니다. 자세한 내용은 [도메인을 CloudFront로 가리키기(표준 배포)](add-domain-existing-distribution.md#point-domains-standard) 섹션을 참조하세요.

------

## CloudFront가 콘솔에 표시하는 값
<a name="distribution-web-values-returned"></a>

새 배포를 생성하거나 기존 배포를 업데이트할 때, CloudFront에서는 다음 정보를 CloudFront 콘솔에 표시합니다.

**참고**  
활성화된 신뢰할 수 있는 서명자, 활성 CloudFront 키 페어를 보유하고 있으며 유효한 서명된 URL을 만드는 데 사용할 수 있는 AWS 계정은 현재 CloudFront 콘솔에 표시되지 않습니다.

### 배포 ID
<a name="DownloadDistReturnID"></a>

CloudFront API를 사용하여 배포에 대한 작업을 수행할 경우, 배포 ID를 사용하여 대상 배포를 지정합니다(예: `EDFDVBD6EXAMPLE`). 배포의 배포 ID는 변경할 수 없습니다.

### 배포 및 상태
<a name="DownloadDistReturnStatus"></a>

배포를 배포할 때 **마지막 수정일** 열 아래에 **배포** 상태가 표시됩니다. 배포가 완료될 때까지 기다린 다음 **상태** 열에 **활성화됨**으로 표시되는지 확인합니다. 자세한 내용은 [배포 상태](DownloadDistValuesGeneral.md#DownloadDistValuesEnabled) 섹션을 참조하세요.

### 마지막 수정
<a name="DownloadDistReturnLastModDate"></a>

배포가 마지막으로 수정된 날짜 및 시간을 ISO 8601 형식을 사용하여 나타냅니다(예: 2012-05-19T19:37:58Z). 자세한 내용은 [https://www.w3.org/TR/NOTE-datetime](https://www.w3.org/TR/NOTE-datetime) 섹션을 참조하세요.

### 도메인 이름
<a name="DownloadDistReturnDomainName"></a>

객체에 대한 링크에 배포의 도메인 이름을 사용합니다. 예를 들어, 배포의 도메인 이름이 `d111111abcdef8.cloudfront.net`인 경우, `/images/image.jpg`에 대한 링크는 `https://d111111abcdef8.cloudfront.net/images/image.jpg`가 됩니다. 배포에 대한 CloudFront 도메인 이름은 변경할 수 없습니다. 객체에 대한 링크의 CloudFront URL에 대한 자세한 내용은 [CloudFront에서 파일에 대한 URL 형식 사용자 지정](LinkFormat.md) 단원을 참조하세요.

하나 이상의 대체 도메인 이름(CNAME)을 지정한 경우, 객체에 대한 링크에 CloudFront 도메인 이름을 사용하는 대신 자체 도메인 이름을 사용할 수 있습니다. CNAME에 대한 자세한 내용은 [대체 도메인 이름(CNAME)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME)을 참조합니다.

**참고**  
CloudFront 도메인 이름은 고유합니다. 즉, 배포의 도메인 이름은 이전 배포에 사용된 적이 없고 이후 다른 배포에 재사용되지도 않습니다.

## 추가 링크
<a name="distribution-helpful-links"></a>

배포 생성에 대한 자세한 내용은 다음 링크를 참조하세요.
+ Amazon Simple Storage Service(S3) 버킷 오리진, 오리진 액세스 제어(OAC)를 사용하는 배포를 생성하는 방법을 알아보려면 [CloudFront 표준 배포 시작](GettingStarted.SimpleDistribution.md) 섹션을 참조하세요.
+ CloudFront API를 사용하여 배포를 생성하는 방법에 대한 자세한 내용은 **Amazon CloudFront API 참조의 [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)을 참조하세요.
+ 배포 업데이트(예: 표준 배포에 캐시 동작 추가 또는 배포 테넌트 사용자 지정)에 대한 자세한 내용은 [배포 업데이트](HowToUpdateDistribution.md) 섹션을 참조하시기 바랍니다.
+ 현재 각 AWS 계정에 대해 생성할 수 있는 배포의 최대 수를 살펴보고 더 높은 할당량(이전에는 제한이라고 함)을 요청하려면, [배포의 일반 할당량](cloudfront-limits.md#limits-web-distributions) 단원을 참조하십시오.

# CloudFront 표준 배포에 도메인 추가
<a name="add-domain-existing-distribution"></a>

새 CloudFront 표준 배포를 생성한 후 도메인을 추가할 수 있습니다. 선택적으로, 표준 배포를 생성할 때 표준 배포에 대한 Amazon Route 53 도메인을 설정할 수 있습니다. 자세한 내용은 [콘솔에서 CloudFront 배포 생성](distribution-web-creating-console.md#create-console-distribution) 섹션을 참조하세요.

## 기존 표준 배포에 도메인 추가
<a name="add-domain-standard"></a>

**표준 배포에 도메인을 추가하려면**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 탐색 창에서 **배포**를 선택한 후 배포 ID를 선택합니다.

1. **설정**, **대체 도메인 이름**에서 **도메인 추가**를 선택합니다.

1. 서비스를 제공할 도메인을 최대 5개까지 입력합니다.

1. **다음**을 선택합니다.

1. **TLS 인증서**의 경우 CloudFront가 AWS 계정의 `us-east-1` AWS 리전에서 도메인에 대한 기존 AWS Certificate Manager(ACM) 인증서를 찾을 수 없는 경우 인증서를 생성할 수 있습니다.
   + Amazon Route 53(Route 53)을 사용하는 경우 CloudFront가 자동으로 인증서를 생성합니다.

1. 인증서가 프로비저닝되면 DNS 공급자로 DNS 레코드를 업데이트하여 도메인 소유권을 입증해야 합니다. 그런 다음 **인증서 검증**을 선택합니다. 자세한 내용은 [도메인을 CloudFront로 가리키기(표준 배포)](#point-domains-standard) 섹션을 참조하세요.
   + Route 53을 사용하는 경우 CloudFront가 DNS 레코드를 자동으로 업데이트합니다.

1. **다음**을 선택합니다.

1. 변경 사항을 검토하고 **도메인 추가**를 선택합니다.

1. 트래픽을 배포에 전송하기 전에 CloudFront를 가리키도록 DNS 레코드를 업데이트해야 합니다. 자세한 내용을 보려면 배포 세부 정보 페이지의 **설정** 섹션에서 **CloudFront로 도메인 라우팅**을 선택합니다.
   + Route 53을 사용하는 경우 CloudFront에서 자동으로 DNS 라우팅을 설정하도록 할 수 있습니다.

## 도메인을 CloudFront로 가리키기(표준 배포)
<a name="point-domains-standard"></a>

DNS 레코드를 업데이트하여 각 도메인의 트래픽을 CloudFront 호스트 이름으로 라우팅합니다. 여러 도메인 이름을 가질 수 있지만 모두 이 호스트 이름으로 확인되어야 합니다.

**도메인을 CloudFront로 가리키려면 다음과 같이 합니다.**

1. d111111abcdef8.cloudfront.net 같은 CloudFront 호스트 이름 값을 복사합니다.

1. DNS 레코드를 업데이트하여 각 도메인의 트래픽을 CloudFront 호스트 이름으로 라우팅합니다.

   1. 도메인 등록 또는 DNS 공급자의 관리 콘솔에 로그인합니다.

   1. 도메인의 DNS 관리 섹션으로 이동합니다.
      + **하위 도메인** - CNAME 레코드를 만듭니다. 예제:
        + **이름** - 하위 도메인(예: `www` 또는 `app`)
        + **값/대상** - CloudFront 호스트 이름
        + **레코드 유형** - CNAME
        + **TTL** – 3600(또는 사용 사례에 적합한 것)
      + **apex/루트 도메인의 경우** - 루트 또는 apex 도메인 수준에서는 표준 CNAME 레코드를 사용할 수 없으므로 고유한 DNS 구성이 필요합니다. 대부분의 DNS 공급자는 ALIAS 레코드를 지원하지 않기 때문에 Route 53에서 ALIAS 레코드를 생성하는 것이 좋습니다. 예제:
        + **이름** - apex 도메인(예: `example.com`)
        + **레코드 유형** - A
        + **별칭** - 예
        + **별칭 대상** - CloudFront 호스트 이름
        + **라우팅 정책** - 단순(또는 사용 사례에 적합한 것)

   1. DNS 변경 사항이 채워졌는지 확인합니다. (이는 일반적으로 TTL이 만료될 때 발생합니다. 경우에 따라 24\$148시간이 걸릴 수 있습니다.) `dig` 또는 `nslookup` 등의 도구를 사용합니다.

      ```
      dig www.example.com
      # Should eventually return a CNAME pointing to your CloudFront hostname
      ```

1. CloudFront 콘솔로 이동하여 **제출**을 선택합니다. 도메인이 활성 상태이면 CloudFront는 도메인이 트래픽을 처리할 준비가 되었음을 나타내도록 도메인 상태를 업데이트합니다.

자세한 내용은 DNS 공급자의 설명서를 참조하세요.
+ [Cloudflare](https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/)
+ [ClouDNS](https://www.cloudns.net/wiki/article/9/)
+ [DNSimple](https://support.dnsimple.com/categories/dns/)
+ [Gandi.net](https://www.gandi.net/)
+ [GoDaddy](https://www.godaddy.com/help/manage-dns-records-680)
+ [Google Cloud DNS](https://cloud.google.com/dns/docs/records)
+ [Namecheap](https://www.namecheap.com/support/knowledgebase/article.aspx/767/10/how-to-change-dns-for-a-domain/)

# 사전 구성된 배포 설정 참조
<a name="template-preconfigured-origin-settings"></a>

CloudFront 배포를 만들면 CloudFront가 콘텐츠 오리진 유형에 따라 대부분의 배포 설정을 자동으로 구성합니다. 선택적으로 배포 설정을 수동으로 편집하도록 선택할 수 있습니다. 자세한 내용은 [모든 배포 설정 참조](distribution-web-values-specify.md) 섹션을 참조하세요.

다음 섹션에서는 배포의 기본 사전 구성 설정과 사용자 지정할 수 있는 설정에 대해 설명합니다.

## Amazon S3 오리진
<a name="s3-origin-preconfiguration"></a>

다음은 CloudFront가 다중 테넌트 배포에서 Amazon S3 오리진에 대해 사전 구성하는 오리진 설정입니다.

**오리진 설정(사전 구성)**
+ **오리진 액세스 제어(콘솔만 해당)** - CloudFront에서 이를 설정합니다. 표준 배포와 오리진 도메인에서 파라미터를 사용하지 않는 다중 테넌트 배포의 경우 CloudFront는 S3 버킷 정책을 추가하려고 시도합니다.
+ **사용자 지정 헤더 추가** - 없음
+ **Origin Shield 활성화** - 아니요
+ **연결 시도** - 3

다음은 CloudFront가 다중 테넌트 배포에서 Amazon S3 오리진에 대해 사전 구성하는 캐시 설정입니다.

**캐시 설정(사전 구성)**
+ **자동으로 객체 압축** - 예
+ **뷰어 프로토콜 정책** - HTTPS로 리디렉션
+ **허용된 HTTP 메서드** - `GET, HEAD`
+ **뷰어 액세스 제한** - 아니요
+ **캐시 정책** - `CachingOptimized`
+ **원본 요청 정책** - 없음
+ **응답 헤더 정책** - 없음
+ **스무스 스트리밍** - 아니요
+ **필드 레벨 암호화** - 아니요
+ **실시간 액세스 로그 활성화** - 아니요
+ **함수** - 아니요

다음은 다중 테넌트 배포에서 Amazon S3 오리진에 대해 사용자 지정할 수 있는 설정입니다.

**사용자 지정 가능한 설정**
+ **S3 액세스** - CloudFront는 S3 버킷 설정에 따라 이를 설정합니다.
  + **버킷이 퍼블릭인 경우** - 오리진 액세스 제어(OAC) 정책이 필요하지 않습니다.
  + **버킷이 프라이빗인 경우** - 사용할 OAC 정책을 선택하거나 만들 수 있습니다.
+ **Origin Shield 활성화** - 아니요
+ **자동으로 객체 압축** - 예
  + **예**를 선택하면 `CachingOptimized` 캐싱 정책이 사용됩니다.
  + **아니요**를 선택하면 `CachingOptimizedForUncompressedObjects` 캐싱 정책이 사용됩니다.

## API 게이트웨이 요금
<a name="api-gateway-origin-preconfiguration"></a>

다음은 CloudFront가 다중 테넌트 배포에서 API 게이트웨이 오리진에 대해 사전 구성하는 오리진 설정입니다.

**오리진 설정(사전 구성)**
+ **프로토콜** - HTTPS 전용
+ **HTTPS 포트** - 443
+ **최소 원본 SSL 프로토콜** – TLSv1.2
+ **오리진 경로** - 없음
+ **오리진 액세스 제어(콘솔만 해당)** - CloudFront에서 설정
+ **사용자 지정 헤더 추가** - 없음
+ **Origin Shield 활성화** - 아니요
+ **연결 시도** - 3
+ **응답 시간 초과** – 30
+ **연결 유지 시간 초과** – 5

다음은 CloudFront가 다중 테넌트 배포에서 API 게이트웨이 오리진에 대해 사전 구성하는 캐시 설정입니다.

**캐시 설정(사전 구성)**
+ **자동으로 객체 압축** - 예
+ **뷰어 프로토콜 정책** - HTTPS로 리디렉션
+ **허용된 HTTP 메서드** - `GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE`
+ **캐시 HTTP 메서드** - 아니요
+ **HTTP/2를 통한 gRPC 요청 허용** - 아니요
+ **뷰어 액세스 제한** - 아니요
+ **캐시 정책** - `CachingDisabled`(가능한 값: `UseOriginCacheControlHeaders`, `UseOriginCacheControlHeaders-QueryStrings`)
+ **원본 요청 정책** - `AllViewerExceptHostHeader`(가능한 값: `AllViewer`, `AllViewerandCloudFrontHeaders-2022-06`)
+ **응답 헤더 정책** - 없음
+ **스무스 스트리밍** - 아니요
+ **필드 레벨 암호화** - 아니요
+ **실시간 액세스 로그 활성화** - 아니요
+ **함수** - 아니요

다음은 다중 테넌트 배포에서 API 게이트웨이 오리진에 대해 사용자 지정할 수 있는 설정입니다.

**사용자 지정 가능한 설정**
+ **Origin Shield 활성화** – 기본값(아니요)
+ **자동으로 객체 압축** - 기본값(예)

## 사용자 지정 오리진 및 EC2 인스턴스
<a name="custom-ec2-origin-preconfiguration"></a>

다음은 CloudFront가 다중 테넌트 배포에서 사용자 지정 오리진에 대해 사전 구성하는 오리진 설정입니다.

**오리진 설정(사전 구성)**
+ **프로토콜** - 뷰어 일치
+ **HTTP 포트** - 80
+ **HTTPS 포트** - 443
+ **최소 원본 SSL 프로토콜** – TLSv1.2
+ **오리진 경로** - 없음
+ **사용자 지정 헤더 추가** - 없음
+ **Origin Shield 활성화** - 아니요
+ **연결 시도** - 3
+ **응답 시간 초과** – 30
+ **연결 유지 시간 초과** – 5

다음은 CloudFront가 다중 테넌트 배포의 사용자 지정 오리진 및 EC2 인스턴스에 대해 사전 구성하는 캐시 설정입니다.

**캐시 설정(사전 구성)**
+ **자동으로 객체 압축** - 예
+ **뷰어 프로토콜 정책** - HTTPS로 리디렉션
+ **허용된 HTTP 메서드** - `GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE`
+ **캐시 HTTP 메서드** - 아니요
+ **HTTP/2를 통한 gRPC 요청 허용** - 아니요
+ **뷰어 액세스 제한** - 아니요
+ **캐시 정책** - `UseOriginCacheControlHeaders`(가능한 값: `UseOriginCacheControlHeaders-QueryStrings`, `CachingDisabled`, `CacheOptimized`, `CachingOptimizedForUncompressedObjects`)
+ **원본 요청 정책** - `AllViewer`(가능한 값: `AllViewerExceptHostHeader`, `AllViewerandCloudFrontHeaders-2022-06`)
+ **응답 헤더 정책** - 없음
+ **스무스 스트리밍** - 아니요
+ **필드 레벨 암호화** - 아니요
+ **실시간 액세스 로그 활성화** - 아니요
+ **함수** - 아니요

다음은 다중 테넌트 배포에서 사용자 지정 오리진 및 EC2 인스턴스에 대해 사용자 지정할 수 있는 설정입니다.

**사용자 지정 가능한 설정**
+ **Origin Shield 활성화** – 기본값(아니요)
+ **자동으로 객체 압축** - 기본값(예)
+ **캐싱** - 기본값(`Cache by Default`)
  + `Cache by Default`를 선택하면 `UseOriginCacheControlHeaders` 캐시 정책이 사용됩니다.
  + `Do Not Cache by Default`를 선택하면 `CachingDisabled` 캐시 정책이 사용됩니다.
+ **캐시에 쿼리 문자열 포함** - 기본값(`Cache by Default`가 이미 선택된 경우 '예')
  + `Do Not Cache by Default`가 이미 선택되어 있고 캐시에 쿼리 문자열을 포함하도록 선택하면 `UseOriginCacheControlHeaders-QueryStrings` 캐시 정책이 사용됩니다.

## Elastic Load Balancing 오리진
<a name="elb-origin-preconfiguration"></a>

다음은 CloudFront가 다중 테넌트 배포에서 Elastic Load Balancing 오리진에 대해 사전 구성하는 오리진 설정입니다.

**오리진 설정(사전 구성)**
+ **프로토콜** - HTTPS 전용
+ **HTTPS 포트** - 443
+ **최소 원본 SSL 프로토콜** – TLSv1.2
+ **오리진 경로** - 없음
+ **사용자 지정 헤더 추가** - 없음
+ **Origin Shield 활성화** - 아니요
+ **연결 시도** - 3
+ **응답 시간 초과** – 30
+ **연결 유지 시간 초과** – 5

다음은 CloudFront가 다중 테넌트 배포에서 Elastic Load Balancing 오리진에 대해 사전 구성하는 캐시 설정입니다.

**캐시 설정(사전 구성)**
+ **자동으로 객체 압축** - 예
+ **뷰어 프로토콜 정책** - HTTPS로 리디렉션
+ **허용된 HTTP 메서드** - `GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE`
+ **캐시 HTTP 메서드** - 아니요
+ **HTTP/2를 통한 gRPC 요청 허용** - 아니요
+ **뷰어 액세스 제한** - 아니요
+ **캐싱** - 기본값(`Cache by Default`)
  + `Cache by Default`를 선택하면 `UseOriginCacheControlHeaders` 캐시 정책이 사용됩니다.
  + `Do Not Cache by Default`를 선택하면 `CachingDisabled` 캐시 정책이 사용됩니다.
+ **캐시에 쿼리 문자열 포함** - 기본값(`Cache by Default`가 이미 선택된 경우 '예')
  + `Do Not Cache by Default`가 이미 선택되어 있고 캐시에 쿼리 문자열을 포함하도록 선택하면 `UseOriginCacheControlHeaders-QueryStrings` 캐시 정책이 사용됩니다.
+ **원본 요청 정책** - `All Viewer`(가능한 값: `AllViewerExceptHostHeader`, `AllViewerandCloudFrontHeaders-2022-06`)
+ **응답 헤더 정책** - 없음
+ **스무스 스트리밍** - 아니요
+ **필드 레벨 암호화** - 아니요
+ **실시간 액세스 로그 활성화** - 아니요
+ **함수** - 아니요

다음은 다중 테넌트 배포에서 Elastic Load Balancing 오리진에 대해 사용자 지정할 수 있는 설정입니다.

**사용자 지정 가능한 설정**
+ **Origin Shield 활성화** – 기본값(아니요)
+ **자동으로 객체 압축** - 기본값(예)
+ **캐싱** - 기본값(`Cache by Default`)
  + `Cache by Default`를 선택하면 `UseOriginCacheControlHeaders` 캐시 정책이 사용됩니다.
  + `Do Not Cache by Default`를 선택하면 `CachingDisabled` 캐시 정책이 사용됩니다.
+ **캐시에 쿼리 문자열 포함** - 기본값(`Cache by Default`가 이미 선택된 경우 '예')
  + `Do Not Cache by Default`가 이미 선택되어 있고 캐시에 쿼리 문자열을 포함하도록 선택하면 `UseOriginCacheControlHeaders-QueryStrings` 캐시 정책이 사용됩니다.

## MediaPackage v1 오리진
<a name="media-package-v1-origin-preconfiguration"></a>

다음은 CloudFront가 다중 테넌트 배포에서 MediaPackage v1 오리진에 대해 사전 구성하는 오리진 설정입니다.

**오리진 설정(사전 구성)**
+ **프로토콜** - HTTPS 전용
+ **HTTPS 포트** - 443
+ **최소 원본 SSL 프로토콜** – TLSv1.2
+ **원본 경로** - MediaPackage URL을 입력하여 이를 제공
+ **사용자 지정 헤더 추가** - 없음
+ **Origin Shield 활성화** - 아니요
+ **연결 시도** - 3
+ **응답 시간 초과** – 30
+ **연결 유지 시간 초과** – 5

다음은 CloudFront가 다중 테넌트 배포에서 MediaPackage v1 오리진에 대해 사전 구성하는 캐시 설정입니다.

**캐시 설정(사전 구성)**
+ **자동으로 객체 압축** - 예
+ **뷰어 프로토콜 정책** - HTTPS로 리디렉션
+ **허용된 HTTP 메서드** - `GET, HEAD`
+ **캐시 HTTP 메서드** - 아니요
+ **HTTP/2를 통한 gRPC 요청 허용** - 아니요
+ **뷰어 액세스 제한** - 아니요
+ **캐시 정책** - `Elemental-MediaPackage`
+ **원본 요청 정책** - 없음
+ **응답 헤더 정책** - 없음
+ **스무스 스트리밍** - 아니요
+ **필드 레벨 암호화** - 아니요
+ **실시간 액세스 로그 활성화** - 아니요
+ **함수** - 아니요

## MediaPackage v2 오리진
<a name="media-package-v2-origin-preconfiguration"></a>

다음은 CloudFront가 다중 테넌트 배포에서 MediaPackage v2 오리진에 대해 사전 구성하는 오리진 설정입니다.

**오리진 설정(사전 구성)**
+ **원본 액세스 제어** - CloudFront에서 이를 설정하고 정책 추가
+ **프로토콜** - HTTPS 전용
+ **HTTPS 포트** - 443
+ **최소 원본 SSL 프로토콜** – TLSv1.2
+ **오리진 경로** - 없음
+ **사용자 지정 헤더 추가** - 없음
+ **Origin Shield 활성화** - 아니요
+ **연결 시도** - 3
+ **응답 시간 초과** – 30
+ **연결 유지 시간 초과** – 5

다음은 CloudFront가 다중 테넌트 배포에서 MediaPackage v2 오리진에 대해 사전 구성하는 캐시 설정입니다.

**캐시 설정(사전 구성)**
+ **자동으로 객체 압축** - 예
+ **뷰어 프로토콜 정책** - HTTPS로 리디렉션
+ **허용된 HTTP 메서드** - `GET, HEAD`
+ **캐시 HTTP 메서드** - 아니요
+ **HTTP/2를 통한 gRPC 요청 허용** - 아니요
+ **뷰어 액세스 제한** - 아니요
+ **캐시 정책** - `Elemental-MediaPackage`
+ **원본 요청 정책** - 없음
+ **응답 헤더 정책** - 없음
+ **스무스 스트리밍** - 아니요
+ **필드 레벨 암호화** - 아니요
+ **실시간 액세스 로그 활성화** - 아니요
+ **함수** - 아니요

## MediaTailor 오리진
<a name="media-tailor-origin-preconfiguration"></a>

다음은 CloudFront가 다중 테넌트 배포에서 MediaTailor 오리진에 대해 사전 구성하는 오리진 설정입니다.

**오리진 설정(사전 구성)**
+ **프로토콜** - HTTPS 전용
+ **HTTPS 포트** - 443
+ **최소 원본 SSL 프로토콜** – TLSv1.2
+ **원본 경로** - MediaPackage URL을 입력하여 이를 제공
+ **사용자 지정 헤더 추가** - 없음
+ **Origin Shield 활성화** - 아니요
+ **연결 시도** - 3
+ **응답 시간 초과** – 30
+ **연결 유지 시간 초과** – 5

다음은 CloudFront가 다중 테넌트 배포에서 MediaTailor 오리진에 대해 사전 구성하는 캐시 설정입니다.

**캐시 설정(사전 구성)**
+ **자동으로 객체 압축** - 예
+ **뷰어 프로토콜 정책** - HTTPS로 리디렉션
+ **허용된 HTTP 메서드** - `GET, HEAD`
+ **캐시 HTTP 메서드** - 아니요
+ **HTTP/2를 통한 gRPC 요청 허용** - 아니요
+ **뷰어 액세스 제한** - 아니요
+ **캐시 정책** - 없음
+ **원본 요청 정책** - `Elemental-MediaTailor-PersonalizedManifests`
+ **응답 헤더 정책** - 없음
+ **스무스 스트리밍** - 아니요
+ **필드 레벨 암호화** - 아니요
+ **실시간 액세스 로그 활성화** - 아니요
+ **함수** - 아니요

# 모든 배포 설정 참조
<a name="distribution-web-values-specify"></a>

배포를 생성하거나 업데이트할 때 CloudFront 배포 설정을 수동으로 편집하도록 선택할 수 있습니다. 다음은 편집할 수 있는 설정입니다.

하지만 CloudFront는 콘텐츠 오리진 유형에 따라 대부분의 배포 설정을 자동으로 구성합니다. 자세한 내용은 [사전 구성된 배포 설정 참조](template-preconfigured-origin-settings.md) 섹션을 참조하세요.

CloudFront 콘솔을 사용하여 배포를 만들거나 업데이트하는 자세한 내용은 [배포 생성](distribution-web-creating-console.md) 또는 [배포 업데이트](HowToUpdateDistribution.md) 단원을 참조하세요.

**Topics**
+ [오리진 설정](DownloadDistValuesOrigin.md)
+ [캐시 동작 설정](DownloadDistValuesCacheBehavior.md)
+ [배포 설정](DownloadDistValuesGeneral.md)
+ [사용자 지정 오류 페이지 및 오류 캐싱](DownloadDistValuesErrorPages.md)
+ [지리적 제한](DownloadDistValuesEnableGeoRestriction.md)

# 오리진 설정
<a name="DownloadDistValuesOrigin"></a>

CloudFront 콘솔을 사용하여 배포를 생성 또는 업데이트할 경우, 원래 버전의 웹 콘텐츠를 저장하는 하나 이상의 위치(오리진이라고도 함)에 대한 정보를 제공합니다.** CloudFront는 오리진에서 웹 콘텐츠를 가져와 이를 엣지 서버의 전 세계 네트워크를 통해 최종 사용자에게 제공합니다.

현재 하나의 배포에 대해 생성할 수 있는 오리진의 최대 수를 살펴보고 더 높은 할당량을 요청하려면, [배포의 일반 할당량](cloudfront-limits.md#limits-web-distributions) 섹션을 참조하세요.

오리진을 삭제하려는 경우 먼저 해당 오리진에 연결된 캐시 동작을 편집하거나 삭제해야 합니다.

**중요**  
오리진을 삭제할 경우 이전에 해당 오리진에서 제공된 파일이 다른 오리진에서 사용 가능하고 캐시 동작이 현재 그러한 파일에 대한 요청을 새 오리진에 라우팅하는지 확인합니다.

배포를 생성 또는 업데이트할 경우 각 오리진에 대해 다음 값을 지정합니다.

**Topics**
+ [오리진 도메인](#DownloadDistValuesDomainName)
+ [프로토콜(사용자 지정 오리진만 해당)](#DownloadDistValuesOriginProtocolPolicy)
+ [오리진 경로](#DownloadDistValuesOriginPath)
+ [이름](#DownloadDistValuesId)
+ [오리진 액세스(Amazon S3 오리진에만 해당)](#DownloadDistValuesOAIRestrictBucketAccess)
+ [사용자 지정 헤더 추가](#DownloadDistValuesOriginCustomHeaders)
+ [Origin Shield 사용](#create-update-fields-origin-shield)
+ [연결 시도](#origin-connection-attempts)
+ [연결 제한 시간](#origin-connection-timeout)
+ [응답 제한 시간](#DownloadDistValuesOriginResponseTimeout)
+ [응답 완료 제한 시간](#response-completion-timeout)
+ [연결 유지 제한 시간(사용자 지정 및 VPC 오리진만 해당)](#DownloadDistValuesOriginKeepaliveTimeout)
+ [응답 및 연결 유지 제한 시간 할당량](#response-keep-alive-timeout-quota)

## 오리진 도메인
<a name="DownloadDistValuesDomainName"></a>

오리진 도메인은 CloudFront가 오리진(예: Amazon S3 버킷 또는 HTTP 서버)에 대한 객체를 가져올 리소스의 DNS 도메인 이름입니다. 예제:
+ **Amazon S3 버킷** – `amzn-s3-demo-bucket.s3.us-west-2.amazonaws.com`
**참고**  
최근에 S3 버킷을 만든 경우 CloudFront 배포에서 최대 24시간 동안 `HTTP 307 Temporary Redirect` 응답을 반환할 수 있습니다. S3 버킷 이름이 모든 AWS 리전에 전파되는 데 최대 24시간이 걸릴 수 있습니다. 전파가 완료되면, 배포에서는 이러한 리디렉션 응답 전송을 자동으로 중지하므로 별도로 조치를 취할 필요가 없습니다. 자세한 내용은 [Amazon S3에서 HTTP 307 임시 리디렉션 응답을 받는 이유는 무엇입니까?](https://repost.aws/knowledge-center/s3-http-307-response) 및 [임시 요청 리디렉션](https://docs.aws.amazon.com/AmazonS3/latest/dev/Redirects.html#TemporaryRedirection)을 참조하십시오.
+ **웹 사이트로 구성된 Amazon S3 버킷** - `amzn-s3-demo-bucket.s3-website.us-west-2.amazonaws.com`
+ **MediaStore 컨테이너** - `examplemediastore.data.mediastore.us-west-1.amazonaws.com`
+ **MediaPackage 엔드포인트** – `examplemediapackage.mediapackage.us-west-1.amazonaws.com`
+ **Amazon EC2 인스턴스** – `ec2-203-0-113-25.compute-1.amazonaws.com`
+ **Elastic Load Balancing 로드 밸런서** – `example-load-balancer-1234567890.us-west-2.elb.amazonaws.com`
+ **자체 웹 서버** - `www.example.com`

**오리진 도메인(Origin domain)** 필드에서 도메인 이름을 선택하거나, 이름을 입력합니다. 옵트인 리전의 리소스는 수동으로 입력해야 합니다. 도메인 이름은 대소문자를 구분하지 않습니다. 오리진 도메인은 인터넷을 통해 클라이언트의 요청을 대상으로 라우팅하는 공개적으로 확인 가능한 DNS 이름을 포함해야 합니다.

CloudFront가 HTTPS를 통해 오리진에 연결하도록 구성하는 경우, 인증서의 도메인 이름 중 하나는 **오리진 도메인 이름**으로 지정하는 도메인 이름과 일치해야 합니다. 일치하는 도메인 이름이 없는 경우 CloudFront는 최종 사용자에게 HTTP 상태 코드 502(잘못된 게이트웨이)를 반환합니다. 자세한 내용은 [CloudFront 배포 및 인증서의 도메인 이름](cnames-and-https-requirements.md#https-requirements-domain-names-in-cert) 및 [CloudFront와 사용자 지정 원본 서버 간의 SSL/TLS 협상 실패](http-502-bad-gateway.md#ssl-negotitation-failure)(을)를 참조하세요.

**참고**  
최종 사용자 호스트 헤더를 오리진으로 전달하는 오리진 요청 정책을 사용하는 경우, 오리진은 최종 사용자 호스트 헤더와 일치하는 인증서로 응답해야 합니다. 자세한 내용은 [CloudFront 요청 헤더 추가](adding-cloudfront-headers.md) 섹션을 참조하세요.

오리진이 Amazon S3 버킷인 경우 다음에 유의하세요.
+ 버킷이 웹 사이트로 구성된 경우, 버킷에 대한 Amazon S3 정적 웹 사이트 호스팅 엔드포인트를 입력합니다. **오리진 도메인(Origin domain)** 필드의 목록에서 버킷 이름을 선택하지 마세요. 정적 웹 사이트 호스팅 엔드포인트는 Amazon S3 콘솔에서 **속성(Properties)** 페이지의 **정적 웹 사이트 호스팅(Static website hosting)** 아래에 나타납니다. 자세한 내용은 [웹 사이트 엔드포인트로 구성된 Amazon S3 버킷 사용](DownloadDistS3AndCustomOrigins.md#concept_S3Origin_website) 섹션을 참조하세요.
+ 버킷에 Amazon S3 Transfer Acceleration을 구성한 경우, **오리진 도메인(Origin domain)**에 `s3-accelerate` 엔드포인트를 지정하지 마세요.
+ 다른 AWS 계정에서 버킷을 사용하려는 경우 버킷이 웹 사이트로 구성되어 있지 않으면 다음 형식을 사용하여 이름을 입력합니다.

  `bucket-name.s3.region.amazonaws.com` 

  버킷이 미국 리전에 있고 Amazon S3에서 요청을 버지니아 북부의 시설로 라우팅하려는 경우, 다음 형식을 사용합니다.

  `bucket-name.s3.us-east-1.amazonaws.com` 
+ CloudFront 오리진 액세스 제어를 사용하여 Amazon S3의 콘텐츠에 보안을 적용하지 않는 한, 파일은 공개적으로 읽기 가능해야 합니다. 액세스 제어에 대한 자세한 내용은 [Amazon S3 오리진에 대한 액세스 제한](private-content-restricting-access-to-s3.md) 섹션을 참조하세요.

**중요**  
오리진이 Amazon S3 버킷인 경우, DNS 명명 요구 사항을 준수하는 버킷 이름을 사용해야 합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [버킷 규제 및 제한](https://docs.aws.amazon.com/AmazonS3/latest/userguide/BucketRestrictions.html)을 참조하세요.

오리진에 대한 **오리진 도메인(Origin domain)**의 값을 변경하면 CloudFront에서는 CloudFront 엣지 로케이션에 대한 변경 사항 복제를 즉시 시작합니다. 배포 구성이 지정된 엣지 로케이션에서 업데이트될 때까지 CloudFront는 계속해서 요청을 이전 오리진으로 전달합니다. 배포 구성이 해당 엣지 로케이션에서 업데이트되는 즉시 CloudFront에서는 요청을 새 오리진으로 전달하기 시작합니다.

버킷을 변경하더라도 CloudFront에서는 엣지 캐시를 새 오리진의 객체로 다시 채울 필요가 없습니다. 애플리케이션의 최종 사용자 요청이 변경되지 않는 한, CloudFront에서는 각 객체의 TTL이 만료되거나 자주 요청되지 않는 객체가 제거될 때까지는 계속해서 엣지 캐시에 이미 존재하는 객체를 제공합니다.

## 프로토콜(사용자 지정 오리진만 해당)
<a name="DownloadDistValuesOriginProtocolPolicy"></a>

**참고**  
이는 사용자 지정 오리진에만 적용됩니다.

오리진에서 객체를 가져올 때 CloudFront에서 사용하려는 프로토콜 정책입니다.

다음 값 중 하나를 선택합니다.
+ **HTTP만(HTTP only):** CloudFront에서 HTTPS만 사용하여 오리진에 액세스합니다.
**중요**  
Amazon S3가 정적 웹 사이트 호스팅 엔드포인트에 대한 HTTPS 연결을 지원하지 않으므로 오리진이 Amazon S3 정적 웹 사이트 호스팅 엔드포인트인 경우 **HTTP만(HTTP only)**이 기본 설정입니다. CloudFront 콘솔에서는 Amazon S3 정적 웹 사이트 호스팅 엔드포인트에 대해 이 설정을 변경할 수 없습니다.
+ **HTTPS만(HTTPS only):** CloudFront에서 HTTPS만 사용하여 오리진에 액세스합니다.
+ **최종 사용자와 일치(Match viewer)** - CloudFront에서 최종 사용자 요청의 프로토콜에 따라 HTTP 또는 HTTPS를 사용하여 오리진과 통신합니다. 최종 사용자가 HTTP 및 HTTPS 프로토콜 모두를 사용하여 요청하더라도 CloudFront에서는 한 번만 객체를 캐싱합니다.
**중요**  
CloudFront에서 이 오리진에 전달하는 HTTPS 최종 사용자 요청의 경우, 원본 서버의 SSL/TLS 인증서에 있는 도메인 이름 중 하나가 **오리진 도메인(Origin domain)**으로 지정한 도메인 이름과 일치해야 합니다. 그렇지 않은 경우 CloudFront는 최종 사용자 요청에 대해 요청된 객체를 반환하는 대신 HTTP 상태 코드 502(잘못된 게이트웨이)로 응답합니다. 자세한 내용은 [CloudFront에서 SSL/TLS 인증서를 사용하기 위한 요구 사항](cnames-and-https-requirements.md) 단원을 참조합니다.

**Topics**
+ [HTTP 포트](#DownloadDistValuesHTTPPort)
+ [HTTPS 포트](#DownloadDistValuesHTTPSPort)
+ [최소 오리진 SSL 프로토콜](#DownloadDistValuesOriginSSLProtocols)

### HTTP 포트
<a name="DownloadDistValuesHTTPPort"></a>

**참고**  
이는 사용자 지정 오리진에만 적용됩니다.

(선택 사항) 사용자 지정 오리진이 수신 대기하는 HTTP 포트를 지정할 수 있습니다. 유효한 값에는 포트 80, 443 및 1024\$165535가 포함됩니다. 기본값은 포트 80입니다.

**중요**  
Amazon S3가 정적 웹 사이트 호스팅 엔드포인트에 대해 포트 80만 지원하므로 오리진이 Amazon S3 정적 웹 사이트 호스팅 엔드포인트인 경우 포트 80이 기본 설정입니다. CloudFront 콘솔에서는 Amazon S3 정적 웹 사이트 호스팅 엔드포인트에 대해 이 설정을 변경할 수 없습니다.

### HTTPS 포트
<a name="DownloadDistValuesHTTPSPort"></a>

**참고**  
이는 사용자 지정 오리진에만 적용됩니다.

(선택 사항) 사용자 지정 오리진이 수신 대기하는 HTTPS 포트를 지정할 수 있습니다. 유효한 값에는 포트 80, 443 및 1024\$165535가 포함됩니다. 기본값은 포트 443입니다. **프로토콜(Protocol)**이 **HTTP만(HTTP only)**으로 설정된 경우 **HTTPS 포트(HTTPS port)**에 값을 지정할 수 없습니다.

### 최소 오리진 SSL 프로토콜
<a name="DownloadDistValuesOriginSSLProtocols"></a>

**참고**  
이는 사용자 지정 오리진에만 적용됩니다.

오리진에 대한 HTTPS 연결을 설정할 때 CloudFront가 사용할 수 있는 최소 TLS/SSL 프로토콜을 선택합니다. TLS 프로토콜이 낮을수록 보안이 낮으므로, 오리진이 지원하는 최신 TLS 프로토콜을 선택하는 것이 좋습니다. **프로토콜(Protocol)**이 **HTTP만(HTTP only)**으로 설정된 경우 **최소 오리진 SSL 프로토콜(Minimum origin SSL protocol)**에 값을 지정할 수 없습니다.

CloudFront API를 사용하여 CloudFront에 사용할 TLS/SSL 프로토콜을 설정하는 경우 최소 프로토콜을 설정할 수 없습니다. 대신, CloudFront에서 오리진과 함께 사용할 수 있는 모든 TLS/SSL 프로토콜을 지정합니다. 자세한 내용은 *Amazon CloudFront API 참조*의 [OriginSslProtocols](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginSslProtocols.html)를 참조하세요.

## 오리진 경로
<a name="DownloadDistValuesOriginPath"></a>

CloudFront가 해당 오리진에 있는 디렉터리에서 콘텐츠를 요청하게 하려면 슬래시(/) 뒤에 디렉터리 경로를 입력합니다. CloudFront는 **오리진 도메인(Origin domain)**의 값에 디렉터리 이름을 추가합니다(예: **cf-origin.example.com/production/images**). 경로 끝에는 슬래시(/)를 추가하지 마십시오.

예를 들어, 배포에 대해 다음 값을 지정했다고 가정해 보겠습니다.
+ **오리진 도메인(Origin domain)** - 이름이 **amzn-s3-demo-bucket**인 Amazon S3 버킷
+ **오리진 경로(Origin path**)**/production** - 
+ **대체 도메인 이름(CNAME)(Alternate domain names(CNAME)**)**example.com** – 

한편, 사용자가 브라우저에 `example.com/index.html`을 입력하면 CloudFront는 Amazon S3에 `amzn-s3-demo-bucket/production/index.html`에 대한 요청을 보냅니다.

한편, 사용자가 브라우저에 `example.com/acme/index.html`을 입력하면 CloudFront는 Amazon S3에 `amzn-s3-demo-bucket/production/acme/index.html`에 대한 요청을 보냅니다.

## 이름
<a name="DownloadDistValuesId"></a>

이름은 이 배포 내의 이 오리진을 고유하게 식별하는 문자열입니다. 기본 캐시 동작에 추가로 캐시 동작을 만들 경우, 여기에서 지정한 이름을 사용하여 요청이 해당 캐시 동작의 경로 패턴과 일치할 때 CloudFront에서 요청을 라우팅하려는 오리진을 식별합니다.

## 오리진 액세스(Amazon S3 오리진에만 해당)
<a name="DownloadDistValuesOAIRestrictBucketAccess"></a>

**참고**  
이는 Amazon S3 버킷 오리진(S3 정적 웹 사이트 엔드포인트를 사용하지 *않는* 오리진)에만 적용됩니다.

Amazon S3 버킷 오리진에 대한 액세스를 특정 CloudFront 배포로만 제한할 수 있도록 하려면 **Origin access control settings(recommended)**(원본 액세스 제어 설정(권장))를 선택합니다.

Amazon S3 버킷 오리진에 공개적으로 액세스할 수 있는 경우 **Public**(공개)을 선택합니다.

자세한 내용은 [Amazon S3 오리진에 대한 액세스 제한](private-content-restricting-access-to-s3.md) 단원을 참조합니다.

사용자가 CloudFront URL만 사용하여 사용자 지정 오리진의 객체에 액세스할 수 있도록 요구하는 방법에 대한 자세한 내용은 [사용자 지정 오리진의 파일에 대한 액세스 제한](private-content-overview.md#forward-custom-headers-restrict-access) 단원을 참조하세요.

## 사용자 지정 헤더 추가
<a name="DownloadDistValuesOriginCustomHeaders"></a>

CloudFront가 오리진에 요청을 보낼 때마다 사용자 지정 헤더를 추가하도록 하려면 헤더 이름과 값을 지정합니다. 자세한 내용은 [사용자 지정 헤더를 오리진 요청에 추가](add-origin-custom-headers.md) 단원을 참조합니다.

현재 추가할 수 있는 사용자 지정 헤더의 최대 수, 사용자 지정 헤더 이름과 값의 최대 길이 및 모든 헤더 이름 및 값의 최대 총 길이는 [할당량](cloudfront-limits.md) 단원을 참조하세요.

## Origin Shield 사용
<a name="create-update-fields-origin-shield"></a>

CloudFront Origin Shield를 사용하려면 **예(Yes)**를 선택합니다. Origin Shield에 대한 자세한 내용은 [Amazon CloudFront Origin Shield 사용](origin-shield.md) 단원을 참조하세요.

## 연결 시도
<a name="origin-connection-attempts"></a>

CloudFront가 오리진에 연결을 시도하는 횟수를 설정할 수 있습니다. 시도 횟수로 1, 2 또는 3을 지정할 수 있습니다. 기본 숫자는 3입니다(달리 지정하지 않은 경우).

이 설정을 **연결 제한 시간(Connection timeout)**과 함께 사용하여 CloudFront가 보조 오리진에 연결하려고 시도하거나 최종 사용자에게 오류 응답을 반환하기 전에 대기하는 시간을 지정합니다. 기본적으로 CloudFront는 보조 오리진에 연결하거나 오류 응답을 반환하기 전에 30초(각각 10초 동안 3회 시도)까지 기다립니다. 더 적은 시도 횟수, 더 짧은 연결 제한 시간 또는 둘 다를 지정하여 이 시간을 줄일 수 있습니다.

지정된 수의 연결 시도가 실패하면 CloudFront에서 다음 중 하나를 수행합니다.
+ 오리진이 오리진 그룹의 일부인 경우 CloudFront는 보조 오리진에 연결을 시도합니다. 보조 오리진에 대한 지정된 수의 연결 시도가 실패하면 CloudFront는 최종 사용자에게 오류 응답을 반환합니다.
+ 오리진이 오리진 그룹의 일부가 아닌 경우 CloudFront가 최종 사용자에게 오류 응답을 반환합니다.

사용자 지정 오리진(정적 웹 사이트 호스팅으로 구성된 Amazon S3 버킷 포함)의 경우 이 설정은 CloudFront가 오리진에서 응답을 받으려고 시도하는 횟수도 지정합니다. 자세한 내용은 [응답 제한 시간](#DownloadDistValuesOriginResponseTimeout) 단원을 참조합니다.

## 연결 제한 시간
<a name="origin-connection-timeout"></a>

오리진 연결 제한 시간은 CloudFront가 오리진에 대한 연결을 설정하려고 할 때 기다리는 시간(초)입니다. 1초에서 10초까지 시간을 지정할 수 있습니다. 기본 제한 시간은 10초입니다(달리 지정하지 않은 경우).

이 설정을 **연결 시도 횟수(Connection attempts)**와 함께 사용하여 CloudFront가 보조 오리진에 연결하려고 시도하거나 최종 사용자에게 오류 응답을 반환하기 전에 대기하는 시간을 지정합니다. 기본적으로 CloudFront는 보조 오리진에 연결하거나 오류 응답을 반환하기 전에 30초(각각 10초 동안 3회 시도)까지 기다립니다. 더 적은 시도 횟수, 더 짧은 연결 제한 시간 또는 둘 다를 지정하여 이 시간을 줄일 수 있습니다.

CloudFront에서 지정된 시간(초) 내에 오리진에 대한 연결을 설정하지 않으면 CloudFront에서 다음 중 하나를 수행합니다.
+ 지정된 **연결 시도 횟수(Connection attempts)**가 1보다 많으면 CloudFront가 다시 연결을 설정하려고 시도합니다. CloudFront는 **연결 시도 횟수(Connection attempts)** 값에 따라 최대 3회까지 시도합니다.
+ 연결 시도가 실패하고 오리진이 오리진 그룹의 일부인 경우 CloudFront는 보조 오리진에 연결을 시도합니다. 보조 오리진에 대한 지정된 수의 연결 시도가 실패하면 CloudFront는 최종 사용자에게 오류 응답을 반환합니다.
+ 모든 연결 시도가 실패하고 오리진이 오리진 그룹의 일부가 아닌 경우 CloudFront가 최종 사용자에게 오류 응답을 반환합니다.

## 응답 제한 시간
<a name="DownloadDistValuesOriginResponseTimeout"></a>

오리진 응답 제한 시간(*오리진 읽기 제한 시간* 또는 *오리진 요청 제한 시간*이라고도 함)은 다음 두 값에 모두 적용됩니다.
+ CloudFront가 오리진에 요청을 전달한 후 응답을 기다리는 시간(초).
+ CloudFront가 오리진으로부터 응답 패킷을 수신한 후 다음 패킷을 수신할 때까지 대기하는 시간(초).

**작은 정보**  
최종 사용자가 HTTP 504 상태 코드 오류를 경험하고 있기 때문에 오리진 응답 제한 시간 값을 늘리고 싶은 경우에는 제한 시간 값을 변경하기 앞서 이러한 오류를 제거할 수 있는 다른 방법들을 시도해 봅니다. [HTTP 504 상태 코드(게이트웨이 제한 시간)](http-504-gateway-timeout.md)에서 문제 해결 주제를 참조합니다.

CloudFront 동작은 최종 사용자 요청 내 HTTP 메서드에 따라 달라집니다.
+ `GET` 및 `HEAD` 요청 - 오리진에서 응답 제한 시간 내에 응답하지 않거나 응답이 중지된 경우, CloudFront에서는 연결을 끊습니다. CloudFront는 [연결 시도](#origin-connection-attempts)의 값에 따라 연결을 다시 시도합니다.
+ `DELETE`, `OPTIONS`, `PATCH`, `PUT` 및 `POST` 요청 - 오리진이 읽기 제한 시간 동안 응답하지 않는 경우, CloudFront는 연결을 끊고 오리진에 다시 연결을 시도하지 않습니다. 필요한 경우 클라이언트는 요청을 다시 제출할 수 있습니다.

## 응답 완료 제한 시간
<a name="response-completion-timeout"></a>

**참고**  
응답 완료 제한 시간은 [지속적 배포](continuous-deployment.md) 기능을 지원하지 않습니다.

CloudFront에서 오리진으로의 요청이 열려 있고 응답을 기다릴 수 있는 시간(초). 이 시간까지 오리진에서 완전한 응답을 받지 못하면 CloudFront는 연결을 종료합니다.

*개별* 응답 패킷의 대기 시간인 **응답 제한 시간**과 달리 **응답 완료 제한 시간**은 CloudFront가 응답이 완료될 때까지 대기하는 *최대* 허용 시간입니다. 이 설정을 사용하면 다른 제한 시간 설정에서 더 긴 대기 시간을 허용하는 경우에도 CloudFront가 느리거나 응답하지 않는 오리진을 무기한 기다리지 않도록 할 수 있습니다.

이 최대 제한 시간에는 다른 제한 시간 설정에 지정한 사항과 각 재시도에 대한 **연결 시도** 횟수가 포함됩니다. 이러한 설정을 함께 사용하여 CloudFront가 전체 요청을 기다리는 시간과 요청이 완료되었는지 여부에 관계없이 요청을 종료할 시기를 지정할 수 있습니다.

예를 들어 다음 설정을 지정했다고 해보겠습니다.
+ **연결 시도** 3회
+ **연결 제한 시간** 10초
+ **응답 제한 시간** 30초
+ **응답 완료 제한 시간** 60초

이 경우 CloudFront는 오리진에 연결을 시도하며(최대 총 3회 시도), 각 연결 시도는 10초 후에 시간 초과됩니다. 연결되면 CloudFront는 오리진이 요청에 응답할 때까지 최대 30초 동안 대기한 후 마지막 응답 패킷을 수신합니다.

연결 시도 횟수 또는 응답 제한 시간에 관계없이 오리진의 전체 응답이 완료되는 데 60초 이상 걸리는 경우 CloudFront는 연결을 종료합니다. 그런 다음 CloudFront는 [HTTP 504 상태 코드(게이트웨이 제한 시간)](http-504-gateway-timeout.md) 오류 응답 또는 사용자 지정 오류 응답(지정한 경우)을 뷰어에 반환합니다.

**참고**  
응답 완료 제한 시간 값을 설정하는 경우, 해당 값은 [응답 제한 시간(오리진 읽기 제한 시간)](#DownloadDistValuesOriginResponseTimeout) 값보다 크거나 같아야 합니다.
응답 완료 제한 시간 값을 설정하지 않으면 CloudFront에서 최대값을 적용하지 않습니다.

## 연결 유지 제한 시간(사용자 지정 및 VPC 오리진만 해당)
<a name="DownloadDistValuesOriginKeepaliveTimeout"></a>

연결 유지 제한 시간은 CloudFront가 응답의 마지막 패킷을 가져온 후 연결을 유지하기 위해 시도하는 시간(초)입니다. 지속적인 연결을 유지하면 TCP 연결 재설정 및 이후 요청에 대한 별도의 TLS 핸드쉐이크 수행에 필요한 시간이 절약됩니다. 연결 유지 제한 시간을 늘리면 배포에서 연결당 요청 지표를 개선할 수 있습니다.

**참고**  
**연결 유지 제한 시간(Keep-alive timeout)** 값이 유효하려면 오리진이 지속적 연결을 허용하도록 구성되어야 합니다.

## 응답 및 연결 유지 제한 시간 할당량
<a name="response-keep-alive-timeout-quota"></a>
+ [응답 시간 제한](#DownloadDistValuesOriginResponseTimeout)의 경우 기본값은 30초입니다.
+ [연결 유지 제한 시간](#DownloadDistValuesOriginKeepaliveTimeout)의 경우 기본값은 5초입니다.

AWS 계정에 대한 제한 시간 증가를 요청하는 경우 배포 오리진을 업데이트하여 원하는 응답 제한 시간 및 연결 유지 제한 시간 값을 갖도록 합니다. 계정 할당량을 늘려도 오리진이 자동으로 업데이트되지는 않습니다. 예를 들어 Lambda@Edge 함수를 사용하여 연결 유지 제한 시간을 90초로 설정하는 경우 오리진의 연결 유지 제한 시간이 이미 90초 이상으로 설정되어 있어야 합니다. 그렇지 않으면 Lambda@Edge 함수가 실행되지 않을 수 있습니다.

증가 요청 방법을 비롯한 배포 할당량에 대한 자세한 내용은 [배포의 일반 할당량](cloudfront-limits.md#limits-web-distributions) 섹션을 참조하세요.

# 캐시 동작 설정
<a name="DownloadDistValuesCacheBehavior"></a>

캐시 동작을 설정하면 웹사이트에 있는 파일의 지정된 URL 경로 패턴에 대해 다양한 CloudFront 기능을 구성할 수 있습니다. 예를 들어, 하나의 캐시 동작이 CloudFront용 오리진 서버로 사용 중인 웹 서버의 `.jpg` 디렉터리에 있는 전체 `images` 파일에 적용될 수 있습니다. 각 캐시 동작에 대해 구성 가능한 기능에는 다음이 포함됩니다.
+ 경로 패턴
+ CloudFront 배포에 대해 다수의 오리진을 구성한 경우, CloudFront에서 요청을 전달하려는 대상 오리진
+ 쿼리 문자열을 오리진에 전달할지 여부
+ 지정된 파일에 액세스하기 위해 서명된 URL이 필요한지 여부
+ 사용자가 HTTPS를 사용하여 그러한 파일에 액세스하도록 지정할지 여부
+ 오리진에서 파일에 추가한 `Cache-Control` 헤더의 값과 관계없이 그러한 파일이 CloudFront 캐시에 머무르는 최소 시간

새 배포를 만든 경우, 배포를 만들 때 지정한 오리진에 모든 요청을 자동으로 전달하는 기본 캐시 동작에 대해 설정을 지정합니다. 배포를 만든 후에는 경로 패턴과 일치하는 객체(예: `*.jpg`)에 대한 요청을 받았을 때 CloudFront에서 응답하는 방식을 정의하는 추가 캐시 동작을 만들 수 있습니다. 추가 캐시 동작을 만든 경우 기본 캐시 동작은 항상 마지막으로 처리됩니다. 나머지 캐시 동작은 CloudFront 콘솔에 나열한 순서에 따라 처리됩니다. 또는 CloudFront API를 사용하는 경우 배포에 대한 `DistributionConfig` 요소에 나열한 순서대로 처리됩니다. 자세한 내용은 [경로 패턴](#DownloadDistValuesPathPattern) 단원을 참조합니다.

캐시 동작을 만들 때 CloudFront에서 객체를 가져오려는 대상 오리진을 하나만 지정합니다. CloudFront에서 오리진 전체로부터 객체를 배포하려는 경우, 기본 캐시 동작을 포함해 캐시 동작은 최소한 보유한 오리진의 수만큼 있어야 합니다. 예를 들어 두 개의 오리진이 있는 경우 기본 캐시 동작이 하나뿐이라면, 이 기본 캐시 동작으로 인해 CloudFront는 두 개의 오리진 중 하나에서 객체를 가져오지만, 나머지 오리진은 사용되지 않습니다.

현재 하나의 배포에 추가할 수 있는 캐시 동작의 최대 수를 살펴보고 더 높은 할당량(이전에는 제한이라고 함)을 요청하려면, [배포의 일반 할당량](cloudfront-limits.md#limits-web-distributions) 단원을 참조하세요.

**Topics**
+ [경로 패턴](#DownloadDistValuesPathPattern)
+ [오리진 또는 오리진 그룹](#DownloadDistValuesTargetOriginId)
+ [뷰어 프로토콜 정책](#DownloadDistValuesViewerProtocolPolicy)
+ [허용되는 HTTP 메서드](#DownloadDistValuesAllowedHTTPMethods)
+ [필드 레벨 암호화 구성](#DownloadDistValuesFieldLevelEncryption)
+ [캐싱된 HTTP 메서드](#DownloadDistValuesCachedHTTPMethods)
+ [HTTP/2를 통한 gRPC 요청 허용](#enable-grpc-distribution)
+ [선택한 요청 헤더 기반의 캐시](#DownloadDistValuesForwardHeaders)
+ [허용 목록 헤더](#DownloadDistValuesAllowlistHeaders)
+ [객체 캐싱](#DownloadDistValuesObjectCaching)
+ [Minimum TTL](#DownloadDistValuesMinTTL)
+ [Maximum TTL](#DownloadDistValuesMaxTTL)
+ [기본 TTL](#DownloadDistValuesDefaultTTL)
+ [쿠키 전달](#DownloadDistValuesForwardCookies)
+ [허용 목록 쿠키](#DownloadDistValuesAllowlistCookies)
+ [쿼리 문자열 전달 및 캐싱](#DownloadDistValuesQueryString)
+ [쿼리 문자열 허용 목록](#DownloadDistValuesQueryStringAllowlist)
+ [Smooth Streaming](#DownloadDistValuesSmoothStreaming)
+ [최종 사용자 액세스 제한(서명된 URL 또는 서명된 쿠키 사용)](#DownloadDistValuesRestrictViewerAccess)
+ [신뢰할 수 있는 서명자](#DownloadDistValuesTrustedSigners)
+ [AWS 계정 번호](#DownloadDistValuesAWSAccountNumbers)
+ [자동으로 객체를 압축](#DownloadDistValuesCompressObjectsAutomatically)
+ [CloudFront 이벤트](#DownloadDistValuesEventType)
+ [Lambda 함수 ARN](#DownloadDistValuesLambdaFunctionARN)
+ [본문 포함](#include-body)

## 경로 패턴
<a name="DownloadDistValuesPathPattern"></a>

경로 패턴(예: `images/*.jpg`)은 이 캐시 동작을 적용하려는 요청을 지정합니다. CloudFront가 최종 사용자 요청을 받으면, 요청된 경로는 배포에 나열된 캐시 동작의 순서대로 경로 패턴과 비교됩니다. 첫 번째 일치 결과로 해당 요청에 적용되는 캐시 동작이 결정됩니다. 예를 들어, 다음과 같은 3개의 경로 패턴과 순서로 3개의 캐시 동작이 있다고 가정합니다.
+ `images/*.jpg`
+ `images/*`
+ `*.gif`

**참고**  
`/images/*.jpg`와 같이 경로 패턴 시작 부분에 슬래시(/)를 포함하도록 선택할 수 있습니다. 선행 / 포함 여부와 상관 없이 CloudFront의 동작은 동일합니다. 경로 시작 부분에 /를 지정하지 않으면 이 문자가 자동으로 암시되며, CloudFront는 선행 /가 있든 없든 경로를 동일하게 처리합니다. 예를 들어, CloudFront는 `/*product.jpg`와 `*product.jpg`를 동일하게 취급합니다.

`images/sample.gif` 파일에 대한 요청은 첫 번째 경로 패턴을 충족하지 않으므로 연결된 캐시 동작은 이 요청에 적용되지 않습니다. 이 파일은 두 번째 경로 패턴을 만족하므로 세 번째 경로 패턴과도 일치하더라도 두 번째 경로 패턴과 연결된 캐시 동작이 이 요청에 적용됩니다.

**참고**  
새 배포를 만들 때 기본 캐시 동작에 대한 **경로 패턴**의 값은 **\$1**(모든 파일)로 설정되고 이는 변경할 수 없습니다. 이 값에 따라 CloudFront에서는 객체에 대한 모든 요청을 [오리진 도메인](DownloadDistValuesOrigin.md#DownloadDistValuesDomainName) 필드에서 지정한 오리진으로 전달합니다. 객체에 대한 요청이 나머지 캐시 동작 중 어느 것의 경로 패턴과도 일치하지 않는 경우, CloudFront에서는 기본 캐시 동작에서 지정한 동작을 적용합니다.

**중요**  
경로 패턴과 그 순서를 주의 깊게 정의하지 않으면 사용자에게 콘텐츠에 대한 원치 않는 액세스 권한을 주게 될 수 있습니다. 예를 들어, 하나의 요청이 두 캐시 동작의 경로 패턴과 일치한다고 가정합니다. 첫 번째 캐시 동작은 서명된 URL이 필요하고 두 번째 캐시 동작은 서명된 URL이 필요하지 않습니다. CloudFront에서는 첫 번째 일치 결과와 연결된 캐시 동작을 처리하므로 사용자는 서명된 URL을 사용하지 않고도 객체에 액세스할 수 있습니다.

MediaPackage 채널을 사용하는 경우, 오리진의 엔드포인트 유형에 대해 정의하는 캐시 동작을 위한 특정 경로 패턴을 포함시켜야 합니다. 예를 들어 DASH 엔드포인트의 경우 **경로 패턴**에 `*.mpd`를 입력합니다. 자세한 정보와 특정 지침은 [AWS Elemental MediaPackage를 사용하여 포맷된 라이브 비디오 제공](live-streaming.md#live-streaming-with-mediapackage) 단원을 참조하십시오.

사용자가 지정한 경로는 지정된 디렉터리와 이 디렉터리의 하위 디렉터리에 있는 모든 파일에 대한 요청에 적용됩니다. CloudFront에서는 경로 패턴을 평가할 때 쿼리 문자열 또는 쿠키를 고려하지 않습니다. 예를 들어, `images` 디렉터리에 `product1` 및 `product2` 하위 디렉터리가 포함되어 있으면, 경로 패턴 `images/*.jpg`는 모든 `images`, `images/product1`, `images/product2` 디렉터리의 모든 .jpg 파일에 대한 요청에 적용됩니다. 다른 캐시 동작을 `images/product1` 및 `images` 디렉터리의 파일이 아닌 `images/product2` 디렉터리의 파일에 적용하려는 경우, `images/product1`에 대한 별도의 캐시 동작을 만들어 `images` 디렉터리에 대한 캐시 동작보다 위로(이전으로) 해당 캐시 동작을 이동합니다.

다음 와일드카드 문자를 경로 패턴에 사용할 수 있습니다.
+ `*`는 0개 이상의 문자에 해당합니다.
+ `?`는 정확히 1문자에 해당합니다.

다음 예는 와일드카드 문자가 어떻게 작동하는지 보여줍니다.


****  

| 경로 패턴 | 경로 패턴과 일치하는 파일 | 
| --- | --- | 
|  `*.jpg`  |  모든 .jpg 파일  | 
|  `images/*.jpg`  |  `images` 디렉터리와 `images` 디렉터리의 하위 디렉터리에 있는 모든 .jpg 파일  | 
|  `a*.jpg`  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/DownloadDistValuesCacheBehavior.html)  | 
|  `a??.jpg`  |  `a`로 시작하여 나머지는 정확히 두 문자가 오는 파일 이름을 지닌 모든 .jpg 파일(예: `ant.jpg`, `abe.jpg`)  | 
|  `*.doc*`  |  파일 이름 확장명이 `.doc`로 시작하는 모든 .jpg 파일(예: `.doc`, `.docx`, `.docm` 파일). 이 경우, `*.doc?` 경로 패턴을 사용할 수 없습니다. 이 경로 패턴은 `.doc` 파일에 대한 요청에 적용할 수 없기 때문입니다. `?` 와일드카드 문자는 정확히 한 문자를 대체합니다.  | 

경로 패턴의 최대 길이는 255자입니다. 이 값에는 다음 문자 중 어느 것이든 포함할 수 있습니다.
+ A\$1Z, a\$1z

  경로 패턴은 대소문자를 구분하므로 경로 패턴 `*.jpg`는 `LOGO.JPG` 파일에 적용되지 않습니다.
+ 0\$19
+ \$1 - . \$1 \$1 / \$1 " ' @ : \$1
+ &, `&amp;`로 처리되고 반환됨

### 경로 정규화
<a name="path-normalization"></a>

CloudFront는 [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6)과 일치하는 URI 경로를 정규화한 다음 경로를 올바른 캐시 동작과 일치시킵니다. 캐시 동작이 일치하면 CloudFront는 원본 URI 경로를 오리진에 보냅니다. 일치하지 않으면 요청이 기본 캐시 동작과 일치하도록 선택할 수 있습니다.

다중 슬래시 (`//`) 또는 마침표 (`..`) 와 같은 일부 문자는 정규화되어 경로에서 제거됩니다. 이렇게 하면 CloudFront가 의도한 캐시 동작과 일치시키기 위해 사용하는 URL을 변경할 수 있습니다.

**Example 예제**  
캐시 동작의 `/a/b*` 및 `/a*` 경로를 지정합니다.  
+ `/a/b?c=1` 경로를 보내는 뷰어는 `/a/b*` 캐시 동작과 일치할 것입니다.
+ `/a/b/..?c=1` 경로를 보내는 뷰어는 `/a*` 캐시 동작과 일치합니다.

경로가 정규화되는 문제를 해결하려면 요청 경로나 캐시 동작의 경로 패턴을 업데이트하면 됩니다.

## 오리진 또는 오리진 그룹
<a name="DownloadDistValuesTargetOriginId"></a>

이 설정은 기존 배포에 대한 캐시 동작을 생성하거나 업데이트하는 경우에만 적용됩니다.

기존 오리진 또는 오리진 그룹의 값을 입력합니다. 이를 통해 요청(예: https://example.com/logo.jpg)이 캐시 동작의 경로 패턴(예: \$1.jpg)이나 기본 캐시 동작의 경로 패턴(\$1)과 일치할 때 CloudFront에서 요청을 라우팅하려는 오리진 또는 오리진 그룹을 식별합니다.

## 뷰어 프로토콜 정책
<a name="DownloadDistValuesViewerProtocolPolicy"></a>

최종 사용자가 CloudFront 엣지 로케이션의 콘텐츠를 액세스하는 데 사용하게 하려는 프로토콜 정책을 선택합니다.
+ **HTTP 및 HTTPS**: 최종 사용자는 두 프로토콜 모두를 사용할 수 있습니다.
+ **Redirect HTTP to HTTPS**(HTTP를 HTTPS로 재지정): 최종 사용자는 두 프로토콜 모두 사용할 수 있지만, HTTP 요청은 자동으로 HTTPS 요청으로 리디렉션됩니다.
+ **HTTPS Only**(HTTPS만 해당): 최종 사용자는 HTTPS를 사용하는 경우에만 콘텐츠에 액세스할 수 있습니다.

자세한 내용은 [뷰어와 CloudFront 간의 통신에 HTTPS 요구](using-https-viewers-to-cloudfront.md) 단원을 참조합니다.

## 허용되는 HTTP 메서드
<a name="DownloadDistValuesAllowedHTTPMethods"></a>

CloudFront에서 오리진을 처리하고 전달하기 위한 HTTP 메서드를 지정합니다.
+ **GET, HEAD:** 오리진에서 객체를 가져오거나 객체 헤더를 가져오기 위해서만 CloudFront를 사용할 수 있습니다.
+ **GET, HEAD, OPTIONS:** 오리진에서 객체를 가져오거나 객체 헤더를 가져오기 위해, 또는 오리진 서버에서 지원되는 옵션 목록을 가져오기 위해서만 CloudFront를 사용할 수 있습니다.
+ **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE:** CloudFront를 사용하여 객체를 추가, 업데이트, 삭제하고 가져올 수 있으며 객체 헤더를 가져올 수 있습니다. 또한 웹 양식에서 데이터를 제출하는 등의 기타 POST 작업을 수행할 수 있습니다.
**참고**  
워크로드에서 gRPC를 사용하는 경우 **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE**를 선택해야 합니다. gRPC 워크로드에는 `POST` 메서드가 필요합니다. 자세한 내용은 [CloudFront 배포에 gRPC 사용](distribution-using-grpc.md) 섹션을 참조하세요.  
CloudFront에서는 `GET` 및 `HEAD` 요청과 선택적으로 `OPTIONS` 요청에 대한 응답을 캐싱합니다. `OPTIONS` 요청에 대한 응답은 `GET` 및 `HEAD` 요청에 대한 응답과 별도로 캐시됩니다(`OPTIONS` 메서드는 `OPTIONS` 요청에 대한 [캐시 키](understanding-the-cache-key.md)에 포함됨). CloudFront에서는 다른 메서드를 사용하는 요청에 대한 응답을 캐시하지 않습니다.

**중요**  
**GET, HEAD, OPTIONS** 또는 **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE**를 선택하는 경우 사용자가 수행하길 원치 않는 작업을 수행하지 못하도록 Amazon S3 버킷 또는 사용자 지정 오리진에 대한 액세스를 제한해야 할 수 있습니다. 다음 예에서는 액세스를 제한하는 방법을 설명합니다.  
**배포에 대한 오리진으로 Amazon S3를 사용하려는 경우:** CloudFront 오리진 액세스 제어를 만들어 Amazon S3 콘텐츠에 대한 액세스를 제한하고 이 오리진 액세스 제어에 적절한 사용 권한을 부여해야 합니다. 예를 들어, `PUT`을 사용할 의도로 이러한 메서드*만* 허용 및 전달하도록 CloudFront를 구성한 경우, `DELETE` 요청을 적절히 처리하도록 Amazon S3 버킷 정책을 구성해야 합니다. 자세한 내용은 [Amazon S3 오리진에 대한 액세스 제한](private-content-restricting-access-to-s3.md) 단원을 참조합니다.
**사용자 지정 오리진을 사용하는 경우:** 모든 메서드를 처리하도록 오리진 서버를 구성합니다. 예를 들어, `POST`를 사용할 의도로 이러한 메서드만** 허용 및 전달하도록 CloudFront를 구성한 경우, `DELETE` 요청을 적절히 처리하도록 오리진 서버를 구성해야 합니다.

## 필드 레벨 암호화 구성
<a name="DownloadDistValuesFieldLevelEncryption"></a>

특정 데이터 필드에 필드 레벨 암호화를 적용하고자 하는 경우 드롭다운 목록에서 필드 레벨 암호화 구성을 선택합니다.

자세한 내용은 [필드 수준 암호화를 사용하여 민감한 데이터 보호](field-level-encryption.md) 섹션을 참조하세요.

## 캐싱된 HTTP 메서드
<a name="DownloadDistValuesCachedHTTPMethods"></a>

최종 사용자가 `OPTIONS` 요청을 제출할 때 CloudFront에서 오리진의 응답을 캐싱할지 여부를 지정합니다. CloudFront에서는 `GET` 및 `HEAD` 요청에 대한 응답을 항상 캐싱합니다.

## HTTP/2를 통한 gRPC 요청 허용
<a name="enable-grpc-distribution"></a>

배포에서 gRPC 요청을 허용할지 여부를 지정합니다. gRPC를 사용하려면 다음 설정을 선택합니다.
+ **[허용된 HTTP 메서드](#DownloadDistValuesAllowedHTTPMethods)**에서 **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE** 메서드를 선택합니다. gRPC에는 `POST` 메서드가 필요합니다.
+ `POST` 메서드를 선택한 후 나타나는 gRPC 확인란을 선택합니다.
+ **[지원되는 HTTP 버전](DownloadDistValuesGeneral.md#DownloadDistValuesSupportedHTTPVersions)**에서 **HTTP/2**를 선택합니다.

자세한 내용은 [CloudFront 배포에 gRPC 사용](distribution-using-grpc.md) 섹션을 참조하세요.

## 선택한 요청 헤더 기반의 캐시
<a name="DownloadDistValuesForwardHeaders"></a>

CloudFront에서 지정된 헤더의 값을 기반으로 객체를 캐싱할지 여부를 지정합니다.
+ **없음(캐싱 향상)(None (improves caching))** - CloudFront가 헤더 값을 기반으로 객체를 캐싱하지 않습니다.
+ **허용 목록** - CloudFront가 지정된 헤더의 값만을 기반으로 객체를 캐싱합니다. **허용 목록 헤더**를 사용하여 CloudFront에서 캐싱의 기준으로 설정할 헤더를 선택합니다.
+ **모두(All)** - CloudFront가 이 캐시 동작과 연결된 객체를 캐싱하지 않습니다. 대신 CloudFront는 각 요청을 오리진에 전송합니다. (Amazon S3 오리진에는 권장하지 않음)

어떤 옵션을 선택하든 상관없이, CloudFront는 오리진에 특정 헤더를 전달하고 전달한 헤더에 따라 작업을 수행합니다. CloudFront가 헤더 전달을 처리하는 방법에 대한 자세한 내용은 [HTTP 요청 헤더 및 CloudFront 동작(사용자 지정 및 Amazon S3 오리진)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior) 단원을 참조하세요.

요청 헤더를 사용하여 CloudFront에서 캐싱을 구성하는 방법에 대한 자세한 내용은 [요청 헤더 기반의 콘텐츠 캐싱](header-caching.md) 단원을 참조하세요.

## 허용 목록 헤더
<a name="DownloadDistValuesAllowlistHeaders"></a>

이 설정은 **선택한 요청 헤더 기반의 캐시**에 대해 **허용 목록**을 선택한 경우에만 적용됩니다.

객체를 캐싱할 때 CloudFront에서 고려할 헤더를 지정합니다. 사용 가능한 헤더 목록에서 헤더를 선택하고 **추가**를 선택합니다. 사용자 지정 헤더를 전달하려면 필드에 헤더 이름을 입력하고 **Add Custom**(사용자 지정 항목 추가)을 선택합니다.

현재 각 캐시 동작에 대해 허용 목록을 작성할 수 있는 헤더의 최대 수를 살펴보고 더 높은 할당량(이전에는 제한이라고 함)을 요청하려면, [헤더에 대한 할당량](cloudfront-limits.md#limits-custom-headers) 단원을 참조하세요.

## 객체 캐싱
<a name="DownloadDistValuesObjectCaching"></a>

오리진 서버에서 객체에 `Cache-Control` 헤더를 추가하여 CloudFront 캐시에 객체가 머무르는 시간을 제어하는 경우와, `Cache-Control` 값을 변경하지 않으려는 경우 **오리진 캐시 헤더 사용(Use Origin Cache Headers)**을 선택합니다.

`Cache-Control` 헤더와 관계없이 CloudFront 캐시에 객체가 머무르는 최소 및 최대 시간과 객체에서 `Cache-Control` 헤더가 누락된 경우 CloudFront 캐시에 객체가 머무르는 기본 시간을 지정하려면 **사용자 지정(Customize)**을 선택합니다. 그런 다음 **최소 TTL**, **기본 TTL** 및 **최대 TTL** 필드에서 값을 지정합니다.

자세한 내용은 [콘텐츠가 캐시에 유지되는 기간(만료) 관리](Expiration.md) 단원을 참조합니다.

## Minimum TTL
<a name="DownloadDistValuesMinTTL"></a>

객체가 업데이트되었는지 여부를 확인하기 위해 CloudFront에서 오리진으로 다른 요청을 전송하기 전에 객체를 CloudFront 캐시에 유지할 최소 시간(초)을 지정합니다.

**주의**  
최소 TTL이 0보다 큰 경우 오리진 헤더에 `Cache-Control: no-cache`, `no-store` 또는 `private` 지시문이 있더라도 CloudFront는 적어도 캐시 정책의 최소 TTL에 지정된 기간 동안 콘텐츠를 캐싱합니다.

자세한 내용은 [콘텐츠가 캐시에 유지되는 기간(만료) 관리](Expiration.md) 섹션을 참조하세요.

## Maximum TTL
<a name="DownloadDistValuesMaxTTL"></a>

객체가 업데이트되었는지 여부를 확인하도록 CloudFront에서 오리진에 쿼리하기 전에 CloudFront 캐시에서 객체를 머무르게 하려는 최대 시간을 초 단위로 지정합니다. **최대 TTL**에 지정하는 값은 오리진이 객체에 `Cache-Control max-age`, `Cache-Control s-maxage` 또는 `Expires` 등의 HTTP 헤더를 추가할 경우에만 적용됩니다. 자세한 내용은 [콘텐츠가 캐시에 유지되는 기간(만료) 관리](Expiration.md) 단원을 참조합니다.

**최대 TTL**의 값을 지정하려면 **Object Caching**(객체 캐싱) 설정의 **Customize**(사용자 지정) 옵션을 선택해야 합니다.

**최대 TTL**의 기본값은 31536000초(1년)입니다. **최소 TTL** 또는 **기본 TTL**의 값을 31536000초 이상으로 변경할 경우 **최대 TTL**의 기본값은 **기본 TTL**의 값으로 변경됩니다.

## 기본 TTL
<a name="DownloadDistValuesDefaultTTL"></a>

객체가 업데이트되었는지 여부를 결정하도록 CloudFront가 오리진에 다른 요청을 전달하기 전에 객체를 CloudFront 캐시에 유지하려는 기본 시간을 초 단위로 지정합니다. **기본 TTL**에 지정하는 값은 오리진이 객체에 `Cache-Control max-age`, `Cache-Control s-maxage`, `Expires` 등의 HTTP 헤더를 추가하지 *않는* 경우에만 적용됩니다. 자세한 내용은 [콘텐츠가 캐시에 유지되는 기간(만료) 관리](Expiration.md) 단원을 참조합니다.

**기본 TTL**에 값을 지정하려면 **Object Caching**(객체 캐싱) 설정에 대해 **Customize**(사용자 지정) 옵션을 선택해야 합니다.

**기본 TTL**의 기본값은 86400초(1일)입니다. **Minimum TTL(최소 TTL)**의 값을 86,400초 이상으로 변경할 경우 **Default TTL(기본 TTL)**의 기본값은 **Minimum TTL(최소 TTL)**의 값으로 변경됩니다.

## 쿠키 전달
<a name="DownloadDistValuesForwardCookies"></a>

**참고**  
Amazon S3 오리진의 경우 이 옵션은 웹 사이트 엔드포인트로 구성된 버킷에만 적용됩니다.

CloudFront에서 쿠키를 오리진 서버로 전달할지 여부와 전달할 쿠키(전달하는 경우)를 지정합니다. 선택한 쿠키(쿠키의 허용 목록)만 전달하도록 선택한 경우, 쿠키 이름을 **허용 목록 쿠키** 필드에 입력합니다. **모두(All)**를 선택하는 경우 CloudFront에서는 애플리케이션에서 사용하는 쿠키 수와 관계없이 모든 쿠키를 전달합니다.

Amazon S3에서는 쿠키를 처리하지 않으며 오리진에 쿠키를 전달함으로써 캐싱 가능성이 줄어듭니다. Amazon S3 오리진에 요청을 전달하는 캐시 동작의 경우 **쿠키 전달(Forward Cookies)**에 대해 **없음(None)**을 선택합니다.

오리진으로 쿠키를 전달하는 것에 대한 자세한 내용은 [쿠키 기반의 콘텐츠 캐싱](Cookies.md) 단원을 참조합니다.

## 허용 목록 쿠키
<a name="DownloadDistValuesAllowlistCookies"></a>

**참고**  
Amazon S3 오리진의 경우 이 옵션은 웹 사이트 엔드포인트로 구성된 버킷에만 적용됩니다.

**쿠키 전달** 목록의 **허용 목록**을 선택하는 경우, **허용 목록 쿠키** 필드에 이 캐시 동작에 대해 CloudFront에서 오리진 서버에 전달하려는 쿠키 이름을 입력합니다. 각 쿠키 이름을 새 줄에 입력합니다.

다음 와일드카드를 지정하여 쿠키 이름을 지정할 수 있습니다.
+ **\$1**는 쿠키 이름의 0개 이상의 문자에 해당합니다.
+ **?**는 쿠키 이름의 정확히 1문자에 해당합니다.

예를 들어, 다음과 같은 쿠키 이름이 포함된 객체에 대한 최종 사용자 요청을 가정합니다.

`userid_member-number`

각각의 사용자는 *member-number*에 대한 고유한 값을 갖습니다. 이 경우에는 CloudFront에서 각 멤버별로 개별 버전의 객체를 캐싱하려 합니다. 모든 쿠키를 오리진에 전달함으로써 이를 달성할 수는 있지만, 최종 사용자 요청에 CloudFront에서 캐싱하길 원치 않는 쿠키가 일부 포함됩니다. 또는, 다음 값을 쿠키 이름으로 지정할 수 있습니다. 이렇게 하면 CloudFront에서 해당 오리진에 `userid_`로 시작하는 모든 쿠키를 전달합니다.

`userid_*`

현재 각 캐시 동작에 대해 허용 목록을 작성할 수 있는 쿠키 이름의 최대 수를 살펴보고 더 높은 할당량(이전에는 제한이라고 함)을 요청하려면, [쿠키에 대한 할당량(레거시 캐시 설정)](cloudfront-limits.md#limits-allowlisted-cookies) 단원을 참조하세요.

## 쿼리 문자열 전달 및 캐싱
<a name="DownloadDistValuesQueryString"></a>

CloudFront는 쿼리 문자열 파라미터 값을 기준으로 콘텐츠의 다른 버전을 캐싱할 수 있습니다. 다음 옵션 중 하나를 선택합니다.

**None (Improves Caching)**  
오리진에서 쿼리 문자열 파라미터 값과 상관 없이 객체의 동일한 버전을 반환하는 경우 이 옵션을 선택합니다. 이렇게 하면 CloudFront에서 캐시로부터 요청을 제공할 수 있는 가능성이 높아지고, 그에 따라 성능이 향상되며 오리진에 걸리는 부하가 줄어듭니다.

**모두 전달, 허용 목록 기반으로 캐싱**  
오리진 서버에서 하나 이상의 쿼리 문자열 파라미터를 기준으로 다른 버전의 객체를 반환할 경우 이 옵션을 선택합니다. 그런 다음 [쿼리 문자열 허용 목록](#DownloadDistValuesQueryStringAllowlist) 필드에서 CloudFront가 이 캐싱의 기준으로 사용하도록 하려는 파라미터를 지정합니다.

**Forward all, cache based on all**  
오리진 서버에서 모든 쿼리 문자열 파라미터를 기준으로 다른 버전의 객체를 반환할 경우 이 옵션을 선택합니다.

성능 향상을 포함하여 쿼리 문자열 파라미터를 기준으로 하는 캐싱에 대한 자세한 내용은 [쿼리 문자열 파라미터 기반의 콘텐츠 캐싱](QueryStringParameters.md) 단원을 참조하십시오.

## 쿼리 문자열 허용 목록
<a name="DownloadDistValuesQueryStringAllowlist"></a>

이 설정은 [쿼리 문자열 전달 및 캐싱](#DownloadDistValuesQueryString)에 **모두 전달, 허용 목록 기반으로 캐싱**을 선택한 경우에만 적용됩니다. CloudFront가 캐싱 기반으로 사용할 쿼리 문자열 파라미터를 지정할 수 있습니다.

## Smooth Streaming
<a name="DownloadDistValuesSmoothStreaming"></a>

Microsoft Smooth Streaming 포맷의 미디어 파일을 배포하려는데 IIS 서버가 없으면 **예**를 선택합니다.

Microsoft Smooth Streaming 포맷의 미디어 파일을 배포하기 위한 오리진으로 사용하려는 Microsoft IIS 서버가 있거나, Smooth Streaming 미디어 파일을 배포하지 않으려는 경우 **아니요**를 선택합니다.

**참고**  
**예**를 지정한 경우에도 콘텐츠가 **경로 패턴** 값과 일치하는 경우 이 캐시 동작을 사용하여 다른 콘텐츠를 배포할 수 있습니다.

자세한 내용은 [Microsoft Smooth Streaming용 온디맨드 비디오 구성](on-demand-video.md#on-demand-streaming-smooth) 단원을 참조합니다.

## 최종 사용자 액세스 제한(서명된 URL 또는 서명된 쿠키 사용)
<a name="DownloadDistValuesRestrictViewerAccess"></a>

이 캐시 동작의 `PathPattern`과 일치하는 객체에 대한 요청에 퍼블릭 URL을 사용하려는 경우 **아니요**를 선택합니다.

이 캐시 동작의 `PathPattern`과 일치하는 객체에 대한 요청에 서명된 URL을 사용하려는 경우 **예**를 선택합니다. 그런 다음, 서명된 URL 생성에 사용하려는 AWS 계정을 지정합니다. 이러한 계정은 신뢰할 수 있는 서명자라고도 합니다.

신뢰할 수 있는 서명자에 대한 자세한 내용은 [서명된 URL 및 서명된 쿠키를 생성할 수 있는 서명자 지정](private-content-trusted-signers.md) 단원을 참조합니다.

## 신뢰할 수 있는 서명자
<a name="DownloadDistValuesTrustedSigners"></a>

이 설정은 **최종 사용자 액세스 제한(서명된 URL 또는 서명된 쿠키 사용)**에 대해 **예**를 선택한 경우에만 적용됩니다.

이 캐시 동작에 대해 신뢰할 수 있는 서명자로 사용하려는 AWS 계정을 선택합니다.
+ **셀프**: 현재 AWS Management Console에 신뢰할 수 있는 서명자로 로그인된 계정을 사용합니다. 현재 IAM 사용자로 로그인되어 있는 경우, 연결된 AWS 계정이 신뢰할 수 있는 서명자로 추가됩니다.
+ **계정 지정(Specify Accounts):** 신뢰할 수 있는 서명자에 대한 계정 번호를 [**AWS 계정 번호(Account Numbers)**] 필드에 입력합니다.

서명된 URL을 생성하려면 AWS 계정에 하나 이상의 활성 CloudFront 키 페어가 있어야 합니다.

**중요**  
콘텐츠 배포에 이미 사용 중인 배포를 업데이트하려는 경우, 서명된 URL 생성을 시작할 준비가 되었을 때만 신뢰할 수 있는 서명자를 추가합니다. 배포에 신뢰할 수 있는 서명자를 추가한 후에, 사용자는 서명된 URL을 사용하여 이 캐시 동작의 `PathPattern`과 일치하는 객체에 액세스해야 합니다.

## AWS 계정 번호
<a name="DownloadDistValuesAWSAccountNumbers"></a>

이 설정은 **신뢰할 수 있는 서명자**에 대해 **계정 지정**을 선택한 경우에만 적용됩니다.

현재 계정에 추가로 또는 현재 계정 대신에 AWS 계정을 사용하여 서명된 URL을 생성하려는 경우, 이 필드에 한 줄당 AWS 계정 번호 하나씩을 입력합니다. 다음 사항에 유의하세요.
+ 지정하는 계정에는 하나 이상의 활성 CloudFront 키 페어가 있어야 합니다. 자세한 내용은 [서명자에 대해 키 페어 생성](private-content-trusted-signers.md#private-content-creating-cloudfront-key-pairs) 단원을 참조합니다.
+ IAM 사용자에 대해 CloudFront 키 페어를 생성할 수 없으므로 IAM 사용자는 신뢰할 수 있는 서명자로 사용할 수 없습니다.
+ 계정의 AWS 계정 번호를 가져오는 방법에 대한 자세한 내용은 **AWS 계정 Management 참조 안내서의 [AWS 계정 식별자 보기](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html)를 참조하세요.
+ 현재 계정에 대한 계정 번호를 입력하면 CloudFront에서는 **셀프** 확인란을 자동으로 선택하고 **AWS 계정 번호** 목록에서 계정 번호를 삭제합니다.

## 자동으로 객체를 압축
<a name="DownloadDistValuesCompressObjectsAutomatically"></a>

최종 사용자가 압축된 콘텐츠를 지원하는 경우 CloudFront가 특정 유형의 파일을 자동 압축하도록 하려면 **예(Yes)**를 선택합니다. CloudFront가 콘텐츠를 압축하면 파일 크기가 더 작아지므로 다운로드 속도가 빨라지고 웹 페이지는 사용자에게 더 빨리 렌더링됩니다. 자세한 내용은 [압축된 파일 제공](ServingCompressedFiles.md) 단원을 참조합니다.

## CloudFront 이벤트
<a name="DownloadDistValuesEventType"></a>

이 설정은 **Lambda 함수 연결**에 적용됩니다.

다음 CloudFront 이벤트가 하나 이상 발생할 때 Lambda 함수를 실행하도록 선택할 수 있습니다.
+ CloudFront가 최종 사용자의 요청을 수신할 때(최종 사용자 요청)
+ CloudFront가 오리진에 요청을 전달하기 전(오리진 요청)
+ CloudFront가 오리진의 응답을 수신할 때(오리진 응답)
+ CloudFront가 최종 사용자에게 응답을 반환하기 전(최종 사용자 응답)

자세한 내용은 [함수를 트리거할 이벤트를 선택합니다.](lambda-how-to-choose-event.md) 단원을 참조합니다.

## Lambda 함수 ARN
<a name="DownloadDistValuesLambdaFunctionARN"></a>

이 설정은 **Lambda 함수 연결**에 적용됩니다.

트리거를 추가할 Lambda 함수의 Amazon 리소스 이름(ARN)을 지정합니다. 함수의 ARN을 가져오는 방법에 대한 자세한 내용은 [CloudFront 콘솔을 사용한 트리거 추가](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-add-triggers.html#lambda-edge-add-triggers-cf-console) 절차의 1단계를 참조하세요.

## 본문 포함
<a name="include-body"></a>

이 설정은 **Lambda 함수 연결**에 적용됩니다.

자세한 내용은 [본문 포함](lambda-generating-http-responses.md#lambda-include-body-access)을 참조하세요.

# 배포 설정
<a name="DownloadDistValuesGeneral"></a>

다음 값들이 전체 배포에 적용됩니다.

**Topics**
+ [요금 계층](#DownloadDistValuesPriceClass)
+ [AWS WAF 웹 ACL](#DownloadDistValuesWAFWebACL)
+ [대체 도메인 이름(CNAME)](#DownloadDistValuesCNAME)
+ [SSL 인증서](#DownloadDistValuesSSLCertificate)
+ [사용자 지정 SSL 클라이언트 지원](#DownloadDistValuesClientsSupported)
+ [보안 정책(최소 SSL/TLS 버전)](#DownloadDistValues-security-policy)
+ [지원되는 HTTP 버전](#DownloadDistValuesSupportedHTTPVersions)
+ [기본 루트 객체](#DownloadDistValuesDefaultRootObject)
+ [표준 로깅](#DownloadDistValuesLoggingOnOff)
+ [연결 로그](#DownloadDistValuesConnectionLogs)
+ [로그 접두사](#DownloadDistValuesLogPrefix)
+ [쿠키 로깅](#DownloadDistValuesCookieLogging)
+ [IPv6 활성화(뷰어 요청)](#DownloadDistValuesEnableIPv6)
+ [상호 인증](#DownloadDistValuesMutualAuthentication)
+ [사용자 지정 오리진에 IPv6 활성화(오리진 요청)](#DownloadDistValuesEnableIPv6-origin)
+ [설명](#DownloadDistValuesComment)
+ [배포 상태](#DownloadDistValuesEnabled)

## 요금 계층
<a name="DownloadDistValuesPriceClass"></a>

CloudFront 서비스를 위해 지급하려는 최고가에 해당하는 요금 계층을 선택합니다. 기본적으로 CloudFront는 모든 CloudFront 리전의 엣지 로케이션에서 객체를 제공합니다.

가격 등급과 가격 등급 선택이 배포를 위한 CloudFront 성능에 미치는 영향에 대한 자세한 내용은 [CloudFront 요금제](https://aws.amazon.com/cloudfront/pricing/)를 참조합니다.

## AWS WAF 웹 ACL
<a name="DownloadDistValuesWAFWebACL"></a>

웹 애플리케이션 및 API를 보호하여 요청이 서버에 도달하기 전에 요청을 차단할 수 있는 웹 애플리케이션 방화벽인 [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf)를 사용하여 CloudFront 배포를 보호할 수 있습니다. CloudFront 배포를 생성하거나 편집할 때 [배포에 AWS WAF 활성화](WAF-one-click.md)할 수 있습니다.

선택적으로 나중에 AWS WAF 콘솔([https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/))에서 애플리케이션과 관련된 다른 위협에 대한 추가 보안 보호를 구성할 수 있습니다.

AWS WAF에 대한 자세한 내용은 [AWS WAF개발자 안내서](https://docs.aws.amazon.com/waf/latest/developerguide/) 단원을 참조하십시오.

## 대체 도메인 이름(CNAME)
<a name="DownloadDistValuesCNAME"></a>

선택. 사용자가 배포를 만들 때 CloudFront에서 할당하는 도메인 이름 대신 객체의 URL에 사용할 하나 이상의 도메인 이름을 지정합니다. 도메인 이름을 소유하거나, 도메인 이름을 사용할 권한이 있어야 합니다. 사용 권한은 SSL/TLS 인증서를 추가하여 확인합니다.

 예를 들어 객체의 URL이 아래와 같은 경우

`/images/image.jpg`

아래와 같이 변경하고

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

아래와 같이 변경하지 않으려면

`https://d111111abcdef8.cloudfront.net/images/image.jpg`

`www.example.com`에 대한 CNAME을 추가합니다.

**중요**  
배포에 `www.example.com`에 대한 CNAME을 추가하는 경우, 다음도 수행해야 합니다.  
DNS 서비스로 CNAME 레코드를 만들거나 업데이트해 `www.example.com`에 대한 쿼리를 `d111111abcdef8.cloudfront.net`로 라우팅합니다.
배포에 추가하는 도메인 이름(CNAME)이 포함된 신뢰할 수 있는 인증 기관(CA)의 인증서를 CloudFront에 추가하여 도메인 이름을 사용할 권한을 검증합니다.
도메인에 대한 DNS 서비스 공급자를 통해 CNAME 레코드를 만들려면 권한이 있어야 합니다. 일반적으로 이 경우 도메인을 소유하고 있거나, 도메인 소유자를 위해 애플리케이션을 개발하는 중일 수도 있습니다.

현재 하나의 배포에 추가할 수 있는 대체 도메인 이름의 최대 수를 살펴보고 더 높은 할당량(이전에는 제한이라고 함)을 요청하려면, [배포의 일반 할당량](cloudfront-limits.md#limits-web-distributions) 단원을 참조하세요.

대체 도메인 이름에 대한 자세한 내용은 [대체 도메인 이름(CNAME)을 추가하여 사용자 지정 URL 사용](CNAMEs.md) 단원을 참조하십시오. CloudFront URL에 대한 자세한 내용은 [CloudFront에서 파일에 대한 URL 형식 사용자 지정](LinkFormat.md) 단원을 참조하세요.

## SSL 인증서
<a name="DownloadDistValuesSSLCertificate"></a>

배포에 사용할 대체 도메인 이름을 지정한 경우, **Custom SSL Certificate(사용자 지정 SSL 인증서)**를 선택한 후 대체 도메인 이름을 사용할 권한을 검증하고, 대체 도메인 이름이 포함된 인증서를 선택합니다. 최종 사용자가 HTTPS를 사용하여 객체에 액세스하게 하려는 경우, 이를 지원하는 설정을 선택합니다.
+ **기본 CloudFront 인증서(\$1.cloudfront.net)(Default CloudFront Certificate (\$1.cloudfront.net))** - CloudFront 도메인 이름을 객체(예: `https://d111111abcdef8.cloudfront.net/image1.jpg`)의 URL에 사용하려는 경우, 이 옵션을 선택합니다.
+ **사용자 정의 SSL 인증서(Custom SSL Certificate)** - 자체 도메인 이름을 객체의 URL에 대체 도메인 이름(예: `https://example.com/image1.jpg`)으로 사용하려는 경우, 이 옵션을 선택합니다. 그런 다음 대체 도메인 이름이 포함된 사용할 인증서를 선택합니다. 인증서 목록에는 다음이 포함될 수 있습니다.
  + 에서 제공하는 인증서AWS Certificate Manager
  + 서드 파티 인증 기관으로부터 구매했고 ACM에 업로드한 인증서
  + 서드 파티 인증 기관으로부터 구매했고 IAM 인증서 스토어에 업로드한 인증서

  이 설정을 선택한 경우 대체 도메인 이름만 객체 URL에 사용하는 것이 좋습니다(https://example.com/logo.jpg). CloudFront 배포 도메인 이름(https://d111111abcdef8.cloudfront.net/logo.jpg)을 사용하고 클라이언트가 SNI를 지원하지 않는 이전 최종 사용자를 사용하는 경우, 최종 사용자가 응답하는 방식은 **지원되는 클라이언트(Clients Supported)**에서 선택하는 값에 따라 달라집니다.
  + **모든 클라이언트(All Clients)**: CloudFront 도메인 이름이 SSL/TLS 인증서의 도메인 이름과 일치하지 않으므로 최종 사용자에게 경고가 표시됩니다.
  + **SNI(서버 이름 표시)를 지원하는 클라이언트만(Only Clients that Support Server Name Indication (SNI))**: CloudFront에서 객체를 반환하지 않고 해당 최종 사용자와의 연결을 끊습니다.

## 사용자 지정 SSL 클라이언트 지원
<a name="DownloadDistValuesClientsSupported"></a>

**SSL 인증서**에 대해 **사용자 정의 SSL 인증서(example.com)**를 선택한 경우에만 적용됩니다. 배포에 대해 하나 이상의 대체 도메인 이름과 사용자 정의 SSL 인증서를 지정한 경우 CloudFront에서 HTTPS 요청을 제공할 방법을 선택합니다.
+ **SNI(서버 이름 표시)를 지원하는 클라이언트 - (권장)** - 이 설정을 사용하면 거의 모든 최신 웹 브라우저와 클라이언트가 SNI를 지원하므로 배포에 연결할 수 있습니다. 그러나 일부 최종 사용자는 SNI를 지원하지 않는 이전 웹 브라우저나 클라이언트를 사용할 수 있으므로 배포에 연결할 수 없습니다.

  CloudFront API를 사용하여 이 설정을 적용하려면 `sni-only` 필드에서 `SSLSupportMethod`를 지정합니다. CloudFormation에서 필드의 이름은 `SslSupportMethod`입니다(다른 대소문자에 유의).
+ **레거시 클라이언트 지원** - 이 설정을 사용하면 SNI를 지원하지 않는 이전 웹 브라우저와 클라이언트가 배포에 연결할 수 있습니다. 그러나 이 설정에는 추가 월별 요금이 발생합니다. 정확한 가격을 보려면 [Amazon CloudFront 요금](https://aws.amazon.com/cloudfront/pricing/) 페이지로 이동하여 **전용 IP 사용자 정의 SSL**을 검색하세요.

  CloudFront API를 사용하여 이 설정을 적용하려면 `vip` 필드에서 `SSLSupportMethod`를 지정합니다. CloudFormation에서 필드의 이름은 `SslSupportMethod`입니다(다른 대소문자에 유의).

자세한 내용은 [CloudFront에서 HTTPS 요청을 제공하는 방식 선택](cnames-https-dedicated-ip-or-sni.md) 섹션을 참조하세요.

## 보안 정책(최소 SSL/TLS 버전)
<a name="DownloadDistValues-security-policy"></a>

CloudFront가 최종 사용자(클라이언트)와의 HTTPS 연결에 사용할 보안 정책을 지정합니다. 보안 정책은 다음 두 가지 설정을 결정합니다.
+ CloudFront가 최종 사용자와 통신하는 데 사용하는 최소 SSL/TLS 프로토콜.
+ CloudFront가 최종 사용자로 반환하는 콘텐츠를 암호화할 때 사용할 수 있는 암호입니다.

각 보안 정책에 포함되는 프로토콜과 암호를 포함해 보안 정책에 관한 자세한 내용은 [최종 사용자와 CloudFront 간에 지원되는 프로토콜 및 암호](secure-connections-supported-viewer-protocols-ciphers.md) 단원을 참조하세요.

사용 가능한 보안 정책은 **SSL 인증서** 및 **사용자 지정 SSL 클라이언트 지원**(CloudFront API의 `CloudFrontDefaultCertificate` 및 `SSLSupportMethod`라고도 함)에 지정한 값에 따라 다릅니다.
+ **SSL 인증서(SSL Certificate)**가 **기본 CloudFront 인증서(\$1.cloudfront.net)(Default CloudFront Certificate(\$1.cloudfront.net))**인 경우(`CloudFrontDefaultCertificate`가 API에서 `true`일 때) CloudFront가 보안 정책을 자동으로 TLSv1로 설정합니다.
+ **SSL 인증서**가 **사용자 정의 SSL 인증서(example.com)***이고* **사용자 지정 SSL 클라이언트 지원**이 **서버 이름 표시(SNI)를 지원하는 클라이언트(권장)**일 때(API에서 `CloudFrontDefaultCertificate`가 `false`*이고* `SSLSupportMethod`가 `sni-only`일 때) 다음 보안 정책 중에서 선택할 수 있습니다.
  + TLSv1.3\$12025
  + TLSv1.2\$12025
  + TLSv1.2\$12021
  + TLSv1.2\$12019
  + TLSv1.2\$12018
  + TLSv1.1\$12016
  + TLSv1\$12016
  + TLSv1
+ **SSL 인증서**가 **사용자 정의 SSL 인증서(example.com)***이고* **사용자 지정 SSL 클라이언트 지원**이 **레거시 클라이언트 지원**일 때(API에서 `CloudFrontDefaultCertificate`가 `false`*이고* `SSLSupportMethod`가 `vip`일 때) 다음 보안 정책 중에서 선택할 수 있습니다.
  + TLSv1
  + SSLv3

  이 구성에서는 TLSv1.3\$12025, TLSv1.2\$12025, TLSv1.2\$12021, TLSv1.2\$12019, TLSv1.2\$12018, TLSv1.1\$12016 및 TLSv1\$12016 보안 정책을 CloudFront 콘솔 또는 API에서 사용할 수 없습니다. 이러한 보안 정책 중 하나를 사용할 경우 다음과 같은 옵션이 있습니다.
  + 배포에 전용 IP 주소로 레거시 클라이언트 지원이 필요한지 여부를 평가합니다. 최종 사용자 측에서 [서버 이름 표시(SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication)를 지원하는 경우에는 배포의 **사용자 지정 SSL 클라이언트 지원** 설정을 **서버 이름 표시(SNI)를 지원하는 클라이언트**로 설정하는 것이 좋습니다(API에서는 `SSLSupportMethod`를 `sni-only`로 설정). 이를 통해 사용 가능한 TLS 보안 정책을 사용할 수 있으며 CloudFront 요금도 줄일 수 있습니다.
  + 레거시 클라이언트 지원을 전용 IP 주소로 유지해야 하는 경우에는 [AWS Support Center](https://console.aws.amazon.com/support/home)에서 사례를 생성하여 다른 TLS 보안 정책(TLSv1.3\$12025, TLSv1.2\$12025, TLSv1.2\$12021, TLSv1.2\$12019, TLSv1.2\$12018, TLSv1.1\$12016 또는 TLSv1\$12016) 중 하나를 요청할 수 있습니다.
**참고**  
AWS Support로 연락해 이러한 변경을 요청하기 전에 다음 사항을 고려합니다.  
이러한 보안 정책 중 하나(TLSv1.3\$12025, TLSv1.2\$12025, TLSv1.2\$12021, TLSv1.2\$12019, TLSv1.2\$12018, TLSv1.1\$12016 또는 TLSv1\$12016)를 레거시 클라이언트 지원 배포에 추가하면 AWS 계정의 *모든* 레거시 클라이언트 지원 배포에 대한 SNI 이외의 *모든* 뷰어 요청에 보안 정책이 적용됩니다. 그러나 최종 사용자가 레거시 클라이언트 지원을 사용하여 배포에 SNI 요청을 보낼 경우 해당 배포의 보안 정책이 적용됩니다. 원하는 보안 정책이 AWS 계정의 *모든* 레거시 클라이언트 지원 배포에 전송된 *모든* 뷰어 요청에 적용되도록 하려면 원하는 보안 정책을 각 배포에 개별적으로 추가합니다.
당연히 새 보안 정책에서는 이전 보안 정책과 동일한 암호 및 프로토콜을 지원하지 않습니다. 예를 들어, 배포의 보안 정책을 TLSv1에서 TLSv1.1\$12016으로 업그레이드하도록 선택한 경우 해당 배포는 DES-CBC3-SHA 암호를 더 이상 지원하지 않습니다. 각 보안 정책이 지원하는 암호 및 프로토콜에 대한 자세한 내용은 [최종 사용자와 CloudFront 간에 지원되는 프로토콜 및 암호](secure-connections-supported-viewer-protocols-ciphers.md) 단원을 참조하세요.

## 지원되는 HTTP 버전
<a name="DownloadDistValuesSupportedHTTPVersions"></a>

최종 사용자가 CloudFront와 통신할 때 배포에서 지원할 HTTP 버전을 선택합니다.

뷰어와 CloudFront가 HTTP/2를 사용하는 경우 뷰어는 TLSv1.2 이상 및 SNI(Server Name Indication)를 지원해야 합니다.

뷰어와 CloudFront가 HTTP/3를 사용하는 경우 뷰어는 TLSv1.3 및 SNI(Server Name Indication)를 지원해야 합니다. CloudFront는 HTTP/3 연결 마이그레이션을 지원하므로 뷰어가 연결 손실 없이 네트워크를 전환할 수 있습니다. 연결 마이그레이션에 대한 자세한 내용은 RFC 9000의 [연결 마이그레이션](https://www.rfc-editor.org/rfc/rfc9000.html#name-connection-migration)을 참조하세요.

**참고**  
지원되는 TLSv1.3 암호에 대한 자세한 내용은 [최종 사용자와 CloudFront 간에 지원되는 프로토콜 및 암호](secure-connections-supported-viewer-protocols-ciphers.md) 섹션을 참조하세요.

**참고**  
Amazon Route 53을 사용하는 경우, 클라이언트가 지원한다면 HTTPS 레코드를 사용하여 DNS 조회의 일부로 프로토콜 협상을 허용할 수 있습니다. 자세한 내용은 [Create alias resource record set](CreatingCNAME.md#alternate-domain-https) 섹션을 참조하세요.

## 기본 루트 객체
<a name="DownloadDistValuesDefaultRootObject"></a>

선택. 최종 사용자가 배포의 객체(`index.html`)가 아닌 배포의 루트 URL(`https://www.example.com/`)을 요청할 때 CloudFront가 소스(예: `https://www.example.com/product-description.html`)으로부터 요청할 객체입니다. 기본 루트 객체를 지정하면 배포 콘텐츠가 노출되지 않습니다.

이름의 최대 길이는 255자입니다. 이름에는 다음 문자 중 어느 것이든 포함할 수 있습니다.
+ A\$1Z, a\$1z
+ 0\$19
+ \$1 - . \$1 \$1 / \$1 " '
+ &, `&amp;`로 처리되고 반환됨

기본 루트 객체를 지정하는 경우 객체 이름만 입력합니다(예: `index.html`). 객체 이름 앞에 `/`를 추가하지 마십시오.

자세한 내용은 [기본 루트 객체 지정](DefaultRootObject.md) 섹션을 참조하세요.

## 표준 로깅
<a name="DownloadDistValuesLoggingOnOff"></a>

CloudFront에서 객체에 대한 각 요청의 정보를 로그하고 이 로그 파일을 저장할지 지정합니다. 언제든지 로깅을 활성화 또는 비활성화할 수 있습니다. 로그를 사용해도 추가 비용이 들지 않지만 파일을 저장하고 이에 액세스하는 데 요금이 발생합니다. 로그는 언제든지 삭제할 수 있습니다.

CloudFront는 다음의 표준 로깅 옵션을 지원합니다.
+ [표준 로깅(v2)](standard-logging.md) - Amazon CloudWatch Logs, Amazon Data Firehose, Amazon Simple Storage Service(Amazon S3)를 포함한 전송 대상으로 로그를 전송할 수 있습니다.
+ [표준 로깅(레거시)](AccessLogs.md) - Amazon S3 버킷에만 로그를 보낼 수 있습니다.

## 연결 로그
<a name="DownloadDistValuesConnectionLogs"></a>

배포에 대한 [상호 인증](#DownloadDistValuesMutualAuthentication)을 켜면 CloudFront는 배포로 전송된 요청에 대한 속성을 캡처하는 연결 로그를 제공합니다. 연결 로그에는 클라이언트 IP 주소 및 포트, 클라이언트 인증서 정보, 연결 결과, 사용 중인 TLS 암호와 같은 정보가 포함됩니다. 이러한 연결 로그를 사용하여 요청 패턴 및 기타 추세를 검토할 수 있습니다.

연결 로그에 대한 자세한 내용은 [연결 로그를 사용한 관찰성](connection-logs.md) 섹션을 참조하세요.

## 로그 접두사
<a name="DownloadDistValuesLogPrefix"></a>

(선택 사항) 표준 로깅(레거시)을 사용하면 CloudFront에서 이 배포에 대한 액세스 로그 파일 이름에 접두사로 지정하려는 문자열(해당하는 경우)을 지정합니다(예: `exampleprefix/`). 후행 슬래시(/)는 선택 사항이지만 로그 파일을 쉽게 검색할 수 있도록 넣는 것이 좋습니다. 자세한 내용은 [표준 로깅(레거시) 구성](standard-logging-legacy-s3.md) 섹션을 참조하세요.

## 쿠키 로깅
<a name="DownloadDistValuesCookieLogging"></a>

CloudFront에서 쿠키를 액세스 로그에 포함하려는 경우 **설정(On)**을 선택합니다. 로그에 쿠키를 포함하도록 선택한 경우, CloudFront에서는 이 배포에 대한 캐시 동작을 어떻게 구성했는지(전체 쿠키 전달, 쿠키 전달 안 함 또는 오리진에 지정한 쿠키 목록 전달)와 관계없이 모든 쿠키를 로깅합니다.

Amazon S3에서는 쿠키를 처리하지 않습니다. 따라서 배포에 Amazon EC2 또는 다른 사용자 지정 오리진 역시 포함하지 않는 한 **쿠키 로깅(Cookie Logging)** 값으로 **해제(Off)**를 선택하는 것이 좋습니다.

쿠키에 대한 자세한 내용은 [쿠키 기반의 콘텐츠 캐싱](Cookies.md) 단원을 참조하십시오.

## IPv6 활성화(뷰어 요청)
<a name="DownloadDistValuesEnableIPv6"></a>

CloudFront가 IPv4 및 IPv6 IP 주소의 뷰어 요청에 응답하도록 하려면 **IPv6 활성화**를 선택합니다. 자세한 내용은 [CloudFront 배포에 IPv6 활성화](cloudfront-enable-ipv6.md) 섹션을 참조하세요.

## 상호 인증
<a name="DownloadDistValuesMutualAuthentication"></a>

선택 사항입니다. CloudFront 배포에 대해 상호 인증을 켜도록 선택할 수 있습니다. 자세한 내용은 [CloudFront에 대한 상호 TLS 인증(뷰어 mTLS)CloudFront에 대한 오리진 상호 TLS](mtls-authentication.md) 섹션을 참조하세요.

## 사용자 지정 오리진에 IPv6 활성화(오리진 요청)
<a name="DownloadDistValuesEnableIPv6-origin"></a>

사용자 지정 오리진(Amazon S3 및 VPC 오리진 제외)을 사용하는 경우 배포의 오리진 설정을 사용자 지정하여 CloudFront가 IPv4 또는 IPv6 주소를 사용하여 오리진에 연결하는 방법을 선택할 수 있습니다. 자세한 내용은 [CloudFront 배포에 IPv6 활성화](cloudfront-enable-ipv6.md) 섹션을 참조하세요.

## 설명
<a name="DownloadDistValuesComment"></a>

선택 사항입니다. 배포를 만들 때 최대 128자의 설명을 포함할 수 있습니다. 설명은 언제든지 업데이트할 수 있습니다.

## 배포 상태
<a name="DownloadDistValuesEnabled"></a>

배포가 완료되었을 때 활성화 또는 비활성화할지 여부를 나타냅니다.
+ *Enabled(활성화됨)*는 배포가 완료되는 대로 이 배포의 도메인 이름을 사용하는 링크를 배포할 수 있고 사용자가 콘텐츠를 가져올 수 있음을 의미합니다. 배포가 활성화되어 있으면 CloudFront에서는 해당 배포와 연결된 도메인 이름을 사용하는 콘텐츠에 대해 최종 사용자 요청을 수락하고 처리합니다.

  CloudFront 배포를 생성, 수정 또는 삭제할 경우 CloudFront 데이터베이스에 변경 사항이 전파되는 데에는 다소 시간이 소요됩니다. 배포 정보에 대한 즉각적인 요청에는 변경 사항이 반영되지 않을 수 있습니다. 전파는 대개 몇 분 내에 완료되지만, 이때 시스템에 과도한 로드가 걸리거나 네트워크 파티션이 증가할 수 있습니다.
+ *Disabled(비활성화됨)*는 배포가 완료되어 사용할 준비가 되더라도 사용자가 이를 사용할 수 없음을 의미합니다. 배포가 비활성화되어 있으면 CloudFront에서는 해당 배포와 연결된 도메인 이름을 사용하는 최종 사용자 요청을 수락하지 않습니다. 배포의 구성을 업데이트하여 비활성 상태에서 활성 상태로 전환할 때까지는 누구도 이 배포를 사용할 수 없습니다.

원하는 만큼 배포를 비활성 상태와 활성 상태 간에 전환할 수 있습니다. 배포 구성 업데이트에 대한 프로세스를 따르세요. 자세한 내용은 [배포 업데이트](HowToUpdateDistribution.md) 단원을 참조합니다.

# 사용자 지정 오류 페이지 및 오류 캐싱
<a name="DownloadDistValuesErrorPages"></a>

Amazon S3 또는 사용자 지정 오리진에서 HTTP 4xx 또는 5xx 상태 코드를 CloudFront에 반환할 때 CloudFront에서 최종 사용자에게 객체(예: HTML 파일)를 반환하도록 할 수 있습니다. 또한 CloudFront 엣지 캐시에서 오리진의 오류 응답 또는 사용자 지정 오류 페이지가 캐싱되는 시간을 지정할 수도 있습니다. 자세한 내용은 [특정 HTTP 상태 코드에 대한 사용자 지정 오류 페이지 생성](creating-custom-error-pages.md) 단원을 참조합니다.

**참고**  
다음 값은 Create Distribution 마법사에 포함되어 있지 않으므로 배포를 업데이트할 때만 사용자 지정 오류 페이지를 구성할 수 있습니다.

**Topics**
+ [HTTP 오류 코드](#DownloadDistValuesErrorCode)
+ [응답 페이지 경로](#DownloadDistValuesResponsePagePath)
+ [HTTP 응답 코드](#DownloadDistValuesResponseCode)
+ [오류 캐싱 최소 TTL(초)](#DownloadDistValuesErrorCachingMinTTL)

## HTTP 오류 코드
<a name="DownloadDistValuesErrorCode"></a>

CloudFront에서 사용자 지정 오류 페이지를 반환하려는 HTTP 상태 코드입니다. CloudFront에서 캐싱하는 HTTP 상태 코드의 일부 또는 전부에 대한(또는 상태 코드가 없는) 사용자 지정 오류 페이지를 반환하도록 CloudFront를 구성할 수 있습니다.

## 응답 페이지 경로
<a name="DownloadDistValuesResponsePagePath"></a>

403 등의 **오류 코드(Error Code)**로 지정한 HTTP 상태 코드가 오리진에서 반환될 때 CloudFront에서 최종 사용자에게 반환하는 사용자 지정 오류 페이지의 경로(예: `/4xx-errors/403-forbidden.html`)입니다. 객체와 사용자 지정 오류 페이지를 서로 다른 위치에 저장하려는 경우, 배포에는 다음을 충족하는 캐시 동작이 포함되어야 합니다.
+ **경로 패턴**의 값이 사용자 지정 오류 메시지와 일치합니다. `/4xx-errors`라는 이름의 디렉터리에 있는 Amazon S3 버킷에 4xx 오류에 대한 사용자 지정 오류 페이지를 저장한 경우를 예로 들어 보겠습니다. 배포에는 사용자 지정 오류 페이지에 대한 요청을 해당 위치로 라우팅하는 경로 패턴(예: **/4xx-errors/\$1**)의 캐시 동작이 포함되어야 합니다.
+ **Origin**(오리진)의 값은 사용자 지정 오류 페이지를 포함한 오리진에 대한 **Origin ID**(오리진 ID)의 값을 지정합니다.

## HTTP 응답 코드
<a name="DownloadDistValuesResponseCode"></a>

CloudFront에서 사용자 지정 오류 페이지와 함께 최종 사용자에게 반환하려는 HTTP 상태 코드입니다.

## 오류 캐싱 최소 TTL(초)
<a name="DownloadDistValuesErrorCachingMinTTL"></a>

CloudFront에서 오리진 서버로부터 오류 응답을 캐싱하려는 최소 시간입니다.

# 지리적 제한
<a name="DownloadDistValuesEnableGeoRestriction"></a>

선택한 국가의 사용자가 콘텐츠에 액세스하지 못하게 차단하려면 **허용 목록** 또는 **차단 목록**으로 CloudFront 배포를 구성할 수 있습니다. 지리적 제한을 구성하는 데 드는 추가 요금은 없습니다. 자세한 내용은 [콘텐츠의 지리적 배포 제한](georestrictions.md) 섹션을 참조하세요.

# 배포 테스트
<a name="distribution-web-testing"></a>

배포를 생성하면 CloudFront에서는 오리진 서버의 위치를 알 수 있으며, 사용자는 배포와 연결된 도메인 이름을 알 수 있습니다. 배포를 테스트하려면 다음과 같이 합니다.

1. 배포가 완료될 때까지 기다립니다.
   + 콘솔에서 배포 **세부 정보**를 확인합니다. 배포가 완료되면 **마지막 수정** 필드가 **배포 중**에서 날짜 및 시간으로 변경됩니다.

1. 다음 절차에 따라 CloudFront 도메인 이름을 사용하여 객체에 대한 링크를 생성합니다.

1. 링크를 테스트합니다. CloudFront가 웹 페이지 또는 애플리케이션에 객체를 제공합니다.

## 객체에 대한 링크 생성
<a name="distribution-create-object-links"></a>

다음 절차에 따라 CloudFront 웹 배포의 객체에 대한 테스트 링크를 생성합니다.<a name="distribution-web-testing-procedure"></a>

**웹 배포에 객체에 대한 링크를 생성하려면**

1. 다음 HTML 코드를 새 파일에 복사하고 *domain-name*과 *object-name*을 각각 배포의 도메인 이름과 객체의 이름으로 대체합니다.

   ```
   <html>
   <head>
   	<title>My CloudFront Test</title>
   </head>
   <body>
   	<p>My text content goes here.</p>
   	<p><img src="https://domain-name/object-name" alt="my test image"></p>
   </body>
   </html>
   ```

   예를 들어, 도메인 이름이 `d111111abcdef8.cloudfront.net`이고 객체가 `image.jpg`인 경우 링크의 URL은 다음과 같습니다.

   `https://d111111abcdef8.cloudfront.net/image.jpg`.

   객체가 오리진 서버의 폴더에 있는 경우, URL에 이 폴더도 포함해야 합니다. 예를 들어, image.jpg가 오리진 서버의 이미지 폴더에 있으면 URL은 다음과 같습니다.

   `https://d111111abcdef8.cloudfront.net/images/image.jpg`

1. 파일 이름 확장명이 .html인 파일에 HTML 코드를 저장합니다.

1. 브라우저에서 웹 페이지를 열어 객체를 볼 수 있는지 확인합니다.

브라우저가 엣지 로케이션에서 제공한 이미지 파일이 포함된 페이지를 반환합니다. 이 엣지는 CloudFront에서 객체를 서비스하기에 적합한 것으로 확인된 위치입니다.

# 배포 업데이트
<a name="HowToUpdateDistribution"></a>

CloudFront 콘솔에서 AWS 계정과 연결된 CloudFront 배포를 확인하고, 배포에 대한 설정을 보며, 대부분의 설정을 업데이트할 수 있습니다. 변경한 설정은 배포가 AWS 엣지 로케이션에 전파되어야 적용됩니다.

## 콘솔에서 배포 업데이트
<a name="update-distribution-console"></a>

다음 절차에서는 콘솔에서 CloudFront 배포를 업데이트하는 방법을 보여줍니다.

------
#### [ Multi-tenant ]<a name="HowToUpdateDistributionProcedure"></a>

**다중 테넌트 배포를 업데이트하려면 다음과 같이 합니다.**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 다중 테넌트 배포의 ID를 검색하여 선택합니다.

1. 업데이트하려는 설정의 탭을 선택합니다.

1. 업데이트한 후 변경한 내용을 저장하려면 **변경 사항 저장**을 선택합니다. 업데이트할 수 있는 설정에 대한 자세한 내용은 [사전 구성된 배포 설정 참조](template-preconfigured-origin-settings.md) 섹션을 참조하시기 바랍니다.

CloudFront API를 사용하여 배포를 업데이트할 수도 있습니다.
+ 배포를 업데이트하려면 *Amazon CloudFront API 참조*의 [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)을 참조하세요.

**중요**  
배포 업데이트 시 배포를 처음 만들 때는 필요하지 않은 여러 개의 추가 필드가 필요합니다. CloudFront API를 사용하여 배포를 업데이트하는 경우 필수 필드를 모두 포함하려면 *Amazon CloudFront API 참조*의 [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)에 설명된 단계를 따르세요.

배포 테넌트의 다중 테넌트 배포를 변경하려면 배포 테넌트를 업데이트합니다. 또한 배포 테넌트를 업데이트하여 도메인, 인증서, 사용자 지정 또는 파라미터 값을 업데이트합니다. 배포 테넌트 인증서 업데이트에 대한 자세한 내용은 [도메인 및 인증서 추가(분산 테넌트)](managed-cloudfront-certificates.md#vanity-domain-tls-tenant) 섹션을 참조하시기 바랍니다.

**배포 테넌트를 업데이트하려면 다음과 같이 합니다.**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. **SaaS**에서 **배포 테넌트**를 선택합니다.

1. 배포 테넌트를 검색합니다. 검색 창의 드롭다운 메뉴를 사용하여 도메인, 이름, 배포 ID, 인증서 ID, 연결 그룹 ID 또는 웹 ACL ID를 기준으로 필터링합니다.

1. 배포 테넌트 이름을 선택합니다.

1. 일반 **세부 정보**를 업데이트하려면 **편집**을 선택하고 업데이트한 다음 **배포 테넌트 업데이트**를 선택합니다.

1. 업데이트할 다른 설정에 적합한 탭을 선택하여 업데이트하고 이를 저장합니다. 사용자 지정할 수 있는 배포 테넌트 설정에 대한 자세한 내용은 [배포 테넌트 사용자 지정](tenant-customization.md) 섹션을 참조하시기 바랍니다.

------
#### [ Standard ]

**표준 배포를 업데이트하려면 다음과 같이 합니다.**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 배포의 ID를 선택합니다. 이 목록에는 CloudFront 콘솔에 로그인하는 데 사용한 AWS 계정과 연결된 배포가 모두 포함되어 있습니다.

1. 일반 설정을 업데이트하려면 **편집**을 선택합니다. 또는 업데이트하려는 설정의 탭을 선택합니다.

1. 업데이트한 다음, **변경 사항 저장**을 선택합니다. 필드에 대한 자세한 내용은 다음 주제를 참조하십시오.
   + **일반 설정:** [배포 설정](DownloadDistValuesGeneral.md)
   + **오리진 설정:** [오리진 설정](DownloadDistValuesOrigin.md)
   + **캐시 동작 설정:** [캐시 동작 설정](DownloadDistValuesCacheBehavior.md)

1. 배포에서 오리진을 삭제하려면 다음과 같이 합니다.

   1. **동작**을 선택하고 해당 오리진과 연결된 기본 캐시 동작을 다른 오리진으로 옮겼는지 확인합니다.

   1. **오리진**을 선택한 후 오리진을 선택합니다.

   1. **삭제**를 선택합니다.

CloudFront API를 사용하여 배포를 업데이트할 수도 있습니다.
+ 배포를 업데이트하려면 *Amazon CloudFront API 참조*의 [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)을 참조하세요.

**중요**  
배포를 업데이트하는 경우에는 배포를 만들 때는 필요 없었던 여러 개의 추가 필드가 필요합니다. CloudFront API를 사용하여 배포를 업데이트하는 경우 필수 필드를 모두 포함하려면 *Amazon CloudFront API 참조*의 [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)에 설명된 단계를 따르세요.

------

배포 구성에 대한 변경 내용을 저장하면 CloudFront에서 이러한 변경 내용을 모든 엣지 로케이션으로 전파하기 시작합니다. 연속적인 구성 변경 사항은 해당 순서로 전파됩니다. 구성이 엣지 로케이션에서 업데이트될 때까지 CloudFront는 이전 구성에 따라 해당 위치에서 콘텐츠를 계속 제공합니다. 구성이 엣지 로케이션에서 업데이트된 후에는 CloudFront가 즉시 새 구성에 따라 해당 위치에서 콘텐츠를 제공하기 시작합니다.

변경 사항이 모든 엣지 로케이션으로 동시에 전파되지는 않습니다. CloudFront가 변경 내용을 전파하고 있는 동안은 지정된 엣지 로케이션이 이전 구성과 새 구성 중 어느 것에 기초하여 콘텐츠를 제공하는지 확인할 수 없습니다.

**참고**  
드문 경우지만 호스트 또는 네트워크 링크가 중단되는 경우 일부 배포 테넌트 트래픽은 변경 사항이 네트워크를 통과할 때까지 짧은 기간 동안 이전 구성을 사용하여 제공될 수 있습니다.

변경 사항이 전파되는 시기를 확인하려면 콘솔에서 배포 **세부 정보**를 확인합니다. 배포가 완료되면 **마지막 수정** 필드가 **배포 중**에서 날짜 및 시간으로 변경됩니다.

# 배포 태깅
<a name="tagging"></a>

태그란 AWS 리소스를 식별하고 정리할 때 사용할 수 있는 단어 또는 문구입니다. 각 리소스에 태그를 여러 개 추가할 수 있고, 각 태그는 사용자가 정의한 키와 값을 포함할 수 있습니다. 예를 들어, 키는 "도메인"이고 값은 "example.com"일 수 있습니다. 추가하는 태그에 따라 리소스를 검색하고 필터링할 수 있습니다.

다음 예와 같이 CloudFront에서 태그를 사용할 수 있습니다.
+ CloudFront 배포에 태그 기반 권한을 적용합니다. 자세한 내용은 [CloudFront와 ABAC](security_iam_service-with-iam.md#security_iam_service-with-iam-tags) 섹션을 참조하세요.
+ 다양한 범주에서 청구 정보를 추적합니다. CloudFront 배포나 다른 AWS 리소스(Amazon EC2 인스턴스 또는 Amazon S3 버킷 등)에 태그를 적용하고 그 태그를 활성화하면 AWS는 사용 내역 및 비용을 활성 태그 기준으로 집계한 비용 할당 보고서를 CSV 파일 형식으로 작성합니다.

  비즈니스 범주를 나타내는 태그(예: 비용 센터, 애플리케이션 이름 또는 소유자)를 적용하여 여러 서비스에 대한 비용을 정리할 수 있습니다. 비용 할당 태그 사용에 대한 자세한 내용은 *AWS Billing 사용 설명서*의 [비용 할당 태그 사용](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)을 참조하십시오.

**참고**  
배포에는 태그를 지정할 수 있지만 원본 액세스 ID 또는 배포에는 태그 지정이 불가능합니다.
현재 CloudFront에는 [Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)나 [리소스 그룹](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html)을 사용할 수 없습니다.
현재 배포에 추가할 수 있는 태그의 최대 수는 [일반 할당량](cloudfront-limits.md#limits-general) 단원을 참조하세요.

**Contents**
+ [태그 제한](#tagging-restrictions)
+ [배포에 태그 추가, 편집, 삭제](#tagging-add-edit-delete)
+ [프로그래밍 방식 태깅](#tagging-related-information)

## 태그 제한
<a name="tagging-restrictions"></a>

태그에 적용되는 기본 제한은 다음과 같습니다.
+ 배포당 최대 태그 수는 [일반 할당량](cloudfront-limits.md#limits-general) 섹션을 참조하세요.
+ 최대 키 길이 - 유니코드 128자
+ 최대 값 길이 - 유니코드 256자
+ 키 및 값의 유효값 - a-z, A-Z, 0-9, 공백 및 특수 문자 \$1 . : / = \$1 - 및 @
+ 태그 키와 값은 대/소문자를 구분합니다
+ 키 접두사로 `aws:`를 사용하지 마세요. 이 접두사는 AWS용으로 예약되어 있습니다.

## 배포에 태그 추가, 편집, 삭제
<a name="tagging-add-edit-delete"></a>

CloudFront 콘솔을 사용하여 배포의 태그를 관리할 수 있습니다.<a name="tagging-add-edit-delete-procedure"></a>

**배포에 태그를 추가, 편집 또는 삭제하려면**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 업데이트하려는 배포의 ID를 선택합니다.

1. [**Tags**] 탭을 선택합니다.

1. **태그 관리**를 선택합니다.

1. **태그 관리** 페이지에서 다음 작업을 수행할 수 있습니다.
   + 태그를 추가하려면 키를 입력하고, 필요한 경우 태그 값도 입력합니다. 태그를 더 추가하려면 **새 태그 추가**를 선택합니다.
   + 태그를 편집하려면 태그의 키나 해당 값 또는 둘 다를 변경합니다. 태그의 값은 삭제할 수 있지만 키는 필수입니다.
   + 태그를 삭제하려면 **제거**를 선택합니다.

1. **변경 사항 저장**을 선택합니다.

## 프로그래밍 방식 태깅
<a name="tagging-related-information"></a>

CloudFront API, AWS Command Line Interface(AWS CLI), AWS SDK 및 AWS Tools for Windows PowerShell을 사용하여 태그를 적용할 수도 있습니다. 자세한 내용은 다음 항목을 참조하세요.
+ CloudFront API 작업:
  + [ListTagsForResource](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListTagsForResource.html) 
  + [TagResource](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_TagResource.html) 
  + [UntagResource](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UntagResource.html) 
+ AWS CLI - *AWS CLI 명령 참조*에서 [cloudfront](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudfront/index.html) 참조
+ AWS SDK - [AWS 설명서](https://docs.aws.amazon.com/index.html) 페이지에서 해당 SDK 설명서 참조
+ Windows PowerShell용 도구 – [AWS Tools for PowerShell Cmdlet Reference(Cmdlet 참조)](https://docs.aws.amazon.com/powershell/latest/reference/)에서 [Amazon CloudFront](https://docs.aws.amazon.com/powershell/latest/reference/items/CloudFront_cmdlets.html)를 참조하십시오.

# 배포 삭제
<a name="HowToDeleteDistribution"></a>

다음 절차에서는 CloudFront 콘솔을 사용하여 배포를 삭제합니다. CloudFront API를 사용한 삭제에 대한 자세한 내용은 **Amazon CloudFront API 참조의 [DeleteDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DeleteDistribution.html)을 참조하세요.

S3 버킷에 OAC가 연결된 배포를 삭제해야 하는 경우 중요한 세부 사항은 [S3 버킷에 OAC가 연결된 배포 삭제](private-content-restricting-access-to-s3.md#delete-oac-distribution-s3)를 참조합니다.

**주의**  
배포를 삭제하려면 먼저 비활성화해야 하며, 이를 위해서는 배포 업데이트 권한이 필요합니다. 삭제된 배포는 복구할 수 없습니다.
대체 도메인 이름이 연결된 배포를 비활성화하면, 다른 배포에 동일한 도메인과 일치하는 와일드카드(\$1)가 있는 대체 도메인 이름(예: \$1.example.com)이 있더라도 CloudFront가 해당 도메인 이름(예: www.example.com)에 대한 트래픽 수신을 중지합니다.
[CloudFront 정액 요금제](flat-rate-pricing-plan.md)를 구독하는 배포는 삭제할 수 없습니다. "You can't delete this distribution while it's subscribed to a pricing plan."이라는 오류가 표시됩니다. 먼저 요금제를 취소한 다음 현재 결제 주기 후에 배포를 삭제해야 합니다.

------
#### [ Multi-tenant ]

다중 테넌트 배포를 삭제하려면 먼저 모든 연결된 배포 테넌트를 삭제해야 합니다.<a name="HowToDeleteDistributionProcedure"></a>

**다중 테넌트 배포를 삭제하려면 다음과 같이 합니다.**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. CloudFront 콘솔의 오른쪽 창에서 삭제하려는 다중 테넌트 배포의 이름을 선택합니다.

1. **테넌트**에서 모든 연결된 배포 테넌트를 선택하고 삭제합니다.

1. 배포를 사용 해제하려면 **비활성화**를 선택하고 **배포 비활성화**를 선택하여 확인합니다.

1. **마지막 수정 날짜** 열 아래에 새 타임스탬프가 나타날 때까지 기다리십시오.
   + CloudFront가 변경 사항을 모든 엣지 로케이션에 전파하는 데 몇 분 정도 걸릴 수 있습니다.

1. **삭제**, **배포 삭제**를 차례로 선택합니다.

**배포 테넌트를 삭제하려면 다음과 같이 합니다.**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. **SaaS**에서 **배포 테넌트**를 선택합니다.

1. 배포 테넌트를 검색합니다. 검색 창의 드롭다운 메뉴를 사용하여 도메인, 이름, 배포 ID, 인증서 ID, 연결 그룹 ID 또는 웹 ACL ID를 기준으로 필터링합니다.

1. 삭제할 배포 테넌트를 선택합니다.

1. **테넌트 삭제**, **배포 테넌트 삭제**를 선택합니다.

------
#### [ Standard ]

**표준 배포를 삭제하려면 다음과 같이 합니다.**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. CloudFront 콘솔의 오른쪽 창에서 삭제할 배포를 찾습니다.
   + **상태** 열에 배포가 이미 **비활성화됨**으로 표시되면 6단계로 건너뜁니다.
   + **상태**가 **활성화됨**으로 표시되지만 배포의 **마지막 수정 날짜** 열에 여전히 **배포 중**으로 표시되는 경우 배포가 완료될 때까지 기다린 다음 3단계로 진행합니다.

1. CloudFront 콘솔의 오른쪽 창에서 삭제할 배포에 해당하는 확인란을 선택합니다.

1. **비활성화**를 선택하여 배포를 비활성화하고 **예, 비활성화**를 선택하여 확인합니다. 그런 다음 **닫기**를 선택합니다.
   + **상태** 열의 값이 **비활성화됨**으로 즉시 변경됩니다.

1. **마지막 수정 날짜** 열 아래에 새 타임스탬프가 나타날 때까지 기다리십시오.
   + CloudFront가 변경 사항을 모든 엣지 로케이션에 전파하는 데 몇 분 정도 걸릴 수 있습니다.

1. 삭제할 배포에 해당하는 확인란을 선택합니다.

1. **삭제**와 **삭제**를 차례로 선택합니다.
   + **삭제** 옵션을 사용할 수 없는 경우 CloudFront가 여전히 변경 사항을 엣지 로케이션에 전파하고 있음을 의미합니다. **마지막 수정 날짜** 열 아래에 새 타임스탬프가 나타날 때까지 기다린 후 6\$17단계를 반복합니다.

------

# CloudFront 배포에 다양한 오리진 사용
<a name="DownloadDistS3AndCustomOrigins"></a>

배포를 만들 때 CloudFront가 파일에 대한 요청을 보내는 *원본*을 지정합니다. CloudFront에서 여러 원본을 사용할 수 있습니다. 예를 들어 Amazon S3 버킷, MediaStore 컨테이너, MediaPackage 채널, Application Load Balancer 또는 AWS Lambda 함수 URL을 사용할 수 있습니다. CloudFront 배포를 만들면 CloudFront가 콘텐츠 오리진 유형에 따라 대부분의 배포 설정을 자동으로 구성합니다. 자세한 내용은 [사전 구성된 배포 설정 참조](template-preconfigured-origin-settings.md) 섹션을 참조하세요.

프라이빗 서브넷에 Application Load Balancer, Network Load Balancer, EC2 인스턴스가 있는 경우 VPC 오리진으로 사용할 수 있습니다. VPC 오리진을 사용하면 CloudFront 배포가 있는 프라이빗 서브넷에서만 애플리케이션에 액세스할 수 있으므로 퍼블릭 인터넷에서는 애플리케이션에 액세스할 수 없습니다. 자세한 내용은 [VPC 오리진으로 액세스 제한](private-content-vpc-origins.md) 섹션을 참조하세요.

**참고**  
엣지 함수를 사용하여 각 요청에 적합한 오리진을 동적으로 선택할 수 있습니다. CloudFront Functions 또는 Lambda@Edge를 사용하여 뷰어의 지리적 위치, 요청 헤더 또는 쿼리 문자열 파라미터와 같은 요인에 따라 요청을 다른 오리진으로 라우팅할 수 있습니다. 자세한 내용은 [함수를 사용하여 엣지에서 사용자 지정](edge-functions.md) 섹션을 참조하세요.

**Topics**
+ [Amazon S3 버킷 사용](#using-s3-as-origin)
+ [MediaStore 컨테이너 또는 MediaPackage 채널 사용](#concept_AWS_Media)
+ [Application Load Balancer 사용](#concept_elb_origin)
+ [Network Load Balancer 사용](#concept_nlb_origin)
+ [Lambda 함수 URL 사용](#concept_lambda_function_url)
+ [Amazon EC2(또는 기타 사용자 지정 오리진) 사용](#concept_CustomOrigin)
+ [CloudFront 오리진 그룹 사용](#concept_origin_groups)
+ [Amazon API Gateway 사용](#use-api-gate-way-origin)

## Amazon S3 버킷 사용
<a name="using-s3-as-origin"></a>

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

**Topics**
+ [표준 Amazon S3 버킷 사용](#concept_S3Origin)
+ [Amazon S3 객체 Lambda 사용](#using-S3-Object-Lambda)
+ [Amazon S3 액세스 포인트 사용](#using-S3-Access-Point)
+ [웹 사이트 엔드포인트로 구성된 Amazon S3 버킷 사용](#concept_S3Origin_website)
+ [기존 Amazon S3 버킷에 CloudFront 추가](#adding-cloudfront-to-s3)
+ [Amazon S3 버킷을 다른 AWS 리전으로 이동](#move-s3-bucket-different-region)

### 표준 Amazon S3 버킷 사용
<a name="concept_S3Origin"></a>

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 요금](https://aws.amazon.com/cloudfront/pricing/)을 참조하세요. CloudFront에서 기존 S3 버킷을 사용하는 자세한 방법은 [기존 Amazon S3 버킷에 CloudFront 추가](#adding-cloudfront-to-s3) 단원을 참조하세요.

**중요**  
버킷을 CloudFront와 함께 사용하려면 DNS 명명 요구 사항을 준수하는 이름을 사용해야 합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [버킷 이름 지정 규칙](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html)을 참조하세요.

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

`bucket-name.s3.region.amazonaws.com`

이 형식으로 버킷 이름을 지정할 경우 다음 CloudFront 기능을 사용할 수 있습니다.
+ SSL/TLS를 사용하여 Amazon S3 버킷과 통신하도록 CloudFront를 구성합니다. 자세한 내용은 [CloudFront에서 HTTPS 사용](using-https.md) 섹션을 참조하세요.
+ 오리진 액세스 제어를 사용하여 뷰어에게 Amazon S3 URL이 아닌 CloudFront URL을 사용하여 콘텐츠에 액세스하도록 요구합니다. 자세한 내용은 [Amazon S3 오리진에 대한 액세스 제한](private-content-restricting-access-to-s3.md) 섹션을 참조하세요.
+ `POST` 및 `PUT` 요청을 CloudFront에 제출하여 버킷의 콘텐츠를 업데이트합니다. 자세한 내용은 [HTTP 메소드](RequestAndResponseBehaviorS3Origin.md#RequestS3HTTPMethods) 주제에서 [CloudFront에서 요청을 처리하고 Amazon S3 오리진에 요청을 전달하는 방법](RequestAndResponseBehaviorS3Origin.md#RequestBehaviorS3Origin) 단원을 참조하십시오.

다음 형식을 사용하여 버킷을 지정하지 마세요.
+ Amazon S3 경로 형식: `s3.amazonaws.com/bucket-name`
+ Amazon S3 CNAME

**참고**  
CloudFront는 S3 Intelligent-Tiering을 포함한 모든 스토리지 클래스를 사용하여 S3 오리진을 지원합니다. CloudFront가 S3 오리진에서 객체를 요청하면 현재 있는 스토리지 계층에 관계없이 객체가 검색됩니다. CloudFront에서 S3 Intelligent-Tiering을 사용하더라도 배포의 성능이나 기능에는 영향을 주지 않습니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [Amazon S3 Intelligent-Tiering을 사용한 스토리지 비용 관리](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html)를 참조하세요.

### Amazon S3 객체 Lambda 사용
<a name="using-S3-Object-Lambda"></a>

[객체 Lambda 액세스 포인트를 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/olap-create.html)할 때 Amazon S3는 객체 Lambda 액세스 포인트에 대한 고유한 별칭을 자동으로 생성합니다. Amazon S3 버킷 이름 대신 [이 별칭](https://docs.aws.amazon.com/AmazonS3/latest/userguide/olap-use.html#ol-access-points-alias)을 CloudFront 배포의 오리진으로 사용할 수 있습니다.

객체 Lambda 액세스 포인트 별칭을 CloudFront의 오리진으로 사용할 때는 다음 형식을 사용하는 것이 좋습니다.

`alias.s3.region.amazonaws.com`

`alias`을 찾는 방법에 대한 자세한 내용은 **Amazon S3 사용 설명서의 [S3 버킷 객체 Lambda 액세스 포인트에 버킷 스타일 별칭을 사용하는 방법](https://docs.aws.amazon.com/AmazonS3/latest/userguide/olap-use.html#ol-access-points-alias)을 참조하세요.

**중요**  
객체 Lambda 액세스 포인트를 CloudFront의 오리진으로 사용하는 경우 [오리진 액세스 제어](private-content-restricting-access-to-s3.md)를 사용해야 합니다.

사용 사례의 예는 [Amazon CloudFront와 함께 Amazon S3 객체 Lambda를 사용하여 최종 사용자에게 콘텐츠 맞춤화](https://aws.amazon.com/blogs/aws/new-use-amazon-s3-object-lambda-with-amazon-cloudfront-to-tailor-content-for-end-users/)를 참조하세요.

CloudFront는 객체 Lambda 액세스 포인트 오리진을 [표준 Amazon S3 버킷 오리진](#concept_S3Origin)과 동일하게 취급합니다.

Amazon S3 객체 Lambda를 배포용 오리진으로 사용하는 경우 다음 네 가지 권한을 구성해야 합니다.

------
#### [ Object Lambda Access Point ]

**객체 Lambda 액세스 포인트에 대한 사용 권한을 추가하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **객체 Lambda 액세스 포인트**를 선택합니다.

1. 사용할 객체 Lambda 액세스 포인트를 선택합니다.

1. **권한** 탭을 선택합니다.

1. **객체 Lambda 액세스 포인트 정책** 섹션에서 **편집**을 선택합니다.

1. **정책** 필드에 다음 정책을 붙여 넣습니다.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Service": "cloudfront.amazonaws.com"
               },
               "Action": "s3-object-lambda:Get*",
               "Resource": "arn:aws:s3-object-lambda:us-east-1:123456789012:accesspoint/Object-Lambda-Access-Point-name",
               "Condition": {
                   "StringEquals": {
                       "aws:SourceArn": "arn:aws:cloudfront::123456789012:distribution/CloudFront-distribution-ID"
                   }
               }
           }
       ]
   }
   ```

------

1. **변경 사항 저장**을 선택합니다.

------
#### [ Amazon S3 Access Point ]

**Amazon S3 액세스 포인트에 대한 사용 권한을 추가하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 탐색 창에서 **액세스 포인트**를 선택합니다.

1. 사용할 Amazon S3 액세스 포인트를 선택합니다.

1. **권한** 탭을 선택합니다.

1. **액세스 포인트 정책** 섹션에서 **편집**을 선택합니다.

1. **정책** 필드에 다음 정책을 붙여 넣습니다.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Id": "default",
       "Statement": [
           {
               "Sid": "s3objlambda",
               "Effect": "Allow",
               "Principal": {
                   "Service": "cloudfront.amazonaws.com"
               },
               "Action": "s3:*",
               "Resource": [
                   "arn:aws:s3:us-east-1:123456789012:accesspoint/Access-Point-name",
                   "arn:aws:s3:us-east-1:123456789012:accesspoint/Access-Point-name/object/*"
               ],
               "Condition": {
                   "ForAnyValue:StringEquals": {
                       "aws:CalledVia": "s3-object-lambda.amazonaws.com"
                   }
               }
           }
       ]
   }
   ```

------

1. **저장**을 선택합니다.

------
#### [ Amazon S3 bucket ]

**Amazon S3 버킷에 권한을 부여합니다.**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **버킷**을 선택합니다.

1. 사용할 Amazon S3 버킷을 선택합니다.

1. **권한** 탭을 선택합니다.

1. **버킷 정책** 섹션에서 **편집**을 선택합니다.

1. **정책** 필드에 다음 정책을 붙여 넣습니다.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "AWS": "*"
               },
               "Action": "*",
               "Resource": [
                   "arn:aws:s3:::bucket-name",
                   "arn:aws:s3:::bucket-name/*"
               ],
               "Condition": {
                   "StringEquals": {
                       "s3:DataAccessPointAccount": "AWS-account-ID"
                   }
               }
           }
       ]
   }
   ```

------

1. **변경 사항 저장**을 선택합니다.

------
#### [ AWS Lambda function ]

**Lambda 함수에 대한 권한 추가하려면**

1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/)에서 AWS Lambda 콘솔을 엽니다.

1. 탐색 창에서 **함수**를 선택합니다.

1. 사용할 AWS Lambda 함수를 선택합니다.

1. **구성** 탭을 선택한 다음, **권한**을 선택합니다.

1. **리소스 기반 정책 명령문** 섹션에서 **권한 추가**를 선택합니다.

1. 을 선택합니다..**AWS 계정**

1. **명령문 ID**의 이름을 입력합니다.

1. **보안 주체**에 `cloudfront.amazonaws.com`을 입력합니다.

1. **작업 **드롭다운 메뉴에서 `lambda:InvokeFunction`을 선택합니다.

1. **저장**을 선택합니다.

------

### Amazon S3 액세스 포인트 사용
<a name="using-S3-Access-Point"></a>

[S3 액세스 포인트를 사용하면](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-access-points.html) Amazon S3는 고유한 별칭을 자동으로 생성합니다. Amazon S3 버킷 이름 대신 이 별칭을 CloudFront 배포의 오리진으로 사용할 수 있습니다.

객체 Amazon S3 액세스 포인트 별칭을 CloudFront의 오리진으로 사용할 때는 다음 형식을 사용하는 것이 좋습니다.

`alias.s3.region.amazonaws.com`

`alias`를 찾는 방법에 대한 자세한 내용은 Amazon S3 사용 설명서의 [S3 버킷 액세스 포인트에 버킷 스타일 별칭을 사용](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points-alias.html)을 참조합니다.**

**중요**  
Amazon S3 액세스 포인트를 CloudFront의 오리진으로 사용하는 경우 [오리진 액세스 제어](private-content-restricting-access-to-s3.md)를 사용해야 합니다.

CloudFront는 Amazon S3 액세스 포인트 오리진을 [표준 Amazon S3 버킷 오리진](#concept_S3Origin)과 동일하게 취급합니다.

Amazon S3 객체 Lambda를 배포용 오리진으로 사용하는 경우 다음 두 가지 권한을 구성해야 합니다.

------
#### [ Amazon S3 Access Point ]

**Amazon S3 액세스 포인트에 대한 사용 권한을 추가하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 탐색 창에서 **액세스 포인트**를 선택합니다.

1. 사용할 Amazon S3 액세스 포인트를 선택합니다.

1. **권한** 탭을 선택합니다.

1. **액세스 포인트 정책** 섹션에서 **편집**을 선택합니다.

1. **정책** 필드에 다음 정책을 붙여 넣습니다.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Id": "default",
       "Statement": [
           {
               "Sid": "s3objlambda",
               "Effect": "Allow",
               "Principal": {"Service": "cloudfront.amazonaws.com"},
               "Action": "s3:*",
               "Resource": [
                   "arn:aws:s3:us-east-1:123456789012:accesspoint/Access-Point-name",
                   "arn:aws:s3:us-east-1:123456789012:accesspoint/Access-Point-name/object/*"
               ],
               "Condition": {
                   "StringEquals": {"aws:SourceArn": "arn:aws:cloudfront::123456789012:distribution/CloudFront-distribution-ID"}
               }
           }
       ]
   }
   ```

------

1. **저장**을 선택합니다.

------
#### [ Amazon S3 bucket ]

**Amazon S3 버킷에 권한을 부여합니다.**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **버킷**을 선택합니다.

1. 사용할 Amazon S3 버킷을 선택합니다.

1. **권한** 탭을 선택합니다.

1. **버킷 정책** 섹션에서 **편집**을 선택합니다.

1. **정책** 필드에 다음 정책을 붙여 넣습니다.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "AWS": "*"
               },
               "Action": "*",
               "Resource": [
                   "arn:aws:s3:::bucket-name",
                   "arn:aws:s3:::bucket-name/*"
               ],
               "Condition": {
                   "StringEquals": {
                       "s3:DataAccessPointAccount": "AWS-account-ID"
                   }
               }
           }
       ]
   }
   ```

------

1. **변경 사항 저장**을 선택합니다.

------

### 웹 사이트 엔드포인트로 구성된 Amazon S3 버킷 사용
<a name="concept_S3Origin_website"></a>

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

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

Amazon S3 정적 웹 사이트 엔드포인트 지정에 대한 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [웹 사이트 엔드포인트](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html)를 참조하세요.

오리진으로서 이 형식으로 된 버킷 이름을 지정할 경우 Amazon S3 리디렉션과 Amazon S3 사용자 지정 오류 문서를 사용할 수 있습니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [사용자 지정 오류 문서 구성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CustomErrorDocSupport.html) 및 [리디렉션 구성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-page-redirect.html)을 참조하세요. (CloudFront에서도 사용자 지정 오류 페이지를 제공합니다. 자세한 내용은 [특정 HTTP 상태 코드에 대한 사용자 지정 오류 페이지 생성](creating-custom-error-pages.md) 단원을 참조하세요.)

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

**참고**  
CloudFront API를 사용하여 웹 사이트 엔드포인트로 구성되는 Amazon S3 버킷 포함 배포를 사용하는 경우 웹 사이트가 Amazon S3 버킷에서 호스팅된 경우에도 `CustomOriginConfig`를 사용하여 구성해야 합니다. CloudFront API를 사용하여 배포를 만드는 방법에 대한 자세한 내용은 *Amazon CloudFront API 참조*의 [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)을 참조하세요.

### 기존 Amazon S3 버킷에 CloudFront 추가
<a name="adding-cloudfront-to-s3"></a>

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

**참고**  
CloudFront에서 Amazon S3 cross-origin 리소스 공유 설정을 지키도록 하려는 경우 `Origin` 헤더를 Amazon S3로 전달하도록 CloudFront를 구성합니다. 자세한 내용은 [요청 헤더 기반의 콘텐츠 캐싱](header-caching.md) 섹션을 참조하세요.

현재 Amazon S3 버킷의 도메인 이름(예: amzn-s3-demo-bucket.s3.us-west-2.amazonaws.com) 대신 고유 도메인 이름(예: example.com)을 사용하여 Amazon S3 버킷에서 콘텐츠를 직접 배포하는 경우, 다음 절차를 이용해 중단 없이 CloudFront를 추가할 수 있습니다.<a name="migrate-s3-to-cloudfront-process"></a>

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

1. CloudFront 배포를 만듭니다. 자세한 내용은 [배포 생성](distribution-web-creating-console.md) 섹션을 참조하세요.

   배포를 생성할 때 Amazon S3 버킷의 이름을 오리진 서버로 지정합니다.
**중요**  
버킷을 CloudFront와 함께 사용하려면 DNS 명명 요구 사항을 준수하는 이름을 사용해야 합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [버킷 이름 지정 규칙](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html)을 참조하세요.

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

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

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

1. Amazon S3 CNAME을 사용할 경우 애플리케이션은 Amazon S3 버킷에서 객체를 참조할 때 버킷 이름(예: amzn-s3-demo-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://amzn-s3-demo-bucket.s3.amazonaws.com/images/image.jpg`

   쿼리를 Amazon S3 버킷 대신에 CloudFront 배포로 라우팅하려면 DNS 서비스 공급자가 제공하는 방법을 사용하여 도메인의 CNAME 리소스 레코드 세트를 업데이트해야 합니다. 이 업데이트된 CNAME 레코드가 DNS 쿼리를 고유 도메인에서 배포의 CloudFront 도메인 이름으로 리디렉션합니다. 자세한 내용은 DNS 서비스 공급자가 제공하는 설명서를 참조하십시오.
**참고**  
Route 53을 DNS 서비스로 사용하는 경우 CNAME 리소스 레코드 세트 또는 별칭 리소스 레코드 세트를 사용할 수 있습니다. 리소스 레코드 세트 편집에 대한 자세한 내용은 [레코드 편집](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-editing.html)을 참조하세요. 별칭 리소스 레코드 세트에 대한 자세한 내용은 [별칭 및 비-별칭 레코드 간의 선택](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)을 참조하세요. 두 주제는 모두 *Amazon Route 53 개발자 안내서*에 나와 있습니다.

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

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

### Amazon S3 버킷을 다른 AWS 리전으로 이동
<a name="move-s3-bucket-different-region"></a>

Amazon S3를 CloudFront 배포에 대한 원본으로 사용하고 있고 버킷을 다른 AWS 리전으로 옮기는 경우, 다음 두 조건이 참일 때 CloudFront가 그 레코드를 업데이트하여 새 리전을 사용하는 데 최대 1시간이 걸릴 수 있습니다.
+ CloudFront 원본 액세스 ID(OAI)를 사용하여 버킷에 대한 액세스를 제한하고 있습니다.
+ 인증을 위해 서명 버전 4가 필요한 Amazon S3 리전으로 버킷을 옮깁니다.

OAI를 사용할 때 CloudFront는 그 리전(다른 값들 중에서)을 사용해 버킷에서 객체를 요청할 때 사용하는 서명을 계산합니다. OAI에 대한 자세한 내용은 [오리진 액세스 ID 사용(레거시, 권장하지 않음)](private-content-restricting-access-to-s3.md#private-content-restricting-access-to-s3-oai) 단원을 참조하십시오. 서명 버전 2를 지원하는 AWS 리전의 목록은 *Amazon Web Services 일반 참조*의 [서명 버전 2 서명 과정](https://docs.aws.amazon.com/general/latest/gr/signature-version-2.html)을 참조하세요.

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

## MediaStore 컨테이너 또는 MediaPackage 채널 사용
<a name="concept_AWS_Media"></a>

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

자세한 내용 및 단계별 지침은 다음 단원을 참조하십시오.
+ [AWS Elemental MediaStore를 오리진으로 사용하여 비디오를 제공합니다.](live-streaming.md#video-streaming-mediastore)
+ [AWS Elemental MediaPackage를 사용하여 포맷된 라이브 비디오 제공](live-streaming.md#live-streaming-with-mediapackage)

## Application Load Balancer 사용
<a name="concept_elb_origin"></a>

CloudFront를 사용하여 트래픽을 내부 및 인터넷 연결 Application Load Balancer로 라우팅할 수 있습니다.

오리진이 하나 이상의 Amazon EC2 인스턴스에서 호스팅되는 하나 이상의 HTTP(S) 서버(웹 서버)인 경우 인터넷 연결 Application Load Balancer를 사용하여 인스턴스에 트래픽을 배포할 수 있습니다. 인터넷 경계 로드 밸런서는 공개적으로 확인 가능한 DNS 이름이 있으며 인터넷을 통해 클라이언트의 요청을 대상으로 라우팅합니다.

뷰어가 로드 밸런서에 직접 액세스하지 않고 CloudFront를 통해서만 웹 서버에 액세스할 수 있도록 하는 방법을 비롯하여 인터넷 연결 Application Load Balancer를 CloudFront의 오리진으로 사용하는 방법에 대한 자세한 내용은 [Application Load Balancer에 대한 액세스 제한](restrict-access-to-load-balancer.md) 섹션을 참조하세요.

또는 VPC 오리진을 사용하여 가상 프라이빗 클라우드(VPC) 프라이빗 서브넷의 내부 Application Load Balancer를 통해 호스팅되는 애플리케이션에서 콘텐츠를 제공할 수 있습니다. VPC 오리진은 퍼블릭 인터넷에서 애플리케이션에 액세스할 수 없도록 합니다. 자세한 내용은 [VPC 오리진으로 액세스 제한](private-content-vpc-origins.md) 섹션을 참조하세요.

## Network Load Balancer 사용
<a name="concept_nlb_origin"></a>

Amazon CloudFront에서는 내부 및 인터넷 연결 Network Load Balancer를 모두 사용할 수 있습니다. VPC 오리진을 사용하여 CloudFront의 프라이빗 서브넷 내에서 내부 Network Load Balancer를 사용할 수 있습니다. CloudFront VPC 오리진을 사용하면 퍼블릭 인터넷에 노출시키지 않고 프라이빗 VPC 서브넷에 호스팅된 애플리케이션에서 콘텐츠를 제공할 수 있습니다. 자세한 내용은 [VPC 오리진으로 액세스 제한](private-content-vpc-origins.md) 섹션을 참조하세요.

또는 CloudFront를 사용하여 인터넷 연결 Network Load Balancer에서 트래픽을 전송할 수도 있습니다. 인터넷 연결 로드 밸런서는 공개적으로 확인 가능한 DNS 이름을 가지며 인터넷의 클라이언트와 CloudFront 배포 모두에서 요청을 수신할 수 있습니다.

## Lambda 함수 URL 사용
<a name="concept_lambda_function_url"></a>

[Lambda 함수 URL](https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html)은 Lambda 함수를 위한 전용 HTTPS 엔드포인트입니다. Lambda 함수 URL을 사용하여 서버리스 웹 애플리케이션을 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에 공개적으로 액세스할 수 있어야 합니다. 이렇게 하려면 다음 방법 중 하나를 사용하세요.
+ 오리진 액세스 제어(OAC)를 사용하는 경우 Lambda 함수 URL의 `AuthType` 파라미터는 `AWS_IAM` 값을 사용하고 리소스 기반 정책에서 `lambda:InvokeFunctionUrl` 및 `lambda:InvokeFunction` 권한을 허용해야 합니다. OAC에 Lambda 함수 URL 사용에 대한 자세한 내용은 [AWS Lambda 함수 URL 오리진에 대한 액세스 제한](private-content-restricting-access-to-lambda.md) 섹션을 참조하세요.
+ OAC를 사용하지 않는 경우 함수 URL의 `AuthType` 파라미터를 `NONE`으로 설정하고 리소스 기반 정책에서 `lambda:InvokeFunctionUrl` 권한을 허용합니다.



또한 CloudFront가 오리진으로 보내는 요청에 [사용자 지정 오리진 헤더를 추가](add-origin-custom-headers.md)하고 헤더가 요청에 없는 경우 오류 응답을 반환하는 함수 코드를 작성할 수도 있습니다. 이렇게 하면 Lambda 함수 URL을 직접 사용하지 않고 CloudFront를 통해서만 웹 애플리케이션에 액세스할 수 있습니다.

Lambda 함수 URL에 대한 자세한 내용은 *AWS Lambda 개발자 가이드*에서 다음 주제를 참조하세요.
+ [Lambda 함수 URL](https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html) - Lambda 함수 URL 기능에 대한 일반적인 개요
+ [Lambda 함수 URL 호출](https://docs.aws.amazon.com/lambda/latest/dg/urls-invocation.html) - 서버리스 웹 애플리케이션 코딩에 사용할 요청 및 응답 페이로드에 대한 세부 정보 포함
+ [Lambda 함수 URL에 대한 보안 및 인증 모델](https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html) – Lambda 인증 유형에 대한 세부 정보 포함

## Amazon EC2(또는 기타 사용자 지정 오리진) 사용
<a name="concept_CustomOrigin"></a>

Amazon CloudFront에서는 내부 및 인터넷 연결 EC2 인스턴스를 모두 사용할 수 있습니다. VPC 오리진을 사용하여 CloudFront에서 프라이빗 서브넷 내의 내부 EC2 인스턴스를 사용할 수 있습니다. CloudFront VPC 오리진을 사용하면 퍼블릭 인터넷에 노출시키지 않고 프라이빗 VPC 서브넷에 호스팅된 애플리케이션에서 콘텐츠를 제공할 수 있습니다. 자세한 내용은 [VPC 오리진으로 액세스 제한](private-content-vpc-origins.md) 섹션을 참조하세요.

사용자 지정 오리진은 공개적으로 확인 가능한 DNS 이름을 가진 HTTP(S) 웹 서버로서 클라이언트의 요청을 인터넷을 통해 대상으로 라우팅합니다. HTTP(S) 서버는 AWS(예: Amazon EC2 인스턴스)에 호스팅하거나 다른 곳에서 호스팅할 수 있습니다. 웹 사이트 엔드포인트로서 구성된 Amazon S3 오리진은 또한 사용자 지정 오리진으로 간주됩니다. 자세한 내용은 [웹 사이트 엔드포인트로 구성된 Amazon S3 버킷 사용](#concept_S3Origin_website) 섹션을 참조하세요.

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

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

CloudFront를 통한 Amazon EC2 인스턴스 및 기타 사용자 지정 오리진 사용에 대한 이러한 지침을 따르세요.
+ 동일한 CloudFront 오리진에 대한 콘텐츠를 서비스하는 모든 서버의 동일한 콘텐츠를 호스팅 및 서비스합니다. 자세한 내용은 [오리진 설정](DownloadDistValuesOrigin.md) 주제에서 [모든 배포 설정 참조](distribution-web-values-specify.md) 단원을 참조하십시오.
+ 지원 또는 CloudFront에서 이 값을 디버깅에 사용해야 할 경우 모든 서버에 `X-Amz-Cf-Id` 헤더 항목을 로그합니다.
+ 사용자 지정 원본이 수신 대기하는 HTTP 및 HTTPS 포트에 대한 요청을 제한합니다.
+ 구현 시 모든 서버의 클록을 동기화합니다. CloudFront는 로그 및 보고용으로 서명된 URL 및 서명된 쿠키에 대해 UTC(협정 세계시)를 사용합니다. 또한 CloudWatch 지표를 사용하여 CloudFront 활동을 모니터링하는 경우 CloudWatch에서도 UTC를 사용한다는 점에 유의하세요.
+ 이중화 서버를 사용하여 오류를 처리합니다.
+ 프라이빗 콘텐츠를 제공하기 위한 사용자 지정 오리진 사용에 대한 자세한 내용은 [사용자 지정 오리진의 파일에 대한 액세스 제한](private-content-overview.md#forward-custom-headers-restrict-access)을 참조하십시오.
+ 요청 및 응답 동작과 지원되는 HTTP 상태 코드에 대한 자세한 내용은 [요청 및 응답 동작](RequestAndResponseBehavior.md) 단원을 참조하십시오.

Amazon EC2를 사용자 지정 원본으로 사용하는 경우 다음을 수행하는 것이 좋습니다.
+ 웹 서버용 소프트웨어를 자동으로 설치하는 Amazon Machine Image를 사용합니다. 자세한 내용은 [Amazon EC2 설명서](https://docs.aws.amazon.com/ec2/index.html)를 참조하세요.
+ Elastic Load Balancing 로드 밸런서를 사용하여 여러 Amazon EC2 인스턴스 간 트래픽을 처리하고 Amazon EC2 인스턴스에 대한 변경으로부터 애플리케이션을 격리할 수 있습니다. 예를 들어, 로드 밸런서를 사용하는 경우 애플리케이션을 변경하지 않고도 Amazon EC2 인스턴스를 추가 및 삭제할 수 있습니다. 자세한 내용은 [Elastic Load Balancing 설명서](https://docs.aws.amazon.com/elasticloadbalancing/index.html)를 참조하세요.
+ CloudFront 배포를 생성할 때 오리진 서버의 도메인 이름으로 로드 밸런서의 URL을 지정합니다. 자세한 내용은 [배포 생성](distribution-web-creating-console.md) 섹션을 참조하세요.

## CloudFront 오리진 그룹 사용
<a name="concept_origin_groups"></a>

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

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

## Amazon API Gateway 사용
<a name="use-api-gate-way-origin"></a>

API Gateway를 CloudFront 배포의 사용자 지정 오리진으로 사용할 수 있습니다. 자세한 내용은 다음 항목을 참조하세요.
+ [Securing Amazon API Gateway with secure ciphers using Amazon CloudFront](https://aws.amazon.com/blogs/networking-and-content-delivery/securing-amazon-api-gateway-with-secure-ciphers-using-amazon-cloudfront/) AWS 블로그 게시물
+ [How do I set up API Gateway with my own CloudFront distribution?](https://repost.aws/knowledge-center/api-gateway-cloudfront-distribution) AWS re:Post 

# CloudFront 배포에 IPv6 활성화
<a name="cloudfront-enable-ipv6"></a>

Amazon CloudFront는 클라이언트에서 AWS 엣지 로케이션까지 IPv4와 IPv6를 모두 지원합니다. CloudFront는 오리진에 대한 IPv6 및 듀얼 스택(IPv4 및 IPv6) 연결도 지원합니다. 이를 통해 엔드 투 엔드 IPv6 전송을 달성할 수 있습니다.

IPv6는 IPv4를 대체하도록 설계된 차세대 인터넷 프로토콜입니다. IPv4는 32비트 주소(예: 192.0.2.44)를 사용하지만 IPv6는 128비트 주소(예: 2001:0db8:85a3::8a2e:0370:7334)를 사용합니다. IPv6는 더 많은 인터넷 연결 디바이스를 수용할 수 있도록 확장된 주소 공간을 제공합니다.

**Topics**
+ [IPv6 뷰어 요청](#ipv6-viewer-requests)
+ [IPv6 오리진 요청](#ipv6-origin-requests)

## IPv6 뷰어 요청
<a name="ipv6-viewer-requests"></a>

일반적으로, 콘텐츠를 액세스하려는 사용자 중에 IPv6 네트워크의 사용자가 있을 경우 IPv6를 사용하도록 설정해야 합니다. 하지만 서명된 URL이나 서명된 쿠키를 사용하여 콘텐츠에 대한 액세스를 제한하며, `IpAddress` 파라미터를 포함하는 사용자 지정 정책을 사용하여, 콘텐츠에 액세스할 수 있는 IP 주소를 제한하려는 경우에는 IPv6를 사용하도록 설정하지 마세요. 일부 콘텐츠에 대한 액세스를 IP 주소에 따라 제한하고, 다른 콘텐츠에 대한 액세스는 제한하지 않으려면(또는 액세스를 제한하되 IP 주소로 제한하지 않으려면), 두 개의 배포를 만들면 됩니다. 사용자 지정 정책을 사용하여 서명된 URL을 만드는 방법에 대한 자세한 내용은 [사용자 지정 정책을 사용하여 서명된 URL 생성](private-content-creating-signed-url-custom-policy.md)을 참조합니다. 사용자 지정 정책을 사용하여 서명된 쿠키를 만드는 방법에 대한 자세한 내용은 [사용자 지정 정책을 사용하여 서명된 쿠키 설정](private-content-setting-signed-cookie-custom-policy.md)을 참조합니다.

Route 53 별칭 리소스 레코드 세트를 사용하여 CloudFront 배포로 트래픽을 라우팅할 경우, 다음 조건이 모두 해당되면 두 번째 별칭 리소스 레코드 세트를 만들어야 합니다.
+ 배포에 대해 IPv6를 사용하도록 설정함
+ 객체의 URL에 대체 도메인 이름을 사용함

자세한 내용은 *Amazon Route 53 개발자 안내서*에서 [도메인 이름을 사용하여 Amazon CloudFront 배포로 트래픽 라우팅](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html)을 참조하세요.

Route 53 또는 다른 DNS 서비스를 사용하여 CNAME 리소스 레코드 세트를 만들었을 경우 아무것도 변경할 필요가 없습니다. CNAME 레코드는 최종 사용자 요청의 IP 주소 형식과 상관없이 배포로 트래픽을 라우팅합니다.

IPv6와 CloudFront 액세스 로그를 사용하도록 설정하면 `c-ip` 열에 IPv4 및 IPv6 형식의 값이 포함됩니다. 자세한 내용은 [로그 파일 필드](standard-logs-reference.md#BasicDistributionFileFormat) 섹션을 참조하세요.

**참고**  
IPv4가 더 우수한 사용자 경험을 제공할 것으로 추천될 경우 CloudFront는 고객에 대해 가용성을 높게 유지하기 위해 IPv4를 사용하여 최종 사용자 요청에 응답합니다. CloudFront가 IPv6를 통해 처리하는 요청의 비율을 확인하려면 배포에 대해 CloudFront 로그 기록을 활성화하여 `c-ip` 열을 구문 분석하세요. 이 열에는 요청을 한 최종 사용자의 IP 주소가 들어 있습니다. 이 비율은 갈수록 커지겠지만 아직 전 세계 모든 최종 사용자 네트워크에서 IPv6가 지원되지는 않으므로 트래픽에서 상대적으로 적은 부분을 차지할 것입니다. 일부 최종 사용자 네트워크는 IPv6를 완벽하게 지원하지만, IPv6를 전혀 지원하지 않는 최종 사용자 네트워크도 있습니다. 최종 사용자 네트워크는 가정용 인터넷이나 무선 통신업체와 유사합니다.  
IPv6에 대한 지원을 자세히 알아보려면 [CloudFront FAQ](https://aws.amazon.com/cloudfront/faqs/)를 참조하세요. 액세스 로그 활성화에 대한 자세한 내용은 [표준 로깅](DownloadDistValuesGeneral.md#DownloadDistValuesLoggingOnOff) 및 [로그 접두사](DownloadDistValuesGeneral.md#DownloadDistValuesLogPrefix) 필드를 참조하세요.

## IPv6 오리진 요청
<a name="ipv6-origin-requests"></a>

사용자 지정 오리진(Amazon S3 및 VPC 오리진 제외)을 사용하는 경우 배포의 오리진 설정을 사용자 지정하여 CloudFront가 IPv4 또는 IPv6 주소를 사용하여 오리진에 연결하는 방법을 선택할 수 있습니다. 사용자 지정 오리진(Amazon S3 및 VPC 오리진 제외)의 경우 다음과 같은 연결 옵션이 있습니다.
+ **IPv4 전용(기본값)** - CloudFront가 IPv4를 통해 오리진에 연결하는 데 사용하는 기본 구성입니다.
+ **IPv6 전용** - 오리진 도메인이 IPv6 주소로 확인되어야 합니다. CloudFront는 오리진 연결에 IPv6 주소만 사용합니다.
+ **듀얼 스택** - IPv4 및 IPv6를 통한 연결을 활성화합니다. CloudFront는 자동으로 IPv4 또는 IPv6 오리진 연결을 선택하여 성능과 가용성을 우선시하므로 CloudFront를 웹 애플리케이션의 IPv6 및 IPv4 듀얼 스택 인터넷 게이트웨이로 사용할 수 있습니다.

오리진의 네트워크 구성 및 연결 요구 사항에 맞는 옵션을 선택합니다. 자세한 내용은 [IPv6용 DNS 설계](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/designing-dns-for-ipv6.html) 및 [IPv6 보안 및 모니터링 고려 사항](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/ipv6-security-and-monitoring-considerations.html)을 참조하세요.

# CloudFront 지속적 배포를 사용하여 CDN 구성 변경을 안전하게 테스트
<a name="continuous-deployment"></a>

Amazon CloudFront *지속적 배포*를 사용하면 프로덕션 트래픽의 하위 집합으로 먼저 테스트하여 CDN 구성의 변경 사항을 안전하게 배포할 수 있습니다. *스테이징 배포*와 *지속적 배포 정책*을 사용하여 실제(프로덕션) 최종 사용자의 일부 트래픽을 새 CDN 구성으로 전송하고 예상대로 작동하는지 확인할 수 있습니다. 새 구성의 성능을 실시간으로 모니터링하고 준비가 되면 *기본 배포*를 통해 모든 트래픽을 처리하도록 새 구성을 승격할 수 있습니다.

다음 다이어그램은 CloudFront 지속적 배포를 사용할 경우의 이점을 보여 줍니다. 이 기능이 없으면 시뮬레이션된 트래픽으로 CDN 구성 변경을 테스트해야 합니다. 지속적 배포를 사용하면 프로덕션 트래픽의 하위 집합을 사용하여 변경 사항을 테스트한 다음 준비가 되면 기본 배포로 변경 사항을 승격할 수 있습니다.

![\[프로덕션 트래픽을 스테이징 배포로 보내는 CloudFront 연속 배포의 그림.\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/images/cloudfront-continuous-deployment.png)


다음 주제에서 지속적 배포 작업에 대해 자세히 알아봅니다.

**Topics**
+ [CloudFront 지속적 배포 워크플로](continuous-deployment-workflow.md)
+ [스테이징 배포 및 지속적 배포 정책 사용](working-with-staging-distribution-continuous-deployment-policy.md)
+ [스테이징 배포 모니터링](monitoring-staging-distribution.md)
+ [지속적 배포의 작동 방식 알아보기](understanding-continuous-deployment.md)
+ [지속적 배포를 위한 할당량 및 기타 고려 사항](continuous-deployment-quotas-considerations.md)

# CloudFront 지속적 배포 워크플로
<a name="continuous-deployment-workflow"></a>

다음 고급 워크플로는 CloudFront 지속적 배포를 통해 구성 변경을 안전하게 테스트하고 배포하는 방법을 설명합니다.

1. *기본 배포*로 사용할 배포를 선택합니다. 기본 배포는 현재 프로덕션 트래픽을 제공하는 배포입니다.

1. 기본 배포에서 *스테이징 배포*를 생성합니다. 스테이징 배포는 기본 배포의 복사본으로 시작됩니다.

1. *지속적 배포 정책* 내에서 *트래픽 구성*을 생성하고 이를 기본 배포에 연결합니다. 이에 따라 CloudFront가 스테이징 배포로 트래픽을 라우팅하는 방식이 결정됩니다. 요청을 스테이징 배포로 라우팅하는 방법에 대한 자세한 내용은 [요청을 스테이징 배포로 라우팅](understanding-continuous-deployment.md#understanding-continuous-deployment-routing)을 참조하십시오.

1. 스테이징 배포의 구성을 업데이트합니다. 업데이트할 수 있는 설정에 대한 자세한 내용은 [기본 및 스테이징 배포 업데이트](understanding-continuous-deployment.md#updating-staging-and-primary-distributions)를 참조하십시오.

1. 스테이징 배포를 모니터링하여 구성 변경이 예상대로 수행되는지 확인합니다. 스테이징 배포를 모니터링하는 방법에 대한 자세한 내용은 [스테이징 배포 모니터링](monitoring-staging-distribution.md)을 참조하십시오.

   스테이징 배포를 모니터링하면서 다음을 수행할 수 있습니다.
   + 스테이징 배포의 구성을 다시 업데이트하여 구성 변경을 계속 테스트합니다.
   + 연속 배포 정책(트래픽 구성)을 업데이트하여 스테이징 배포에 더 많은 트래픽을 보내거나 더 적게 보냅니다.

1. 스테이징 배포의 성능이 만족스러우면 스테이징 배포의 구성을 기본 배포로 *승격합니다*. 그러면 스테이징 배포의 구성이 기본 배포에 복사됩니다. 이렇게 하면 지속적 배포 정책도 비활성화되므로 CloudFront는 모든 트래픽을 기본 배포로 라우팅합니다.

스테이징 배포의 성능을 모니터링(5단계)하고 특정 기준이 충족되면 구성을 자동으로 승격(6단계)하는 자동화를 구축할 수 있습니다.

구성을 승격시킨 후 다음에 구성 변경을 테스트할 때 동일한 스테이징 배포를 재사용할 수 있습니다.

CloudFront 콘솔, AWS CLI 또는 CloudFront API에서 스테이징 배포 및 지속적 배포 정책을 사용하는 방법에 대한 자세한 내용은 다음 섹션을 참조하십시오.

# 스테이징 배포 및 지속적 배포 정책 사용
<a name="working-with-staging-distribution-continuous-deployment-policy"></a>

AWS Command Line Interface(AWS CLI) 또는 CloudFront API를 사용하여 CloudFront 콘솔에서 스테이징 배포와 지속적 배포 정책을 생성, 업데이트 및 수정할 수 있습니다.

## 스테이징 배포 및 지속적 배포 정책 생성
<a name="create-staging-distribution-continuous-deployment-policy"></a>

다음 절차에서는 스테이징 배포 및 지속적 배포 정책을 생성하는 방법을 보여 줍니다.

------
#### [ Console ]

AWS Management Console을 사용하여 스테이징 배포 및 지속적 배포 정책을 생성할 수 있습니다.

**스테이징 배포 및 연속 배포 정책 생성(콘솔)**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 탐색 창에서 **Distributions(배포)**를 선택합니다.

1. *기본 배포*로 사용할 배포를 선택합니다. 기본 배포는 현재 프로덕션 트래픽을 제공하는 배포이며, 여기서 스테이징 배포를 만들게 됩니다.

1. **Continuous deployment**(지속적 배포) 섹션에서 **Create staging distribution**(스테이징 배포 생성)을 선택합니다. 그러면 **Create staging distribution**(스테이징 배포 생성) 마법사가 열립니다.

1. **Create staging distribution**(스테이징 배포 생성) 마법사에서 다음을 수행합니다.

   1. (선택 사항) 스테이징 배포에 대한 설명을 입력합니다.

   1. **다음**을 선택합니다.

   1. 스테이징 배포의 구성을 수정합니다. 업데이트할 수 있는 설정에 대한 자세한 내용은 [기본 및 스테이징 배포 업데이트](understanding-continuous-deployment.md#updating-staging-and-primary-distributions)를 참조하십시오.

      스테이징 배포의 구성 수정을 마치면 **Next**(다음)을 선택합니다.

   1. 콘솔을 사용하여 **Traffic configuration**(트래픽 구성)을 지정합니다. 이에 따라 CloudFront가 스테이징 배포로 트래픽을 라우팅하는 방식이 결정됩니다. (CloudFront는 트래픽 구성을 *지속적 배포 정책*에 저장합니다.)

      **트래픽 구성** 옵션에 대한 자세한 내용은 [요청을 스테이징 배포로 라우팅](understanding-continuous-deployment.md#understanding-continuous-deployment-routing)을 참조하세요.

      **Traffic configuration**(트래픽 구성)을 완료했으면 **Next**(다음)을 선택합니다.

   1. 트래픽 구성을 포함하여 스테이징 배포에 대한 구성을 검토한 다음 **Create staging distribution**(스테이징 배포 생성)을 선택합니다.

CloudFront 콘솔에서 **Create staging distribution**(스테이징 배포 생성) 마법사를 완료하면 CloudFront는 다음을 수행합니다.
+ 지정한 설정을 사용하여 스테이징 배포를 만듭니다(5c 단계).
+ 지정한 트래픽 구성을 사용하여 지속적 배포 정책을 생성합니다(5d단계).
+ 스테이징 배포를 만들 때 바탕이 된 기본 배포에 지속적 배포 정책을 연결합니다.

기본 배포의 구성이 연결된 지속적 배포 정책을 사용하여 엣지 로케이션에 배포되면 CloudFront는 트래픽 구성을 기반으로 지정된 트래픽 부분을 스테이징 배포로 전송하기 시작합니다.

------
#### [ CLI ]

AWS CLI에서 스테이징 배포와 지속적 배포 정책을 생성하려면 다음 절차를 사용합니다.

**스테이징 배포 생성(CLI)**

1. **aws cloudfront get-distribution** 및 **grep** 명령을 함께 사용하면 *기본 배포*로 사용할 배포의 `ETag` 값을 얻을 수 있습니다. 기본 배포는 현재 프로덕션 트래픽을 제공하는 배포이며, 여기서 스테이징 배포를 만들게 됩니다.

   다음 명령은 예시를 나타냅니다. 다음 예에서는 *primary\$1distribution\$1ID*를 기본 배포의 ID로 바꿉니다.

   ```
   aws cloudfront get-distribution --id primary_distribution_ID | grep 'ETag'
   ```

   다음 단계에 필요하므로 `ETag` 값을 복사하십시오.

1. **aws cloudfront copy-distribution** 명령을 사용하여 스테이징 배포를 만들 수 있습니다. 다음 예제 명령에서는 가독성을 높이기 위해 이스케이프 문자(\$1)와 줄 바꿈을 사용하지만 실제 명령에서는 이러한 문자를 생략해야 합니다. 이 예에서 다음과 같이 합니다.
   + *primary\$1distribution\$1ID*를 기본 배포의 ID로 바꿉니다.
   + *primary\$1distribution\$1ETag*를 기본 배포의 `ETag` 값(이전 단계에서 가져온 값)으로 바꿉니다.
   + (선택 사항) *CLI\$1example*을 원하는 호출자 참조 ID로 바꿉니다.

   ```
   aws cloudfront copy-distribution --primary-distribution-id primary_distribution_ID \
                                    --if-match primary_distribution_ETag \
                                    --staging \
                                    --caller-reference 'CLI_example'
   ```

   명령의 출력에는 스테이징 배포와 해당 구성에 대한 정보가 표시됩니다. 스테이징 배포의 CloudFront 도메인 이름은 다음 단계에 필요하므로 복사합니다.

**지속적 배포 정책 생성(입력 파일이 있는 CLI)**

1. 다음 명령을 사용하여 `continuous-deployment-policy.yaml` 명령에 대한 모든 입력 파라미터가 포함된 **create-continuous-deployment-policy**이라는 파일을 만듭니다. 다음 명령에서는 가독성을 높이기 위해 이스케이프 문자(\$1)와 줄 바꿈을 사용하지만 실제 명령에서는 이러한 문자를 생략해야 합니다.

   ```
   aws cloudfront create-continuous-deployment-policy --generate-cli-skeleton yaml-input \
                                                      > continuous-deployment-policy.yaml
   ```

1. 방금 생성한 `continuous-deployment-policy.yaml`이라는 파일을 엽니다. 파일을 편집하여 원하는 지속적 배포 정책 설정을 지정한 다음 파일을 저장합니다. 파일을 편집할 때:
   + `StagingDistributionDnsNames` 섹션:
     + `Quantity`의 값을 `1`로 변경합니다.
     + `Items`의 경우 스테이징 배포의 CloudFront 도메인 이름(이전 단계에서 저장한 이름)을 붙여 넣습니다.
   + `TrafficConfig` 섹션:
     + `Type`을 `SingleWeight` 또는 `SingleHeader`로 선택합니다.
     + 다른 유형에 대한 설정을 제거합니다. 예를 들어, 가중치 기반 트래픽 구성을 원하는 경우 `Type`을 `SingleWeight`로 설정한 다음 `SingleHeaderConfig` 설정을 제거합니다.
     + 가중치 기반 트래픽 구성을 사용하려면 `Weight`의 값을 `.01`(1%) 에서 `.15`(15%) 사이의 10진수로 설정합니다.

     `TrafficConfig`의 이러한 옵션에 대한 자세한 내용은 [요청을 스테이징 배포로 라우팅](understanding-continuous-deployment.md#understanding-continuous-deployment-routing) 및 [가중치 기반 구성을 위한 세션 고정성](understanding-continuous-deployment.md#understanding-continuous-deployment-sessions)을 참조하세요.

1. 다음 명령을 사용하여 `continuous-deployment-policy.yaml` 파일의 입력 파라미터로 지속적 배포 정책을 만듭니다.

   ```
   aws cloudfront create-continuous-deployment-policy --cli-input-yaml file://continuous-deployment-policy.yaml
   ```

   명령 출력의 `Id` 값을 복사합니다. 이는 지속적 배포 정책 ID이며 다음 단계에서 필요합니다.

**기본 배포에 지속적 배포 정책 연결(입력 파일이 있는 CLI)**

1. 다음 명령을 사용하여 기본 배포에 대한 구성을 이름이 `primary-distribution.yaml`인 파일에 저장합니다. *primary\$1distribution\$1ID*를 기본 배포의 ID로 바꿉니다.

   ```
   aws cloudfront get-distribution-config --id primary_distribution_ID --output yaml > primary-distribution.yaml
   ```

1. 방금 생성한 `primary-distribution.yaml`이라는 파일을 엽니다. 파일을 편집하여 다음과 같이 변경합니다.
   + 지속적 배포 정책 ID(이전 단계에서 복사한 ID)를 `ContinuousDeploymentPolicyId` 필드에 붙여 넣습니다.
   + `ETag` 필드의 이름을 `IfMatch`로 바꾸지만 필드 값은 변경하지 마세요.

   완료되면 파일을 저장합니다.

1. 지속적 배포 정책을 사용하도록 기본 배포를 업데이트하려면 다음 명령을 사용합니다. *primary\$1distribution\$1ID*를 기본 배포의 ID로 바꿉니다.

   ```
   aws cloudfront update-distribution --id primary_distribution_ID --cli-input-yaml file://primary-distribution.yaml
   ```

기본 배포의 구성이 연결된 지속적 배포 정책을 사용하여 엣지 로케이션에 배포되면 CloudFront는 트래픽 구성을 기반으로 지정된 트래픽 부분을 스테이징 배포로 전송하기 시작합니다.

------
#### [ API ]

CloudFront API를 사용하여 스테이징 배포 및 지속적 배포 정책을 생성하려면 다음 API 작업을 사용합니다.
+ [CopyDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CopyDistribution.html)
+ [CreateContinuousDeploymentPolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateContinuousDeploymentPolicy.html)

이러한 API 호출에서 지정하는 필드에 대한 자세한 내용은 다음을 참조하세요.
+ [요청을 스테이징 배포로 라우팅](understanding-continuous-deployment.md#understanding-continuous-deployment-routing)
+ [가중치 기반 구성을 위한 세션 고정성](understanding-continuous-deployment.md#understanding-continuous-deployment-sessions)
+ AWS SDK 또는 기타 API 클라이언트에 대한 API 참조 설명서

스테이징 배포와 지속적 배포 정책을 만든 후에는 [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)(기본 배포에서)을 사용하여 지속적 배포 정책을 기본 배포에 연결합니다.

------

## 스테이징 배포 업데이트
<a name="update-staging-distribution"></a>

다음 절차에서는 스테이징 배포 및 지속적 배포 정책을 업데이트하는 방법을 보여 줍니다.

------
#### [ Console ]

기본 배포와 스테이징 배포 모두에 대해 특정 구성을 업데이트할 수 있습니다. 자세한 내용은 [기본 및 스테이징 배포 업데이트](understanding-continuous-deployment.md#updating-staging-and-primary-distributions) 섹션을 참조하세요.

**스테이징 배포 업데이트(콘솔)**

1. [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 탐색 창에서 **Distributions(배포)**를 선택합니다.

1. 기본 배포를 선택합니다. 현재 프로덕션 트래픽을 제공하는 배포이며, 여기서 스테이징 배포를 만들게 됩니다.

1. **View staging distribution**(스테이징 배포 보기)를 선택합니다.

1. 콘솔을 사용하여 스테이징 배포의 구성을 수정합니다. 업데이트할 수 있는 설정에 대한 자세한 내용은 [기본 및 스테이징 배포 업데이트](understanding-continuous-deployment.md#updating-staging-and-primary-distributions)를 참조하십시오.

스테이징 배포의 구성이 엣지 로케이션에 배포되는 즉시 스테이징 배포로 라우팅되는 수신 트래픽에 적용됩니다.

------
#### [ CLI ]

**스테이징 배포 업데이트(입력 파일이 있는 CLI)**

1. 다음 명령을 사용하여 스테이징 배포에 대한 구성을 이름이 `staging-distribution.yaml`인 파일에 저장합니다. *staging\$1distribution\$1ID*를 스테이징 배포 ID로 바꿉니다.

   ```
   aws cloudfront get-distribution-config --id staging_distribution_ID --output yaml > staging-distribution.yaml
   ```

1. 방금 생성한 `staging-distribution.yaml`이라는 파일을 엽니다. 파일을 편집하여 다음과 같이 변경합니다.
   + 스테이징 배포의 구성을 수정합니다. 업데이트할 수 있는 설정에 대한 자세한 내용은 [기본 및 스테이징 배포 업데이트](understanding-continuous-deployment.md#updating-staging-and-primary-distributions)를 참조하십시오.
   + `ETag` 필드의 이름을 `IfMatch`로 바꾸지만 필드 값은 변경하지 마세요.

   완료되면 파일을 저장합니다.

1. 다음 명령을 사용하여 스테이징 배포의 구성을 업데이트합니다. *staging\$1distribution\$1ID*를 스테이징 배포 ID로 바꿉니다.

   ```
   aws cloudfront update-distribution --id staging_distribution_ID --cli-input-yaml file://staging-distribution.yaml
   ```

스테이징 배포의 구성이 엣지 로케이션에 배포되는 즉시 스테이징 배포로 라우팅되는 수신 트래픽에 적용됩니다.

------
#### [ API ]

스테이징 배포의 구성을 업데이트하려면 [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)(스테이징 배포에서)을 사용하여 스테이징 배포의 구성을 수정합니다. 업데이트할 수 있는 설정에 대한 자세한 내용은 [기본 및 스테이징 배포 업데이트](understanding-continuous-deployment.md#updating-staging-and-primary-distributions)를 참조하십시오.

------

## 지속적 배포 정책 업데이트
<a name="update-continuous-deployment-policy"></a>

다음 절차에서는 지속적 배포 정책을 업데이트하는 방법을 보여 줍니다.

------
#### [ Console ]

지속적 배포 정책을 업데이트하여 배포의 트래픽 구성을 업데이트할 수 있습니다.

**지속적 배포 정책 업데이트(콘솔)**

1. [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 탐색 창에서 **Distributions(배포)**를 선택합니다.

1. 기본 배포를 선택합니다. 현재 프로덕션 트래픽을 제공하는 배포로, 스테이징 배포를 만들 때 바탕이 된 배포입니다.

1. **Continuous deployment**(지속적 배포) 섹션에서 **Edit policy**(정책 편집)을 선택합니다.

1. 지속적 배포 정책에서 트래픽 구성을 수정합니다. 작업을 마쳤으면 **변경 사항 저장**을 선택합니다.

기본 배포의 구성이 업데이트된 지속적 배포 정책을 사용하여 엣지 로케이션에 배포되면 CloudFront는 업데이트된 트래픽 구성을 기반으로 지정된 트래픽 부분을 스테이징 배포로 전송하기 시작합니다.

------
#### [ CLI ]

**지속적 배포 정책 업데이트(입력 파일이 있는 CLI)**

1. 다음 명령을 사용하여 지속적 배포 정책의 구성을 이름이 `continuous-deployment-policy.yaml`인 파일로 저장합니다. *continuous\$1deployment\$1policy\$1ID*를 지속적 배포 정책의 ID로 바꾸십시오. 다음 명령에서는 가독성을 높이기 위해 이스케이프 문자(\$1)와 줄 바꿈을 사용하지만 실제 명령에서는 이러한 문자를 생략해야 합니다.

   ```
   aws cloudfront get-continuous-deployment-policy-config --id continuous_deployment_policy_ID \
                                                          --output yaml > continuous-deployment-policy.yaml
   ```

1. 방금 생성한 `continuous-deployment-policy.yaml`이라는 파일을 엽니다. 파일을 편집하여 다음과 같이 변경합니다.
   + 지속적 배포 정책에서 구성을 원하는 대로 수정합니다. 예를 들어 헤더 기반 트래픽 구성에서 가중치 기반 트래픽 구성으로 변경하거나 가중치 기반 구성의 트래픽 비율(가중치)을 변경할 수 있습니다. 자세한 내용은 [요청을 스테이징 배포로 라우팅](understanding-continuous-deployment.md#understanding-continuous-deployment-routing) 및 [가중치 기반 구성을 위한 세션 고정성](understanding-continuous-deployment.md#understanding-continuous-deployment-sessions)(을)를 참조하세요.
   + `ETag` 필드의 이름을 `IfMatch`로 바꾸지만 필드 값은 변경하지 마세요.

   완료되면 파일을 저장합니다.

1. 지속적 배포 정책을 업데이트하려면 다음 명령을 사용합니다. *continuous\$1deployment\$1policy\$1ID*를 지속적 배포 정책의 ID로 바꾸십시오. 다음 명령에서는 가독성을 높이기 위해 이스케이프 문자(\$1)와 줄 바꿈을 사용하지만 실제 명령에서는 이러한 문자를 생략해야 합니다.

   ```
   aws cloudfront update-continuous-deployment-policy --id continuous_deployment_policy_ID \
                                                      --cli-input-yaml file://continuous-deployment-policy.yaml
   ```

기본 배포의 구성이 업데이트된 지속적 배포 정책을 사용하여 엣지 로케이션에 배포되면 CloudFront는 업데이트된 트래픽 구성을 기반으로 지정된 트래픽 부분을 스테이징 배포로 전송하기 시작합니다.

------
#### [ API ]

지속적 배포 정책을 업데이트하려면 [UpdateContinuousDeploymentPolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateContinuousDeploymentPolicy.html)를 사용합니다.

------

## 스테이징 배포 구성 승격
<a name="promote-staging-distribution-configuration"></a>

다음 절차에서는 스테이징 배포 구성을 승격하는 방법을 보여 줍니다.

------
#### [ Console ]

스테이징 배포를 *승격*하면 CloudFront는 스테이징 배포의 구성을 기본 배포로 복사합니다. CloudFront는 지속적 배포 정책도 비활성화하며 모든 트래픽을 기본 배포로 라우팅합니다.

구성을 승격시킨 후 다음에 구성 변경을 테스트할 때 동일한 스테이징 배포를 재사용할 수 있습니다.

**스테이징 배포의 구성 승격(콘솔)**

1. [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 탐색 창에서 **Distributions(배포)**를 선택합니다.

1. 기본 배포를 선택합니다. 현재 프로덕션 트래픽을 제공하는 배포로, 스테이징 배포를 만들 때 바탕이 된 배포입니다.

1. **지속적 배포** 섹션에서 **승격**을 선택합니다.

1. **confirm**을 입력한 다음 **Promote**(승격)을 선택합니다.

------
#### [ CLI ]

스테이징 배포를 *승격*하면 CloudFront는 스테이징 배포의 구성을 기본 배포로 복사합니다. CloudFront는 지속적 배포 정책도 비활성화하며 모든 트래픽을 기본 배포로 라우팅합니다.

구성을 승격시킨 후 다음에 구성 변경을 테스트할 때 동일한 스테이징 배포를 재사용할 수 있습니다.

**스테이징 배포의 구성 승격(CLI)**
+ **aws cloudfront update-distribution-with-staging-config** 명령을 사용하여 스테이징 배포의 구성을 기본 배포로 승격시킵니다. 다음 예제 명령에서는 가독성을 높이기 위해 이스케이프 문자(\$1)와 줄 바꿈을 사용하지만 실제 명령에서는 이러한 문자를 생략해야 합니다. 이 예에서 다음과 같이 합니다.
  + *primary\$1distribution\$1ID*를 기본 배포의 ID로 바꿉니다.
  + *staging\$1distribution\$1ID*를 스테이징 배포 ID로 바꿉니다.
  + *primary\$1distribution\$1ETag* 및 *staging\$1distribution\$1ETag*를 기본 및 스테이징 배포의 `ETag` 값으로 바꿉니다. 예와 같이 기본 분포의 값이 첫 번째인지 확인하십시오.

  ```
  aws cloudfront update-distribution-with-staging-config --id primary_distribution_ID \
                                                         --staging-distribution-id staging_distribution_ID \
                                                         --if-match 'primary_distribution_ETag,staging_distribution_ETag'
  ```

------
#### [ API ]

스테이징 배포의 구성을 기본 배포로 승격시키려면 [UpdateDistributionWithStagingConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistributionWithStagingConfig.html)를 사용합니다.

------

# 스테이징 배포 모니터링
<a name="monitoring-staging-distribution"></a>

스테이징 배포의 성능을 모니터링하려면 CloudFront에서 모든 배포에 제공하는 것과 동일한 [지표, 로그 및 보고서](reports-and-monitoring.md)를 사용할 수 있습니다. 예제:
+ CloudFront 콘솔에서 [기본 CloudFront 배포 지표](viewing-cloudfront-metrics.md#monitoring-console.distributions)(예: 총 요청 수 및 오류율)를 볼 수 있으며 추가 비용을 지불하고 [추가 지표](viewing-cloudfront-metrics.md#monitoring-console.distributions-additional)(예: 캐시 적중률 및 상태 코드별 오류 발생률)를 설정할 수 있습니다. 이러한 지표를 기반으로 경보를 생성할 수도 있습니다.
+ [표준 로그](AccessLogs.md)와 [실시간 액세스 로그](real-time-logs.md)를 보고 스테이징 배포에서 받은 요청에 대한 자세한 정보를 얻을 수 있습니다. 표준 로그에는 CloudFront가 스테이징 배포로 요청을 라우팅하기 전에 요청이 원래 전송된 기본 배포를 식별하는 데 도움이 되는 두 필드 `primary-distribution-id` 및 `primary-distribution-dns-name`이 있습니다.
+ CloudFront 콘솔에서 [보고서](reports.md)(예: 캐시 통계 보고서)를 보고 다운로드할 수 있습니다.

# 지속적 배포의 작동 방식 알아보기
<a name="understanding-continuous-deployment"></a>

다음 주제에서는 CloudFront 지속적 배포의 작동 방식을 설명합니다.

**Topics**
+ [요청을 스테이징 배포로 라우팅](#understanding-continuous-deployment-routing)
+ [가중치 기반 구성을 위한 세션 고정성](#understanding-continuous-deployment-sessions)
+ [기본 및 스테이징 배포 업데이트](#updating-staging-and-primary-distributions)
+ [캐시를 공유하지 않는 기본 배포와 스테이징 배포](#staging-and-primary-no-shared-cache)

## 요청을 스테이징 배포로 라우팅
<a name="understanding-continuous-deployment-routing"></a>

CloudFront 지속적 배포를 사용할 경우 최종 사용자 요청에 대한 내용을 변경할 필요가 없습니다. 최종 사용자는 DNS 이름, IP 주소 또는 CNAME을 사용하여 스테이징 배포에 직접 요청을 보낼 수 없습니다. 대신 최종 사용자는 기본 (프로덕션) 배포에 요청을 보내고 CloudFront는 지속적 배포 정책의 트래픽 구성 설정에 따라 이러한 요청 중 일부를 스테이징 배포로 라우팅합니다. 다음과 같은 두 가지 유형의 트래픽 구성이 있습니다.

**가중치 기반**  
가중치 기반 구성은 지정된 비율의 최종 사용자 요청을 스테이징 배포로 라우팅합니다. 가중치 기반 구성을 사용하는 경우 *세션 고정성*을 활성화하여 CloudFront가 동일한 사용자의 요청을 단일 세션의 일부로 처리하도록 할 수도 있습니다. 자세한 내용은 [가중치 기반 구성을 위한 세션 고정성](#understanding-continuous-deployment-sessions) 섹션을 참조하세요.

**헤더 기반**  
헤더 기반 구성은 최종 사용자 요청에 특정 HTTP 헤더(헤더 및 값 지정)가 포함된 경우 요청을 스테이징 배포로 라우팅합니다. 지정된 헤더와 값을 포함하지 않는 요청은 기본 배포로 라우팅됩니다. 이 구성은 로컬 테스트나 최종 사용자 요청을 제어할 수 있는 경우에 유용합니다.  
스테이징 배포로 라우팅되는 헤더에는 `aws-cf-cd-` 접두사가 포함되어야 합니다.

## 가중치 기반 구성을 위한 세션 고정성
<a name="understanding-continuous-deployment-sessions"></a>

트래픽을 스테이징 배포로 라우팅하기 위해 가중치 기반 구성을 사용하는 경우 *세션 고정성*을 활성화하여 CloudFront가 동일한 사용자의 요청을 단일 세션의 일부로 처리하도록 할 수도 있습니다. 세션 고정성을 활성화하면 CloudFront는 쿠키를 설정하여 단일 세션에서 동일한 사용자의 모든 요청이 기본 배포든 스테이징이든 하나의 배포에서 처리되도록 합니다.

세션 고정성을 활성화하면 *유휴 기간*도 지정할 수 있습니다. 이 시간 동안 사용자가 유휴 상태(요청을 보내지 않음)인 경우 세션이 만료되고 CloudFront는 이 사용자의 향후 요청을 새 세션으로 취급합니다. 유휴 지속 시간을 300(5분)에서 3600(1시간) 사이의 초 수로 지정합니다.

다음과 같은 경우 CloudFront는 모든 세션(활성 세션 포함)을 재설정하고 모든 요청을 새 세션으로 간주합니다.
+ 지속적 배포 정책 활성화 또는 비활성화
+ 세션 고정성 설정 활성화 또는 비활성화

## 기본 및 스테이징 배포 업데이트
<a name="updating-staging-and-primary-distributions"></a>

기본 배포에 연속 배포 정책이 연결된 경우 기본 배포와 스테이징 배포 모두에 대해 다음과 같은 구성 변경을 사용할 수 있습니다.
+ 기본 캐시 동작을 포함한 모든 캐시 동작 설정
+ 모든 오리진 설정(오리진 및 오리진 그룹)
+ 사용자 지정 오류 응답(오류 페이지)
+ 지리적 제한
+ 기본 루트 객체
+ 로깅 설정
+ 설명(댓글)

또한 캐시 정책, 응답 헤더 정책, CloudFront 함수 또는 Lambda@Edge 함수와 같이 배포 구성에서 참조되는 외부 리소스를 업데이트할 수 있습니다.

## 캐시를 공유하지 않는 기본 배포와 스테이징 배포
<a name="staging-and-primary-no-shared-cache"></a>

기본 배포와 스테이징 배포는 캐시를 공유하지 않습니다. CloudFront가 스테이징 배포에 첫 번째 요청을 보낼 때 해당 캐시는 비어 있습니다. 요청이 스테이징 배포에 도착하면 응답 캐싱을 시작합니다(그렇게 하도록 구성된 경우).

# 지속적 배포를 위한 할당량 및 기타 고려 사항
<a name="continuous-deployment-quotas-considerations"></a>

CloudFront 지속적 배포에는 다음 할당량 및 기타 고려 사항이 적용됩니다.

## 할당량
<a name="continuous-deployment-quotas"></a>
+ AWS 계정당 최대 스테이징 배포 수: 20
+ AWS 계정당 최대 지속적 배포 정책 수: 20
+ 가중치 기반 구성에서 스테이징 배포로 보낼 수 있는 최대 트래픽 비율: 15%
+ 세션 고정 유휴 기간의 최소값 및 최대값: 300\$13600초

자세한 내용은 [할당량](cloudfront-limits.md) 섹션을 참조하세요.

**참고**  
지속적 배포를 사용하고 기본 배포가 S3 버킷 액세스를 위한 OAC로 설정된 경우 스테이징 배포에 대한 액세스를 허용하도록 S3 버킷 정책을 업데이트합니다. 예제 S3 버킷 정책은 [CloudFront에 S3 버킷에 액세스할 수 있는 권한 부여](private-content-restricting-access-to-s3.md#oac-permission-to-access-s3) 섹션을 참조합니다.

## AWS WAF 웹 ACL
<a name="waf-web-acl"></a>

배포에 지속적 배포를 활성화하는 경우 다음 고려 사항이 AWS WAF에 적용됩니다.
+ ACL이 배포와 처음 연결된 경우 배포에 AWS WAF 웹 액세스 제어 목록(ACL)을 연결할 수 없습니다.
+ 배포에서 AWS WAF 웹 ACL을 연결 해제할 수 없습니다.

위의 작업을 수행하려면 먼저 프로덕션 배포에 대한 지속적 배포 정책을 삭제해야 합니다. 이렇게 하면 스테이징 배포의 구성도 업데이트됩니다. 자세한 내용은 [AWS WAF 보호 사용](distribution-web-awswaf.md) 섹션을 참조하세요.

## CloudFront가 모든 요청을 기본 배포로 보내는 경우
<a name="all-requests-to-primary-distribution"></a>

리소스 사용률이 높은 기간과 같은 특정 상황에서는 지속적 배포 정책에 지정된 내용에 관계없이 CloudFront가 모든 요청을 기본 배포로 보낼 수 있습니다.

CloudFront는 지속적 배포 정책에 지정된 내용에 관계없이 트래픽이 가장 많은 시간대에 기본 배포에 모든 요청을 보냅니다. 최대 트래픽은 배포의 트래픽이 아니라 CloudFront 서비스의 트래픽을 나타냅니다.**

## HTTP/3
<a name="continuous-deployment-http3"></a>

HTTP/3을 지원하는 배포에서는 지속적 배포를 사용할 수 없습니다.

# 대체 도메인 이름(CNAME)을 추가하여 사용자 지정 URL 사용
<a name="CNAMEs"></a>

배포를 만들 때 CloudFront가 배포에 도메인 이름을 제공합니다(예: d111111abcdef8.cloudfront.net). 제공된 이 도메인 이름을 사용하는 대신 대체 도메인 이름(CNAME이라고도 함)을 사용할 수 있습니다.

www.example.com과 같은 고유한 도메인 이름을 사용하는 방법은 다음 주제를 참조하세요.

**Topics**
+ [대체 도메인 이름 사용과 관련된 요구 사항](#alternate-domain-names-requirements)
+ [대체 도메인 이름 사용에 대한 제한](#alternate-domain-names-restrictions)
+ [대체 도메인 이름 사용](CreatingCNAME.md)
+ [대체 도메인 이름 이동](alternate-domain-names-move.md)
+ [대체 도메인 이름 제거](alternate-domain-names-remove-domain.md)
+ [대체 도메인 이름에서 와일드카드 사용](alternate-domain-names-wildcard.md)

## 대체 도메인 이름 사용과 관련된 요구 사항
<a name="alternate-domain-names-requirements"></a>

CloudFront 배포에 www.example.com과 같은 대체 도메인 이름을 추가하는 경우 요구 사항은 다음과 같습니다.

**대체 도메인 이름은 소문자여야 합니다.**  
모든 대체 도메인 이름(CNAME)은 소문자여야 합니다.

**대체 도메인 이름은 유효한 TLS 인증서에 포함되어야 합니다.**  
CloudFront 배포에 대체 도메인 이름(CNAME)을 추가하려면 대체 도메인 이름이 포함된 신뢰할 수 있는 유효한 TLS 인증서를 배포에 연결해야 합니다. 그러면 도메인의 인증서에 대한 액세스 권한이 있는 사람만 해당 도메인과 관련된 CloudFront CNAME과 연결할 수 있습니다.  
신뢰할 수 있는 인증서는 AWS Certificate Manager(ACM) 또는 다른 유효한 CA(인증 기관)에서 발급하는 인증서입니다. 자체 서명된 인증서를 사용하여 기존 CNAME의 유효성을 검사할 수 있지만 새 CNAME의 유효성은 확인할 수 없습니다**. CloudFront는 Mozilla가 지원하는 것과 동일한 인증 기관을 지원합니다. 최신 목록은 [Mozilla에 포함된 CA 인증서 목록](https://wiki.mozilla.org/CA/Included_Certificates)을 참조하십시오. 서드 파티 CA 사용 시 중간 인증서에 대한 자세한 내용은 [중간 인증서](cnames-and-https-requirements.md#https-requirements-intermediate-certificates) 섹션을 참조하시기 바랍니다.  
연결한 인증서를 사용하여 와일드카드가 포함된 대체 도메인 이름 등의 대체 도메인 이름을 확인하기 위해 CloudFront는 인증서에서 주제 대체 이름(SAN)을 확인합니다. 추가하는 대체 도메인 이름은 SAN에 포함되어야 합니다.  
한 번에 인증서 하나만 CloudFront 배포에 연결할 수 있습니다.
다음 중 하나를 수행하여 배포에 특정 대체 도메인 이름을 추가할 권한을 입증합니다.  
+ 대체 도메인 이름(예: product-name.example.com)이 포함된 인증서 연결.
+ 도메인 이름의 시작 부분에 \$1 와일드카드가 포함된 인증서를 추가하여 인증서 하나로 여러 하위 도메인 포괄. 와일드카드를 지정할 때 CloudFront에서 여러 하위 도메인을 대체 도메인 이름으로 추가할 수 있습니다.
다음 예에서는 인증서 작업에서 도메인 이름에 와일드카드를 사용하여 CloudFront에서 특정 대체 도메인 이름을 추가할 수 있는 권한을 부여하는 보여 줍니다.  
+ marketing.example.com을 대체 도메인 이름으로 추가하려고 합니다. 인증서에 도메인 이름(\$1.example.com)을 나열합니다. CloudFront에 이 인증서를 연결할 때 해당 수준에서 와일드카드를 대체하는 배포의 대체 도메인 이름을 추가할 수 있습니다(예: marketing.example.com). 또한 예를 들어 다음과 같은 대체 도메인 이름을 추가할 수도 있습니다.
  + product.example.com
  + api.example.com

  그러나 와일드카드보다 높거나 낮은 수준의 대체 도메인 이름은 추가할 수 없습니다. 예를 들어 example.com 또는 marketing.product.example.com은 대체 도메인 이름으로 추가할 수 없습니다.
+ example.com을 대체 도메인 이름으로 추가하려고 합니다. 이를 수행하려면 배포에 연결하는 인증서에서 도메인 이름 example.com 자체를 나열해야 합니다.
+ marketing.product.example.com을 대체 도메인 이름으로 추가하려고 합니다. 이를 수행하려면 인증서에 \$1.product.example.com을 나열하거나, 인증서에 marketing.product.example.com 자체를 나열하면 됩니다.

**DNS 구성 변경 권한**  
대체 도메인 이름을 추가하는 경우, CNAME 레코드를 생성하여 대체 도메인 이름에 대한 DNS 쿼리를 CloudFront 배포에 라우팅해야 합니다. 이를 수행하려면 사용 중인 대체 도메인 이름의 DNS 서비스 공급자를 통해 CNAME 레코드를 생성할 수 있는 권한이 있어야 합니다. 일반적으로 이 경우 도메인을 소유하고 있지만 도메인 소유자를 위해 애플리케이션을 개발하는 중일 수도 있습니다.

**대체 도메인 이름과 HTTPS**  
최종 사용자가 대체 도메인 이름과 함께 HTTPS를 사용하도록 하려면 추가 구성을 수행해야 합니다. 자세한 내용은 [대체 도메인 이름과 HTTPS 사용](using-https-alternate-domain-names.md) 단원을 참조합니다.

## 대체 도메인 이름 사용에 대한 제한
<a name="alternate-domain-names-restrictions"></a>

대체 도메인 이름 사용에 대한 제한 사항은 다음과 같습니다.

**최대 대체 도메인 이름 수**  
현재 하나의 배포에 추가할 수 있는 대체 도메인 이름의 최대 수를 살펴보고 더 높은 할당량(이전에는 제한이라고 함)을 요청하려면, [배포의 일반 할당량](cloudfront-limits.md#limits-web-distributions) 단원을 참조하세요.

**중복 및 중첩 대체 도메인 이름**  
AWS 계정에서 다른 배포를 소유하더라도 동일한 대체 도메인 이름이 다른 CloudFront 배포 안에 이미 있는 경우에는 대체 도메인 이름을 CloudFront 배포에 추가할 수 없습니다.  
하지만 \$1.example.com 등의 와일드카드 대체 도메인 이름을 추가할 수 있는데 여기에는 www.example.com 등의 비 와일드카드 대체 도메인 이름이 포함(중첩)됩니다. 배포 2개의 대체 도메인 이름이 겹치는 경우 CloudFront는 DNS 레코드가 가리키는 배포에 상관 없이 보다 구체적으로 일치하는 이름을 사용하여 배포에 요청을 보냅니다. 예를 들어, markeeting.domain.com은 \$1.domain.com보다 더 구체적입니다.  
CloudFront 배포를 가리키는 기존 와일드카드 DNS 항목이 있고 보다 구체적인 이름으로 새 CNAME을 추가하려고 할 때 잘못 구성된 DNS 오류가 발생하는 경우 [새 CNAME을 추가하려고 하면 CloudFront에서 잘못 구성된 DNS 레코드 오류가 반환됩니다.](troubleshooting-distributions.md#troubleshoot-incorrectly-configured-DNS-record-error) 섹션을 참조하세요.

**Domain Fronting(도메인 프론팅)**  
CloudFront에는 여러 AWS 계정에서 발생하는 도메인 프론팅에 대한 보호 기능이 있습니다. 이는 표준이 아닌 클라이언트가 한 AWS 계정의 도메인 이름에 대한 TLS/SSL 연결을 생성하지만 다른 AWS 계정에서 관련이 없는 도메인 이름에 대한 HTTPS 요청을 하는 시나리오입니다.  
 예를 들어 TLS 연결은 www.example.com에 연결한 후 www.example.org에 대한 요청을 발행할 수 있습니다.  
요청이 도메인 프론팅인지 확인하기 위해 CloudFront는 다음 검사를 수행합니다.  
+ SNI 확장이 HTTP 요청 `Host` 헤더와 동일합니다.
+ 인증서가 요청의 배포와 동일한 AWS 계정에 속합니다.
+ HTTP 요청 `Host`가 TLS 핸드셰이크 중에 제공되는 인증서에 포함됩니다.
이러한 조건 중 하나라도 충족되지 않으면 CloudFront는 요청이 도메인 프론팅이라고 판단합니다. CloudFront는 421 HTTP 오류 응답과 함께 해당 요청을 거부합니다.  
클라이언트가 SNI 확장을 제공하지 않고 대신 기본 \$1.cloudfront.net 인증서를 받는 경우 CloudFront는 수신되는 요청을 수락합니다.

**CloudFront가 요청의 배포를 식별하는 방법**  
CloudFront는 `Host` 헤더를 기반으로 HTTP 요청의 배포를 식별합니다. CloudFront는 연결 중인 CloudFront IP 주소 또는 TLS 핸드셰이크 중에 제공된 SNI 핸드셰이크에 의존하지 않습니다.  
CloudFront는 요청을 수신하면 `Host` 헤더 값을 사용하여 요청을 특정 배포에 매칭합니다.  
예를 들어 배포가 두 개 있고 대체 도메인 이름이 다음 엔드포인트로 라우팅되도록 DNS 구성을 업데이트했다고 가정해 보겠습니다.  
+ primary.example.com이 d111111primary.cloudfront.net를 가리킴 
+ secondary.example.com이 d222222secondary.cloudfront.net를 가리킴 
`curl https://primary.example.com -H "Host: secondary.example.com"`과 같이 https://primary.example.com에 요청을 하지만 `Host` 헤더를 secondary.example.com으로 지정하면 요청이 대신 보조 배포로 라우팅됩니다.

**도메인의 최상위 노드(Zone Apex)에서 대체 도메인 이름 추가**  
배포에 대체 도메인 이름을 추가하는 경우, 일반적으로 DNS 구성에서 CNAME 레코드를 생성하여 도메인 이름에 대한 DNS 쿼리를 CloudFront 배포에 라우팅합니다. 하지만 Zone Apex라고 하는 DNS 네임스페이스의 최상위 노드에 대한 CNAME 레코드를 생성할 수 없습니다. DNS 프로토콜이 허용하지 않습니다. 예를 들어, DNS 이름 example.com을 등록하면 zone apex는 example.com입니다. example.com에 대한 CNAME 레코드를 생성할 수는 없지만, www.example.com, newproduct.example.com 등에 대한 CNAME 레코드는 생성할 수 있습니다.  
Route 53을 DNS 서비스로 사용하는 경우 CNAME 레코드에 비해 다음과 같은 장점이 있는 별칭 리소스 레코드 세트를 생성할 수 있습니다.  
+ 최상위 노드(example.com)에서 도메인 이름에 대한 별칭 리소스 레코드 세트를 생성할 수 있습니다.
+ 클라이언트가 지원하는 경우 대체 도메인 이름에 대한 HTTPS 레코드를 생성하여 DNS 조회의 일부로 프로토콜 협상을 허용할 수 있습니다. 자세한 내용은 [Create alias resource record set](CreatingCNAME.md#alternate-domain-https) 섹션을 참조하세요.
+ 별칭 리소스 레코드 세트를 사용할 때는 Route 53 쿼리에 대한 요금을 지불하지 않습니다.
IPv6를 활성화하는 경우 두 개의 별칭 리소스 레코드를 생성해야 합니다. 하나는 IPv6 트래픽(A 레코드)을 라우팅하고 다른 하나는 IPv4 트래픽(AAAA 레코드)을 라우팅합니다. 자세한 내용은 [IPv6 활성화(뷰어 요청)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6) 주제에서 [모든 배포 설정 참조](distribution-web-values-specify.md) 단원을 참조하십시오.
자세한 내용은 *Amazon Route 53 개발자 안내서*에서 [도메인 이름을 사용하여 Amazon CloudFront 웹 배포로 트래픽 라우팅](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html)을 참조하세요.  
DNS에 Route 53을 사용하지 않는 경우 애니캐스트 고정 IP 주소를 요청하여 example.com와 같은 apex 도메인을 CloudFront로 라우팅할 수 있습니다. 자세한 내용은 [허용 목록에 사용할 애니캐스트 고정 IP 요청](request-static-ips.md) 섹션을 참조하세요.

# 대체 도메인 이름 사용
<a name="CreatingCNAME"></a>

다음 작업 목록은 CloudFront 콘솔을 사용하여 배포에 대체 도메인 이름을 추가하여 링크에서 CloudFront 도메인 이름 대신에 고유의 도메인 이름을 사용할 수 있도록 하는 방법을 설명합니다. CloudFront API를 사용한 배포 업데이트에 대한 자세한 내용은 [배포 구성](distribution-working-with.md) 단원을 참조하세요.

**참고**  
최종 사용자가 대체 도메인 이름에 HTTPS를 사용하도록 하려면 [대체 도메인 이름과 HTTPS 사용](using-https-alternate-domain-names.md) 단원을 참조하십시오.

**시작하기 전에:** 대체 도메인 이름을 추가하도록 배포를 업데이트하기 전에 다음을 수행해야 합니다.
+ 도메인 이름을 Route 53 또는 다른 도메인 등록 기관에 등록합니다.
+ 공인 인증 기관(CA)에서 도메인 이름에 적용되는 TLS 인증서를 받습니다. 인증서를 배포에 추가하여 도메인 사용 권한이 있는지 확인합니다. 자세한 내용은 [대체 도메인 이름 사용과 관련된 요구 사항](CNAMEs.md#alternate-domain-names-requirements) 섹션을 참조하세요.<a name="CreatingCNAMEProcess"></a>

**대체 도메인 이름 사용**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 업데이트하려는 배포의 ID를 선택합니다.

1. **일반** 탭에서 **도메인 추가**를 선택합니다.

1. 서비스를 제공할 도메인을 최대 5개까지 입력합니다.

1. **다음**을 선택합니다.

1. **TLS 인증서**의 경우 CloudFront가 AWS 계정의 `us-east-1` AWS 리전에서 도메인에 대한 기존 AWS Certificate Manager(ACM) 인증서를 찾을 수 없다면 인증서를 자동으로 생성하거나 ACM에서 수동으로 생성하도록 선택할 수 있습니다.

1. 인증서가 프로비저닝되면 DNS 공급자로 DNS 레코드를 업데이트하여 도메인 소유권을 입증해야 합니다. DNS 레코드에 입력해야 하는 항목은 CloudFront 콘솔에서 제공됩니다.

1. DNS 레코드를 업데이트한 후 **인증서 검증**을 선택합니다.

1. 인증서가 검증되면 **다음**을 선택합니다.

1. 변경 사항을 검토하고 **도메인 추가**를 선택합니다.

1. 배포에 대한 **일반** 탭에서 **배포 상태**가 **배포 완료**로 변경되었는지 확인합니다. 배포에 대한 업데이트가 배포되기 전에 대체 도메인 이름을 사용하려고 하면 다음 단계에서 생성하는 링크가 작동하지 않을 수도 있습니다.

1. 트래픽을 배포의 CloudFront 도메인 이름(예: d111111abcdef8.cloudfront.net)으로 라우팅하도록 대체 도메인 이름(예: www.exapmle.com)에 대한 DNS 서비스를 구성합니다. 사용하는 방법은 Route 53을 도메인의 DNS 서비스 공급자로 사용하는지, 다른 공급자로 사용하는지에 따라 결정됩니다. 자세한 내용은 [CloudFront 표준 배포에 도메인 추가](add-domain-existing-distribution.md) 섹션을 참조하세요.  
**Route 53**  
별칭 리소스 레코드 세트를 생성합니다. 별칭 리소스 레코드 세트를 사용하면 Route 53 쿼리에 대해서는 요금이 지불되지 않습니다. 또한 DNS에서 CNAME을 허용하지 않는 루트 도메인 이름(example.com)에 대해 별칭 리소스 레코드 세트를 생성할 수 있습니다. 별칭 리소스 레코드 세트 생성에 대한 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [도메인 이름을 사용하여 Amazon CloudFront 웹 배포로 트래픽 라우팅](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html)을 참조하세요.  
선택적으로, 클라이언트가 지원하는 경우 대체 도메인 이름에 대한 HTTPS 레코드를 생성하여 DNS 조회의 일부로 프로토콜 협상을 허용할 수 있습니다.  

**HTTPS 레코드를 사용하여 별칭 리소스 레코드 세트를 생성하려면(선택 사항)**

   1. CloudFront 배포 설정에서 HTTP/2 또는 HTTP/3을 활성화합니다. 자세한 내용은 [지원되는 HTTP 버전](DownloadDistValuesGeneral.md#DownloadDistValuesSupportedHTTPVersions) 및 [배포 업데이트](HowToUpdateDistribution.md)(을)를 참조하세요.

   1. Route 53 콘솔에서 별칭 리소스 레코드 세트를 생성합니다. [도메인 이름을 사용하여 Amazon CloudFront 웹 배포로 트래픽 라우팅](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html) 절차를 따르세요.

   1. 별칭 리소스 레코드 세트를 생성하는 동안 레코드 유형 **HTTPS**를 사용하여 별칭 레코드를 생성합니다.  
**다른 DNS 서비스 공급자**  
DNS 서비스 공급자가 제공하는 방법을 사용하여 도메인에 대한 CNAME 레코드를 추가합니다. 이 새 CNAME 레코드는 DNS 쿼리를 대체 도메인 이름(예: www.example.com)에서 배포의 CloudFront 도메인 이름(예: d111111abcdef8.cloudfront.net)으로 리디렉션합니다. 자세한 내용은 DNS 서비스 공급자가 제공하는 설명서를 참조하십시오.  
대체 도메인 이름에 대한 기존 CNAME 레코드가 이미 있는 경우 해당 레코드를 업데이트하거나 배포의 CloudFront 도메인 이름을 가리키는 새 레코드로 바꿉니다.

1. `dig` 또는 이와 유사한 DNS 도구를 사용하여 이전 단계에서 생성한 DNS 구성이 배포의 도메인 이름을 가리키는지 확인합니다.

   다음 예는 www.example.com 도메인에 대한 `dig` 요청과 응답의 관련 부분을 보여 줍니다.

   ```
   PROMPT> dig www.example.com
   
   ; <<> DiG 9.3.3rc2 <<> www.example.com
   ;; global options:	printcmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15917
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 2, ADDITIONAL: 0
   
   ;; QUESTION SECTION:
   ;www.example.com.     IN    A
   
   ;; ANSWER SECTION:
   www.example.com. 10800 IN	CNAME	d111111abcdef8.cloudfront.net.
   ...
   ```

   Answer Section에서는 CNAME 레코드가 www.example.com에 대한 쿼리를 CloudFront 배포 도메인 이름 d111111abcdef8.cloudfront.net로 라우팅합니다. `CNAME`의 오른쪽에 있는 이름이 CloudFront 배포의 도메인 이름이면 CNAME 레코드가 올바르게 구성된 것입니다. 이 값이 다른 값이면(예: Amazon S3 버킷의 도메인 이름) CNAME 레코드가 잘못 구성된 것입니다. 이 경우에는 7단계로 돌아가서 배포의 도메인 이름을 가리키도록 CNAME 레코드를 수정합니다.

1. 배포의 CloudFront 도메인 이름 대신에 고유 도메인 이름을 사용하는 URL을 방문하여 대체 도메인 이름을 테스트합니다.

1. 애플리케이션에서 CloudFront 배포의 도메인 이름 대신에 대체 도메인 이름을 사용하도록 객체 URL을 변경합니다.

# 대체 도메인 이름 이동
<a name="alternate-domain-names-move"></a>

표준 배포 또는 배포 테넌트에 대체 도메인 이름을 추가하려고 하는데 대체 도메인 이름이 이미 다른 리소스와 연결되어 있는 경우 오류 메시지가 표시됩니다.

예를 들어 표준 배포 또는 배포 테넌트에 www.example.com을 추가하려고 하는데 이 대체 도메인 이름이 이미 다른 리소스와 연결되어 있는 경우 `CNAMEAlreadyExists` 오류 메시지(One or more of the CNAMEs you provided are already associated with a different resource)가 표시됩니다.

이 경우 기존 대체 도메인 이름을 한 리소스에서 다른 리소스로 이동할 수 있습니다. *소스 배포*와 *대상 배포*입니다. 표준 배포 및/또는 배포 테넌트 간에 대체 도메인 이름을 이동할 수 있습니다.

대체 도메인 이름을 이동하려면 다음 항목을 참조하세요.

**Topics**
+ [대상 표준 배포 또는 배포 테넌트 설정](alternate-domain-names-move-create-target.md)
+ [소스 표준 배포 또는 배포 테넌트 찾기](alternate-domain-names-move-find-source.md)
+ [대체 도메인 이름 이동](alternate-domain-names-move-options.md)

# 대상 표준 배포 또는 배포 테넌트 설정
<a name="alternate-domain-names-move-create-target"></a>

대체 도메인 이름을 이동하려면 먼저 대상 리소스를 설정해야 합니다. 대체 도메인 이름을 이동하려는 대상 표준 배포 또는 배포 테넌트입니다.

------
#### [ Standard distribution ]

**대상 표준 배포를 설정하려면**

1. TLS 인증서를 요청합니다. 이 인증서에는 대체 도메인 이름이 주체 또는 주체 대체 도메인(SAN)으로 포함되거나 이동하려는 대체 도메인 이름에 적용되는 와일드카드(\$1)가 포함됩니다. 없는 경우 AWS Certificate Manager(ACM) 또는 다른 인증 기관(CA)에 요청하거나 ACM으로 가져올 수 있습니다.
**참고**  
미국 동부(버지니아 북부)(`us-east-1`) 리전에서 인증서를 요청하거나 가져와야 합니다.

   자세한 내용은 *AWS Certificate Manager 사용 설명서*의 AWS Certificate Manager에서 [콘솔을 사용하여 퍼블릭 인증서 요청](https://docs.aws.amazon.com/acm/latest/userguide/acm-public-certificates.html#request-public-console) 또는 [인증서 가져오기](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-api-cli.html)를 참조하세요.

1. 대상 표준 배포를 생성하지 않은 경우 지금 생성합니다. 표준 배포 생성의 일부로 인증서를 이 표준 배포와 연결합니다. 자세한 내용은 [배포 생성](distribution-web-creating-console.md) 섹션을 참조하세요.

   대상 표준 배포가 이미 있는 경우 인증서를 표준 배포와 연결합니다. 자세한 내용은 [배포 업데이트](HowToUpdateDistribution.md) 섹션을 참조하세요.

1. **동일한 AWS 계정 내에서 대체 도메인 이름을 이동하는 경우 이 단계를 건너뜁니다.**

   대체 도메인 이름을 AWS 계정 간에 이동하려면 DNS 구성에서 TXT 레코드를 생성해야 합니다. 이 확인 단계는 무단 도메인 전송을 방지하는 데 도움이 됩니다. CloudFront가 이 TXT 레코드를 사용하여 대체 도메인 이름의 소유권을 확인합니다.

   DNS 구성에서 대체 도메인 이름을 대상 표준 배포와 연결하는 DNS TXT 레코드를 생성합니다. TXT 레코드 형식은 도메인 유형에 따라 다를 수 있습니다.
   + 하위 도메인의 경우 대체 도메인 이름 앞에 밑줄(`_`)을 지정합니다. 다음에 TXT 레코드의 예시가 나와 있습니다.

     `_www.example.com TXT d111111abcdef8.cloudfront.net`
   + apex(또는 루트 도메인)의 경우 도메인 이름 앞에 밑줄과 마침표(`_.`)를 지정합니다. 다음에 TXT 레코드의 예시가 나와 있습니다.

     `_.example.com TXT d111111abcdef8.cloudfront.net`

------
#### [ Distribution tenant ]

**대상 배포 테넌트를 설정하려면**

1. TLS 인증서를 요청합니다. 이 인증서에는 대체 도메인 이름이 주체 또는 주체 대체 도메인(SAN)으로 포함되거나 이동하려는 대체 도메인 이름에 적용되는 와일드카드(\$1)가 포함됩니다. 없는 경우 AWS Certificate Manager(ACM) 또는 다른 인증 기관(CA)에 요청하거나 ACM으로 가져올 수 있습니다.
**참고**  
미국 동부(버지니아 북부)(`us-east-1`) 리전에서 인증서를 요청하거나 가져와야 합니다.

   자세한 내용은 *AWS Certificate Manager 사용 설명서*의 AWS Certificate Manager에서 [콘솔을 사용하여 퍼블릭 인증서 요청](https://docs.aws.amazon.com/acm/latest/userguide/acm-public-certificates.html#request-public-console) 또는 [인증서 가져오기](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-api-cli.html)를 참조하세요.

1. 대상 배포 테넌트를 생성하지 않은 경우 지금 생성합니다. 대상 배포를 생성하는 과정에서 인증서를 배포 테넌트와 연결합니다. 자세한 내용은 [배포 생성](distribution-web-creating-console.md) 섹션을 참조하세요.

   대상 표준 배포가 이미 있는 경우 인증서를 배포 테넌트와 연결합니다. 자세한 내용은 [도메인 및 인증서 추가(분산 테넌트)](managed-cloudfront-certificates.md#vanity-domain-tls-tenant) 섹션을 참조하세요.

1. **동일한 AWS 계정 내에서 대체 도메인 이름을 이동하는 경우 이 단계를 건너뜁니다.**

   대체 도메인 이름을 AWS 계정 간에 이동하려면 DNS 구성에서 TXT 레코드를 생성해야 합니다. 이 확인 단계는 무단 도메인 이전을 방지하는 데 도움이 되며 CloudFront는 이 TXT 레코드를 사용하여 대체 도메인 이름의 소유권을 검증합니다.

   DNS 구성에서 대체 도메인 이름을 대상 배포 테넌트와 연결하는 DNS TXT 레코드를 생성합니다. TXT 레코드 형식은 도메인 유형에 따라 다를 수 있습니다.
   + 하위 도메인의 경우 대체 도메인 이름 앞에 밑줄(`_`)을 지정합니다. 다음에 TXT 레코드의 예시가 나와 있습니다.

     `_www.example.com TXT d111111abcdef8.cloudfront.net`
   + apex(또는 루트 도메인)의 경우 도메인 이름 앞에 밑줄과 마침표(`_.`)를 지정합니다. 다음에 TXT 레코드의 예시가 나와 있습니다.

     `_.example.com TXT d111111abcdef8.cloudfront.net`

------

그러고 나서 다음 항목을 참조하여 대체 도메인 이름과 이미 연결된 소스 표준 배포 또는 배포 테넌트를 찾습니다.

# 소스 표준 배포 또는 배포 테넌트 찾기
<a name="alternate-domain-names-move-find-source"></a>

한 배포(표준 또는 테넌트)에서 다른 배포로 대체 도메인 이름을 이동하려면 먼저 *소스 배포*를 찾습니다. 대체 도메인 이름이 이미 연결된 리소스입니다. 소스와 대상 배포 리소스의 AWS 계정 ID 모두를 알고 있는 경우 대체 도메인 이름을 이동하는 방법을 결정할 수 있습니다.

**참고**  
표준 배포와 배포 테넌트를 모두 지원하는 [ListDomainConflicts](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListDomainConflicts.html) API 작업을 사용하는 것이 좋습니다.
[ListConflictingAliases](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListConflictingAliases.html) API 작업은 표준 배포만 지원합니다.

다음 예시를 따라 소스 배포(표준 또는 테넌트)를 찾습니다.

------
#### [ list-domain-conflicts ]

**작은 정보**  
표준 배포의 경우 `cloudfront:GetDistribution` 및 `cloudfront:ListDomainConflicts` 권한이 있어야 합니다.
배포 테넌트의 경우 `cloudfront:GetDistributionTenant` 및 `cloudfront:ListDomainConflicts` 권한이 있어야 합니다.

**`list-domain-conflicts`를 사용하여 소스 표준 배포 또는 배포 테넌트를 찾으려면**

1. 다음 예와 같이 `list-domain-conflicts` 명령을 사용합니다.

   1. *www.example.com*을 도메인 이름으로 바꿉니다.

   1. `domain-control-validation-resource`의 경우 [이전에 설정](alternate-domain-names-move-create-target.md)한 대상 표준 배포 또는 배포 테넌트의 ID를 지정합니다. 지정된 도메인에 적용되는 인증서와 연결된 표준 배포 또는 배포 테넌트가 있어야 합니다.

   1. 대상 표준 배포 또는 배포 테넌트와 동일한 AWS 계정에 있는 자격 증명을 사용하여 이 명령을 실행합니다.

   **요청**

    이 예시에서는 배포 테넌트를 지정합니다.

   ```
   aws cloudfront list-domain-conflicts \
   --domain www.example.com \
   --domain-control-validation-resource "DistributionTenantId=dt_2x9GhoK0TZRsohWzv1b9It8JABC"
   ```

   **응답**

   명령 출력의 각 도메인 이름에 대해 다음을 볼 수 있습니다.
   + 도메인에 연결된 리소스 유형
   + 리소스 ID
   + 리소스를 소유한 AWS 계정 ID

   리소스 ID와 계정 ID는 부분적으로 가려집니다. 이를 통해 계정에 속한 표준 배포 또는 배포 테넌트를 식별하고 소유하지 않은 표준 배포 또는 배포 테넌트의 정보를 보호할 수 있습니다.

   ```
   {
       "DomainConflicts": [
           {
               "Domain": "www.example.com",
               "ResourceType": "distribution-tenant",
               "ResourceId": "***************ohWzv1b9It8JABC",
               "AccountId": "******112233"
           }
       ]
   }
   ```

   응답에는 지정한 도메인 이름과 충돌하거나 겹치는 모든 도메인 이름이 나열됩니다.

**예제**
   + *tenant1.example.com*을 지정하는 경우 응답에는 tenant1.example.com 및 겹치는 와일드카드 대체 도메인 이름(\$1.example.com, 있는 경우)이 포함됩니다.
   + *\$1.tenant1.example.com*을 지정하면 응답에 \$1.tenant1.example.com 및 해당 와일드카드가 적용되는 대체 도메인 이름(예: test.tenant1.example.com, dev.tenant1.example.com 등)이 포함됩니다.

1. 응답에서 이동하려는 대체 도메인 이름의 소스 표준 배포 또는 배포 테넌트를 찾고 AWS 계정 ID를 기록해 둡니다.

1. *소스* 표준 배포 또는 배포 테넌트의 계정 ID를 [이전 단계](alternate-domain-names-move-create-target.md)에서 *대상* 표준 배포 또는 배포 테넌트를 생성한 계정 ID와 비교합니다. 그러면 소스와 대상이 동일한 AWS 계정에 있는지 확인할 수 있습니다. 이렇게 하면 대체 도메인 이름을 이동하는 방법을 결정할 수 있습니다.

   자세한 내용은 *AWS Command Line Interface 명령 참조*의 [https://docs.aws.amazon.com/cli/latest/reference/cloudfront/list-domain-conflicts.html](https://docs.aws.amazon.com/cli/latest/reference/cloudfront/list-domain-conflicts.html) 명령을 참조하세요.

------
#### [ list-conflicting-aliases (standard distributions only) ]

**작은 정보**  
대상 표준 배포에 대한 `cloudfront:GetDistribution` 및 `cloudfront:ListConflictingAliases` 권한이 있어야 합니다.

**`list-conflicting-aliases`를 사용하여 소스 표준 배포를 찾으려면**

1. 다음 예와 같이 `list-conflicting-aliases` 명령을 사용합니다.

   1. *www.example.com*을 대체 도메인 이름으로 바꾸고 *EDFDVBD6EXAMPLE*을 [이전에 설정](alternate-domain-names-move-create-target.md)한 대상 표준 배포의 ID로 바꿉니다.

   1. 대상 표준 배포와 동일한 AWS 계정의 자격 증명을 사용하여 이 명령을 실행합니다.

   **요청**

    이 예시에서는 표준 배포를 지정합니다.

   ```
   aws cloudfront list-conflicting-aliases \
   --alias www.example.com \
   --distribution-id EDFDVBD6EXAMPLE
   ```

   **응답**

   명령의 출력에 있는 각 대체 도메인 이름에 대해 연결된 표준 배포의 ID와 해당 표준 배포를 소유하는 AWS 계정 ID를 볼 수 있습니다. 표준 배포 및 계정 ID는 부분적으로 가려지므로 본인이 소유한 표준 배포와 계정을 식별할 수 있지만 소유하지 않은 배포의 정보를 보호하는 데 도움이 됩니다.

   ```
   {
       "ConflictingAliasesList": {
           "MaxItems": 100,
           "Quantity": 1,
           "Items": [
               {
                   "Alias": "www.example.com",
                   "DistributionId": "*******EXAMPLE",
                   "AccountId": "******112233"
               }
           ]
       }
   }
   ```

   응답에는 지정한 도메인 이름과 충돌하거나 겹치는 대체 도메인 이름이 나열됩니다.

**예제**
   + *www.example.com*을 지정하는 경우 응답에는 www.example.com 및 겹치는 와일드카드 대체 도메인 이름(\$1.example.com, 있는 경우)이 포함됩니다.
   + *\$1.example.com*을 지정한다면 응답에는 \$1.example.com 및 해당 와일드카드가 적용되는 대체 도메인 이름(예: www.example.com, test.example.com, dev.example.com 등)이 명령의 출력에 포함됩니다.

1. 이동하려는 대체 도메인 이름의 표준 배포를 찾고 AWS 계정 ID를 기록해 둡니다. 이 계정 ID를 [이전 단계](alternate-domain-names-move-create-target.md)에서 대상 표준 배포를 생성한 계정 ID와 비교합니다. 그러면 이러한 두 표준 배포가 동일한 AWS 계정에 있는지 여부와 대체 도메인 이름을 이동하는 방법을 확인할 수 있습니다.

   자세한 내용은 *AWS Command Line Interface 명령 참조*의 [https://docs.aws.amazon.com//cli/latest/reference/cloudfront/list-conflicting-aliases.html](https://docs.aws.amazon.com//cli/latest/reference/cloudfront/list-conflicting-aliases.html) 명령을 참조하세요.

------

그런 다음 대체 도메인 이름을 이동하려면 다음 항목을 참조하세요.

# 대체 도메인 이름 이동
<a name="alternate-domain-names-move-options"></a>

상황에 따라 다음 방법 중에서 선택하여 대체 도메인 이름을 이동합니다.

**소스와 대상 배포(표준 또는 테넌트)가 동일한 AWS 계정에 있음**  
AWS Command Line Interface(AWS CLI)에서 **update-domain-association** 명령을 사용하여 대체 도메인 이름을 이동합니다.  
이 명령은 대체 도메인 이름이 apex 도메인(*루트 도메인*이라고도 함. 예: example.com)인 경우를 포함해 같은 계정 이동인 경우 작동합니다.

**소스와 대상 배포(표준 또는 테넌트)가 서로 다른 AWS 계정에 있음**  
소스 표준 배포 또는 배포 테넌트에 대한 액세스 권한이 있고 대체 도메인 이름이 apex 도메인이 *아니며* 해당 대체 도메인 이름과 겹치는 와일드카드를 아직 사용하고 있지 않은 경우, 대체 도메인 이름을 이동하려면 와일드카드를 사용합니다. 자세한 내용은 [와일드카드를 사용하여 대체 도메인 이름 이동](#alternate-domain-names-move-use-wildcard) 섹션을 참조하세요.  
소스 표준 배포 또는 배포 테넌트의 AWS 계정에 대한 액세스 권한이 없는 경우, **update-domain-association** 명령을 사용해 대체 도메인 이름을 이동해볼 수 있습니다. 대체 도메인 이름을 이동하려면 소스 표준 배포 또는 배포 테넌트를 비활성화해야 합니다. 추가적인 도움말은 [AWS Support에 문의하여 대체 도메인 이름을 이동](#alternate-domain-names-move-contact-support) 섹션을 참조하십시오.

**참고**  
**associate-alias** 명령을 사용할 수 있지만 이 명령은 표준 배포만 지원합니다. *Amazon CloudFront API 참조*의 [AssociateAlias](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_AssociateAlias.html)를 참조하세요.

------
#### [ update-domain-association (standard distributions and distribution tenants) ]

**`update-domain-association`를 사용하여 대체 도메인 이름을 이동하려면**

1. 다음 예와 같이 `update-domain-association` 명령을 사용하세요.

   1. *example.com*을 대체 도메인 이름으로 바꾸고 대상 표준 배포 또는 배포 테넌트의 ID를 지정합니다.

   1. 대상 표준 배포 또는 배포 테넌트와 동일한 AWS 계정에 있는 자격 증명을 사용하여 이 명령을 실행합니다.
**다음과 같은 제한 사항이 있습니다.**  
`cloudfront:UpdateDomainAssociation` 권한 외에도 표준 배포를 업데이트할 수 있는 `cloudfront:UpdateDistribution` 권한이 있어야 합니다. 배포 테넌트를 업데이트하려면 `cloudfront:UpdateDistributionTenant` 권한이 있어야 합니다.
소스 배포와 대상 배포(표준 또는 테넌트)가 서로 다른 AWS 계정에 있는 경우 도메인을 이동하려면 먼저 소스를 비활성화해야 합니다.
대상 배포는 [대상 표준 배포 또는 배포 테넌트 설정](alternate-domain-names-move-create-target.md)에 설명된 대로 설정해야 합니다.

   **요청**

   ```
   aws cloudfront update-domain-association \
     --domain "www.example.com" \
     --target-resource DistributionTenantId=dt_9Fd3xTZq7Hl2KABC \
     --if-match E3UN6WX5ABC123
   ```

   **응답**

   ```
   {
       "ETag": "E7Xp1Y3N9DABC",
       "Domain": "www.example.com",
       "ResourceId": "dt_9Fd3xTZq7Hl2KABC"
   }
   ```

   이 명령은 대체 도메인 이름을 소스 표준 배포 또는 배포 테넌트에서 제거하고 대상 표준 배포 또는 배포 테넌트에 추가합니다.

1. 대상 배포가 완전히 배포되면 도메인 이름이 CloudFront 라우팅 엔드포인트를 가리키도록 DNS 구성을 업데이트합니다. 예를 들어 DNS 레코드가 대체 도메인 이름(`www.example.com`)을 CloudFront 제공 도메인 이름인 d111111abcdef8.cloudfront.net로 가리키도록 합니다. 대상이 배포 테넌트인 경우 연결 그룹 엔드포인트를 지정합니다. 자세한 내용은 [도메인을 CloudFront로 가리키기](managed-cloudfront-certificates.md#point-domains-to-cloudfront) 섹션을 참조하세요.

------
#### [ associate-alias (standard distributions only) ]

**`associate-alias`를 사용하여 대체 도메인 이름을 이동하려면**

1. 다음 예와 같이 `associate-alias` 명령을 사용하세요.

   1. *www.example.com*을 대체 도메인 이름으로 바꾸고 *EDFDVBD6EXAMPLE*을 대상 표준 배포 ID로 바꿉니다.

   1. 대상 표준 배포와 동일한 AWS 계정의 자격 증명을 사용하여 이 명령을 실행합니다.
**다음과 같은 제한 사항이 있습니다.**  
표준 대상 배포에 대한 `cloudfront:AssociateAlias` 및 `cloudfront:UpdateDistribution` 권한이 있어야 합니다.
소스 표준 배포와 대상 표준 배포가 동일한 AWS 계정에 있는 경우 소스 표준 배포에 대한 `cloudfront:UpdateDistribution` 권한이 있어야 합니다.
소스 표준 배포와 대상 표준 배포가 서로 다른 AWS 계정에 있는 경우 먼저 소스 표준 배포를 비활성화해야 합니다.
대상 표준 배포는 [대상 표준 배포 또는 배포 테넌트 설정](alternate-domain-names-move-create-target.md)에 설명된 대로 설정해야 합니다.

      **요청**

      ```
      aws cloudfront associate-alias \
      --alias www.example.com \
      --target-distribution-id EDFDVBD6EXAMPLE
      ```

      이 명령은 대체 도메인 이름을 소스 표준 배포에서 제거하고 대상 표준 배포로 이동합니다.

1. 대상 표준 배포가 완전히 배포된 후 대체 도메인 이름의 DNS 레코드가 대상 표준 배포의 배포 도메인 이름을 가리키도록 DNS 구성을 업데이트합니다. 예를 들어 DNS 레코드가 대체 도메인 이름(`www.example.com`)을 CloudFront 제공 도메인 이름인 d111111abcdef8.cloudfront.net로 가리키도록 합니다.

자세한 내용은 *AWS CLI 명령 참조*의 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudfront/associate-alias.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudfront/associate-alias.html) 명령을 참조하세요.

------

## 와일드카드를 사용하여 대체 도메인 이름 이동
<a name="alternate-domain-names-move-use-wildcard"></a>

소스 배포가 대상 배포와 서로 다른 AWS 계정에 있고 소스 배포가 활성화된 경우, 와일드카드를 사용하여 대체 도메인 이름을 이동할 수 있습니다.

**참고**  
와일드카드를 사용하여 apex 도메인(예: example.com)을 이동할 수는 없습니다. 소스 배포와 대상 배포가 서로 다른 AWS 계정에 있을 때 apex 도메인을 이동하려면 지원에 문의하세요. 자세한 내용은 [AWS Support에 문의하여 대체 도메인 이름을 이동](#alternate-domain-names-move-contact-support) 섹션을 참조하세요.

**와일드카드를 사용하여 대체 도메인 이름을 이동하려면 다음을 수행합니다.**
**참고**  
이 프로세스에는 배포에 대한 다중 업데이트가 포함됩니다. 각 배포가 최신 변경 사항을 완전히 배포할 때까지 기다린 후 다음 단계를 진행합니다.

1. 대상 배포를 업데이트하여 이동할 대체 도메인 이름을 포함하는 와일드카드 대체 도메인 이름을 추가합니다. 예를 들어 이동할 대체 도메인 이름이 www.example.com인 경우 대체 도메인 이름 \$1.example.com을 대상 배포에 추가합니다. 이렇게 하려면 대상 배포의 SSL/TLS 인증서에 와일드카드 도메인 이름이 포함되어야 합니다. 자세한 내용은 [배포 업데이트](HowToUpdateDistribution.md) 단원을 참조하세요.

1. 대상 배포의 도메인 이름을 가리키도록 대체 도메인 이름에 대한 DNS 설정을 업데이트합니다. 예를 들어 이동하려는 대체 도메인 이름이 www.example.com인 경우 대상 배포의 도메인 이름(예: d1111abcdef8.cloudfront.net)으로 트래픽을 라우팅하도록 www.example.com에 대한 DNS 레코드를 업데이트합니다.
**참고**  
DNS 설정을 업데이트해도 대체 도메인 이름이 현재 구성되어 있으므로 대체 도메인 이름이 소스 배포에서 계속 제공됩니다.

1. 소스 배포를 업데이트하여 대체 도메인 이름을 제거합니다. 자세한 내용은 [배포 업데이트](HowToUpdateDistribution.md) 단원을 참조하세요.

1. 대상 배포를 업데이트하여 대체 도메인 이름을 추가합니다. 자세한 내용은 [배포 업데이트](HowToUpdateDistribution.md) 단원을 참조하세요.

1. **dig**(또는 유사한 DNS 쿼리 도구)을(를) 사용하여 대체 도메인 이름에 대한 DNS 레코드가 대상 배포의 도메인 이름으로 확인되는지 확인합니다.

1. (선택 사항) 대상 배포를 업데이트하여 와일드카드 대체 도메인 이름을 제거합니다.

## AWS Support에 문의하여 대체 도메인 이름을 이동
<a name="alternate-domain-names-move-contact-support"></a>

소스 배포와 대상 배포가 서로 다른 AWS 계정에 있고 소스 배포의 AWS 계정에 대한 액세스 권한이 없거나 소스 배포를 비활성화할 수 없는 경우 지원에 문의하여 대체 도메인 이름을 이동할 수 있습니다.

**지원에 문의하여 대체 도메인 이름을 이동하려면 다음을 수행하세요.**

1. 대상 배포를 가리키는 DNS TXT 레코드를 포함하여 대상 배포를 설정합니다. 자세한 내용은 [대상 표준 배포 또는 배포 테넌트 설정](alternate-domain-names-move-create-target.md) 단원을 참조하세요.

1. [지원에 문의](https://console.aws.amazon.com/support/home)해 도메인 소유권을 확인하고 새 CloudFront 배포로 도메인을 이동시켜 달라고 요청합니다.

1. 대상 배포가 완전히 배포된 후 대체 도메인 이름의 DNS 레코드가 대상 배포의 배포 도메인 이름을 가리키도록 DNS 구성을 업데이트합니다.

# 대체 도메인 이름 제거
<a name="alternate-domain-names-remove-domain"></a>

도메인 또는 하위 도메인에서 CloudFront 배포로의 트래픽 라우팅을 중단시키고 싶으면 여기 나오는 단계에 따라 DNS 구성과 CloudFront 배포를 모두 업데이트합니다.

배포에서 대체 도메인 이름을 제거하고 DNS 구성을 업데이트하는 것이 중요합니다. 이렇게 하면 나중에 CloudFront 배포에 도메인 이름을 연결하고 싶은 경우에 문제가 발생하는 것을 막을 수 있습니다. 대체 도메인 이름이 이미 하나의 배포에 연결되어 있는 경우에는 또 다른 연결을 설정할 수 없습니다.

**참고**  
또 다른 배포에 추가할 수 있도록 이 배포에서 대체 도메인 이름을 제거하고 싶으면 [대체 도메인 이름 이동](alternate-domain-names-move.md)의 단계를 따릅니다. 도메인을 제거하는 대신에 여기 나온 단계에 따라 또 다른 배포에 도메인을 추가한 경우에는 도메인이 새 배포에 연결되지 않는 기간이 존재합니다. 왜냐하면 CloudFront가 엣지 로케이션에 대한 업데이트로 전파되고 있기 때문입니다.<a name="RemovingADomain"></a>

**배포에서 대체 도메인 이름을 제거하려면**

1. 먼저 도메인에 대한 인터넷 트래픽을 CloudFront 배포가 아닌 또 다른 리소스(예: Elastic Load Balancing 로드 밸런서)로 라우팅합니다. 또는 CloudFront로 트래픽을 라우팅하고 있는 DNS 레코드를 삭제할 수 있습니다.

   도메인의 DNS 서비스에 따라 다음 중 하나를 수행합니다.
   + **Route 53을 사용 중인 경우**에는 별칭 레코드나 CNAME 레코드를 업데이트 또는 삭제합니다. 자세한 내용은 [레코드 편집](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-editing.html) 또는 [레코드 삭제](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-deleting.html)를 참조하세요.
   + **또 다른 DNS 서비스 공급자를 사용하고 있는 경우**에는 DNS 서비스 공급자가 제공한 방법을 사용하여 CloudFront로 트래픽을 전달하는 CNAME 레코드를 업데이트 또는 삭제합니다. 자세한 내용은 DNS 서비스 공급자가 제공하는 설명서를 참조하십시오.

1. 도메인의 DNS 레코드를 업데이트한 후에는 변경 사항이 전파되어 DNS 해석기가 새 리소스로 트래픽을 라우팅할 때까지 기다립니다. 라우팅이 완료되면 URL에서 도메인을 사용하는 몇 가지 테스트 링크를 생성하여 확인할 수 있습니다.

1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 연 다음, 다음과 같이 CloudFront 배포를 업데이트하여 도메인 이름을 제거합니다.

   1. 업데이트하려는 배포의 ID를 선택합니다.

   1. [**General**] 탭에서 [**Edit**]를 선택합니다.

   1. **대체 도메인 이름 사용(CNAME)**에서 배포에서 더 이상 사용하고 싶지 않은 대체 도메인 이름 또는 도메인 이름을 제거합니다.

   1. **예, 편집합니다**를 선택합니다.

# 대체 도메인 이름에서 와일드카드 사용
<a name="alternate-domain-names-wildcard"></a>

대체 도메인 이름을 추가할 경우 하위 도메인을 개별적으로 추가하는 대신에 도메인 이름 시작 부분에 와일드카드(\$1)를 사용할 수 있습니다. 예를 들어 대체 도메인 이름으로 \$1.example.com을 사용하면 example.com으로 끝나는 모든 도메인 이름(예: www.example.com, product-name.example.com, marketing.product-name.example.com 등)을 URL에 사용할 수 있습니다. 객체의 경로는 도메인 이름과 상관없이 동일하며, 예를 들면 다음과 같습니다.
+ www.example.com/images/image.jpg
+ product-name.example.com/images/image.jpg
+ marketing.product-name.example.com/images/image.jpg

와일드카드가 포함된 대체 도메인 이름에 대해 다음 요구 사항을 따르세요.
+ 대체 도메인 이름은 별표(\$1)와 마침표(.)로 시작해야 합니다.
+ 와일드카드를 사용하여 하위 도메인 이름의 일부를 *대체할 수 없습니다*(예: \$1domain.example.com).
+ 도메인 이름의 중간에 있는 하위 도메인은 바꿀 수 없습니다(예: subdomain.\$1.example.com).
+ 와일드카드를 사용하는 대체 도메인 이름을 포함하여 모든 대체 도메인 이름은 인증서의 주체 대체 이름(SAN)으로 보호되어야 합니다.

와일드카드 대체 도메인 이름(예: \$1.example.com)에는 사용 중인 다른 대체 도메인 이름(예: example.com이 포함될 수 있습니다.

# CloudFront 배포에 WebSocket 사용
<a name="distribution-working-with.websockets"></a>

Amazon CloudFront는 클라이언트와 서버 사이에 수명이 긴 양방향 연결이 필요할 때 유용한 TCP 기반 프로토콜인 WebSocket의 사용을 지원합니다. 지속적 연결이 실시간 애플리케이션의 요구 사항에 포함되는 경우가 흔히 있습니다. WebSockets를 사용할 수 있는 시나리오에는 채팅 플랫폼, 온라인 협업 공간, 멀티 플레이어 게임 및 금융 거래 플랫폼과 같이 실시간 데이터 피드를 제공하는 서비스 등이 포함됩니다. WebSocket 연결에서는 데이터가 전이중 통신의 양방향으로 흐를 수 있습니다.

WebSocket 기능은 모든 배포판에서 작동하도록 자동으로 활성화됩니다. WebSocket을 사용하려면 배포에 연결된 캐시 동작에서 다음 중 하나를 구성합니다.
+ 모든 뷰어 요청 헤더를 오리진에 전달합니다. [AllViewer 관리형 오리진](using-managed-origin-request-policies.md#managed-origin-request-policy-all-viewer) 요청 정책을 사용할 수 있습니다.
+ 특히 원본 요청 정책에서 `Sec-WebSocket-Key` 및 `Sec-WebSocket-Version` 요청 헤더를 구체적으로 전달하세요.

## WebSocket 프로토콜의 작동 방식
<a name="distribution-working-with.websockets.how-it-works"></a>

WebSocket 프로토콜은 독립적인 TCP 기반의 프로토콜이며, 이를 통해 HTTP의 오버헤드 및 잠재적인 지연 시간 연장을 방지할 수 있습니다.

WebSocket 연결을 설정하기 위해, 클라이언트가 HTTP의 업그레이드 의미론을 사용하는 정규 HTTP 요청을 전송하여 프로토콜을 변경합니다. 그 후에는 서버가 핸드셰이크를 완료할 수 있습니다. WebSocket 연결은 개방 상태를 유지하며 클라이언트 또는 서버가 매회 새로운 연결을 설정할 필요 없이 서로에게 데이터 프레임을 전송할 수 있습니다.

기본적으로 WebSocket 프로토콜은 정규 WebSocket 연결에 포트 80을, TLS를 통한 WebSocket 연결에는 포트 443을 사용합니다. CloudFront [뷰어 프로토콜 정책](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy) 및 [프로토콜(사용자 지정 오리진만 해당)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy)에 대해 선택한 옵션은 WebSocket 연결뿐 아니라 HTTP 트래픽에도 적용됩니다.

## WebSocket 요구 사항
<a name="distribution-working-with.websockets.requirements"></a>

WebSocket 요청은 다음 표준 형식으로 [RFC 6455](https://datatracker.ietf.org/doc/html/rfc6455)를 준수해야 합니다.

**Example 예제 클라이언트 요청**  

```
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: https://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
```

**Example 샘플 서버 응답**  

```
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
```

WebSocket 연결이 클라이언트나 서버 또는 네트워크 장애로 인해 끊어진 겨우, 클라이언트 애플리케이션이 서버와의 연결을 다시 시작해야 합니다.

## 권장 WebSocket 헤더
<a name="distribution-working-with.websockets.recomended-settings"></a>

WebSocket을 사용할 때 예상치 못한 압축 관련 문제를 방지하려면 [오리진 요청 정책](origin-request-create-origin-request-policy.md)에 다음 헤더를 포함하는 것이 좋습니다.
+ `Sec-WebSocket-Key`
+ `Sec-WebSocket-Version`
+ `Sec-WebSocket-Protocol`
+ `Sec-WebSocket-Accept`
+ `Sec-WebSocket-Extensions`

**참고**  
현재 CloudFront는 HTTP/1.1 프로토콜을 통한 WebSocket 연결만 지원합니다.

# 허용 목록에 사용할 애니캐스트 고정 IP 요청
<a name="request-static-ips"></a>

CloudFront에서 배포에 사용할 애니캐스트 고정 IP를 요청할 수 있습니다. 애니캐스트 고정 IP 목록에는 IPv4 IP 주소만 포함하거나 IPv4 및 IPv6 IP 주소 둘 다 포함될 수 있습니다. 이러한 고정 IP는 AWS 계정 전용이며 여러 리전에 분산되어 있습니다.

네트워크 공급자의 허용 목록에 추가할 21개의 애니캐스트 고정 IP 주소를 요청하여 애플리케이션에 액세스하는 사용자의 데이터 요금을 면제하거나, 아웃바운드 보안 방화벽 내에서 이러한 고정 IP를 사용하여 승인된 애플리케이션과의 트래픽 교환을 제어할 수 있습니다. 애니캐스트 고정 IP 목록은 하나 이상의 배포와 함께 사용할 수 있습니다.

CloudFront 배포로 직접 apex 도메인(예: example.com)을 라우팅하려는 경우 이 사용 사례용으로 3개의 애니캐스트 고정 IP 주소를 요청할 수 있습니다. 그런 다음 DNS에 A 레코드를 추가하여 apex 도메인이 CloudFront를 가리키도록 합니다.

애니캐스트 고정 IP는 [서버 이름 표시(SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication)와 함께 작동합니다. 자세한 내용은 [SNI를 사용하여 HTTPS 요청 제공(대부분 클라이언트에 적용)](cnames-https-dedicated-ip-or-sni.md#cnames-https-sni) 섹션을 참조하세요.

## 사전 조건
<a name="anycast-static-ip-prereqs"></a>

CloudFront 배포에서 애니캐스트 고정 IP 목록을 사용하려면 배포의 가격 등급에 대해 **모든 엣지 로케이션 사용**을 선택해야 합니다. 요금에 대한 자세한 내용은 [CloudFront 요금](https://aws.amazon.com/cloudfront/pricing/)을 참조하시기 바랍니다.

## 애니캐스트 고정 IP 목록 요청
<a name="request-static-ip-list"></a>

CloudFront 배포에 사용할 애니캐스트 고정 IP 목록을 요청합니다.

**애니캐스트 고정 IP 목록을 요청하려면 다음과 같이 합니다.**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **고정 IP**를 선택합니다.

1. **요청**에서 CloudFront 지원 엔지니어링 팀에 문의할 수 있는 링크를 선택합니다.

1. 워크로드 정보(초당 요청 바이트 수 및 초당 요청 수)를 제공합니다.

1. CloudFront 지원 엔지니어링 팀에서는 요청을 검토합니다. 검토 프로세스는 최대 2일이 걸릴 수 있습니다.

요청이 승인되면 애니캐스트 고정 IP 목록을 만들어 하나 이상의 배포와 연결할 수 있습니다.

## 애니캐스트 고정 IP 목록 생성
<a name="create-static-ip-list"></a>

시작하기 전에 이전 섹션에 설명된 대로 애니캐스트 고정 IP 목록을 요청합니다.

**애니캐스트 고정 IP 목록을 만들려면 다음과 같이 합니다.**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **고정 IP**를 선택합니다.

1. **애니캐스트 IP 목록 생성**을 선택합니다.

1. **이름**에 이름을 입력합니다.

1. **고정 IP 사용 사례**에서 적절한 사용 사례를 선택합니다.

1. **IP 주소 유형**에서 다음 옵션 중 하나를 지정합니다.
   + **IPv4** - IPv4 주소 목록만 할당 
   + **듀얼 스택** - IPv4 및 IPv6 주소 목록 할당

1. 서비스 약관 및 요금을 검토하고 **제출**을 선택합니다.

고정 IP 목록이 만들어지면 고정 IP 목록 세부 정보 페이지에서 할당된 IP 주소를 볼 수 있습니다. 배포를 고정 IP 목록과 연결할 수도 있습니다.

## 애니캐스트 고정 IP 목록을 기존 배포와 연결
<a name="associate-static-ip-list-existing"></a>

시작하기 전에 이전 섹션에 설명된 대로 애니캐스트 고정 IP 목록을 요청하고 만듭니다.

다음 배포 설정이 애니캐스트 고정 IP 목록과 호환되는지 확인합니다.
+ [요금 계층](DownloadDistValuesGeneral.md#DownloadDistValuesPriceClass)에는 **모든 엣지 로케이션 사용(최상의 성능)** 설정이 있습니다.
+ [IPv6](cloudfront-enable-ipv6.md)가 활성화된 경우 듀얼 스택 애니캐스트 고정 IP 목록을 연결할 수 있습니다. IPv4 주소만 있는 애니캐스트 정적 IP 목록은 IPv6가 활성화된 배포에 연결할 수 없습니다.

**애니캐스트 고정 IP 목록을 기존 배포와 연결하려면 다음과 같이 합니다.**
+ 다음 중 하나를 수행하세요.
  + 고정 IP 목록 세부 정보 페이지에서 고정 IP 목록을 연결합니다.

    1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

    1. 왼쪽 탐색 창에서 **고정 IP**를 선택합니다.

    1. 고정 IP 목록의 이름을 선택합니다.

    1. **배포 연결**을 선택합니다.

    1. 하나 이상의 배포를 선택하고 **배포 연결**을 선택합니다.
  + 배포 세부 정보 페이지에서 다음과 같이 고정 IP 목록을 연결합니다.

    1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

    1. 왼쪽 탐색 창에서 **배포**를 선택합니다.

    1. 배포의 이름을 선택합니다.

    1. **일반** 탭의 **설정**에서 **편집**을 선택합니다.

    1. **애니캐스트 IP 목록**에서 이 배포에 사용할 애니캐스트 고정 IP 목록을 선택합니다.

    1. **변경 사항 저장**을 선택합니다.

## 애니캐스트 고정 IP 목록을 새 배포와 연결
<a name="associate-static-ip-list-new"></a>

시작하기 전에 이전 섹션에 설명된 대로 애니캐스트 고정 IP 목록을 요청하고 만듭니다.

**애니캐스트 고정 IP 목록을 새 배포와 연결하려면 다음과 같이 합니다.**
+ 새 배포를 생성합니다. 자세한 내용은 [콘솔에서 CloudFront 배포 생성](distribution-web-creating-console.md#create-console-distribution) 섹션을 참조하세요. **설정**에서 애니캐스트 고정 IP 목록을 사용하려면 다음을 선택해야 합니다.
  + **애니캐스트 IP 목록**의 드롭다운 목록에서 애니캐스트 고정 IP 목록을 선택합니다.
  + **가격 분류**에서 **모든 엣지 로케이션에서 사용(최고의 성능)**을 선택합니다.
  + **참고:** 애니캐스트 고정 IP가 IPv4만 사용하고 듀얼 스택은 사용하지 않는 경우 **IPv6**에서 **끄기**를 선택합니다.

배포 생성을 완료합니다. 필요에 따라 애니캐스트 고정 IP 목록에 필요하지 않은 다른 설정 및 구성을 선택할 수 있습니다.

애니캐스트 고정 IP 목록과 관련된 할당량에 대한 자세한 내용은 *AWS 일반 참조*의 [Amazon CloudFront endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/cf_region.html#limits_cloudfront)를 참조하시기 바랍니다.

## 애니캐스트 고정 IP 목록을 연결 그룹과 연결
<a name="associate-anycast-ip-connection-group"></a>

시작하기 전에 이전 섹션에 설명된 대로 애니캐스트 고정 IP 목록을 요청하고 만듭니다.

**애니캐스트 고정 IP 목록을 새 연결 그룹과 연결하려면**

1. **설정**에서 연결 그룹을 활성화했는지 확인합니다.

1. 연결 그룹을 생성합니다. 자세한 내용을 알아보려면 [사용자 지정 연결 그룹 생성](custom-connection-group.md) 섹션을 참조하세요.

1. **설정**에서 애니캐스트 고정 IP 목록을 사용하려면 다음을 선택해야 합니다.

   1. **애니캐스트 IP 목록**의 드롭다운 목록에서 애니캐스트 고정 IP 목록을 선택합니다.

1. 연결 그룹 생성을 완료합니다.

**참고**  
애니캐스트 고정 IP가 IPv4만 사용하고 듀얼 스택은 사용하지 않는 경우 **IPv6**에서 **끄기**를 선택합니다.

애니캐스트 고정 IP 목록과 관련된 할당량에 대한 자세한 내용은 *Amazon Web Services 일반 참조*의 [Amazon CloudFront endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/cf_region.html#limits_cloudfront)를 참조하시기 바랍니다.

## 애니캐스트 고정 IP 목록 업데이트
<a name="update-static-ip-list"></a>

애니캐스트 고정 IP 주소를 생성하고 배포에 연결한 후 애니캐스트 고정 IP 목록의 IP 주소 유형을 변경할 수 있습니다.

**애니캐스트 고정 IP 목록을 업데이트하려면**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **고정 IP**를 선택합니다.

1. 고정 IP 목록의 이름을 선택합니다.

1. **편집**을 선택합니다.

1. **IP 주소 유형**에서 다음 옵션 중 하나를 지정합니다.
   + **IPv4** - IPv4 주소 목록만 할당 
   + **듀얼 스택** - IPv4 및 IPv6 주소 목록 할당
**참고**  
연결된 배포에서 이미 IPv6를 활성화한 경우 **IPv4**를 선택할 수 없습니다. 이렇게 하려면 애니캐스트 고정 IP의 IP 주소 유형을 업데이트하기 전에 IPv6를 비활성화합니다. 자세한 내용은 [CloudFront 배포에 IPv6 활성화](cloudfront-enable-ipv6.md) 섹션을 참조하세요.

1. **제출**을 선택하여 변경 사항을 저장하고 애니캐스트 고정 IP 목록을 업데이트합니다.

# IPAM을 사용하여 CloudFront로 자체 IP 가져오기
<a name="bring-your-own-ip-address-using-ipam"></a>

이 자습서에서는 IPAM을 사용하여 CloudFront 애니캐스트 정적 IP 목록에 대한 BYOIP CIDR을 관리하는 방법을 알아봅니다.

**Topics**
+ [애니캐스트 고정 IP의 BYOIP란 무엇입니까?](#what-is-byoip-anycast)
+ [이 기능을 사용하는 이유는 무엇인가요?](#why-use-byoip)
+ [사전 조건](#byoip-prerequisites)
+ [1단계: 애니캐스트 고정 IP 목록 요청](#request-anycast-static-ip-list)
+ [2단계: 애니캐스트 고정 IP 목록 생성](#create-anycast-static-ip-list)
+ [3단계: CloudFront 배포 생성](#create-cloudfront-distribution)
+ [4단계: CloudFront 리소스와 연결](#associate-with-cloudfront-resources)
+ [5단계: 마이그레이션 준비](#prepare-for-migration)
+ [6단계: CIDR을 전역에 보급](#advertise-cidr-globally)

## 애니캐스트 고정 IP의 BYOIP란 무엇입니까?
<a name="what-is-byoip-anycast"></a>

CloudFront는 글로벌 서비스에 대한 IPAM의 BYOIP를 통해 자체 IPv4 주소 가져오기를 지원합니다. IPAM의 통합 인터페이스를 통해 고객은 자체 IP 주소(BYOIP)를 사용하여 전용 IP 주소 풀을 생성하고 CloudFront 배포에 할당하는 동시에 AWS 전 세계 콘텐츠 전송 네트워크를 활용하여 애플리케이션과 콘텐츠를 제공할 수 있습니다. IP 주소는 애니캐스트 라우팅을 사용하여 여러 CloudFront 엣지 로케이션에서 동시에 광고됩니다.

## 이 기능을 사용하는 이유는 무엇인가요?
<a name="why-use-byoip"></a>

**허용 목록에서 네트워크 액세스를 제어하여 다음을 수행합니다.**
+ 승인된 뷰어에 대한 데이터 요금을 면제하기 위해 네트워크 공급자와의 IP 주소 허용 목록
+ 승인된 애플리케이션으로만 트래픽을 제한하도록 아웃바운드 보안 방화벽 구성

**운영 및 마이그레이션 간소화**
+ 고정 IP를 가리키는 A 레코드를 추가하여 Apex 도메인(example.com)을 CloudFront로 직접 라우팅
+ IP 인프라 또는 방화벽 구성을 업데이트하지 않고 다른 CDN에서 마이그레이션
+ 파트너 및 클라이언트와 기존 IP 허용 목록 유지
+ 여러 CloudFront 배포에서 단일 애니캐스트 고정 IP 목록 공유

**일관된 브랜딩**
+ AWS로 이동할 때 일관된 브랜딩을 위해 기존 IP 주소 공간을 유지합니다.

## 사전 조건
<a name="byoip-prerequisites"></a>

CloudFront 배포에서 애니캐스트 고정 IP 목록을 사용하려면 배포의 가격 등급에 대해 **모든 엣지 로케이션 사용**을 선택해야 합니다. 요금에 대한 자세한 내용은 [CloudFront 요금](https://aws.amazon.com/cloudfront/pricing/)을 참조하시기 바랍니다. Bring Your Own IP(BYOIP)의 경우 배포 또는 연결 그룹에 대해 IPv6도 비활성화해야 합니다.

시작하기 전에 다음 단계를 완료합니다.
+ IPAM 설정: [IPAM을 계정과 통합](https://docs.aws.amazon.com/vpc/latest/ipam/enable-integ-ipam.html) 및 [IPAM 생성](https://docs.aws.amazon.com/vpc/latest/ipam/create-ipam.html)을 참조하세요.
+ 도메인 확인: [도메인 제어를 확인합니다](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-ipam-domain-verification-methods.html).
+ 최상위 풀 생성: [IPAM에 자체 IPv4 CIDR 가져오기](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-ipam-console-ipv4.html)의 1\$12단계를 따릅니다.
+ CloudFront에서 사용할 글로벌 로캘로 IPAM 풀을 생성합니다. 자세한 내용은 [IPAM을 사용하여 자체 IP를 CloudFront로 가져오기](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-cloudfront.html)를 참조하세요.

**참고**  
**3개의 /24** IPv4 CIDR 블록이 필요합니다.

## 1단계: 애니캐스트 고정 IP 목록 요청
<a name="request-anycast-static-ip-list"></a>

CloudFront 배포에 사용할 애니캐스트 고정 IP 목록을 요청합니다.<a name="request-anycast-static-ip-list-procedure"></a>

**애니캐스트 고정 IP 목록을 요청하려면 다음과 같이 합니다.**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **고정 IP**를 선택합니다.

1. **요청**에서 CloudFront 지원 엔지니어링 팀에 문의할 수 있는 링크를 선택합니다.

1. 워크로드 정보(초당 요청 바이트 수 및 초당 요청 수)를 제공합니다.

1. CloudFront 지원 엔지니어링 팀에서는 요청을 검토합니다. 검토 프로세스는 최대 2일이 걸릴 수 있습니다.

1. 요청이 승인되면 애니캐스트 고정 IP 목록을 만들어 하나 이상의 배포와 연결할 수 있습니다.

## 2단계: 애니캐스트 고정 IP 목록 생성
<a name="create-anycast-static-ip-list"></a>

시작하기 전에 이전 섹션에 설명된 대로 애니캐스트 고정 IP 목록을 요청합니다.<a name="create-anycast-static-ip-list-procedure"></a>

**애니캐스트 고정 IP 목록을 만들려면 다음과 같이 합니다.**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **고정 IP**를 선택합니다.

1. **애니캐스트 IP 목록 생성**을 선택합니다.

1. **이름**에 이름을 입력합니다.

1. **고정 IP 사용 사례**에서 사용 사례로 **BYOIP**를 선택합니다.

다음 단계는 표준 리전 BYOIP 프로세스와 다르며 글로벌 서비스에 대한 패턴을 설정합니다.

### AWS CLI
<a name="create-anycast-cli"></a>

최신 버전의 AWS CLI를 설치 또는 업데이트합니다. 자세한 내용은 [AWS Command Line Interface 사용 설명서](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.

1. CIDR 블록이 프로비저닝된 IPAM 풀의 IpamPoolArn을 검색합니다. 자세한 내용은 [AWS CLI만 사용하여 IPAM으로 고유 퍼블릭 IPv4 CIDR 가져오기](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-ipam-ipv4.html)를 참조하세요.

1. CIDR 블록 및 IPAM 구성을 사용하여 애니캐스트 IP 목록을 생성합니다.

   ```
   aws cloudfront create-anycast-ip-list \
       --name byoip-aip-1 \
       --ip-count 3 \
       --region us-east-1 \
       --ip-address-type ipv4 \
       --ipam-cidr-configs '[{"Cidr":"1.1.1.0/24","IpamPoolArn":"arn:aws:ec2::123456789012:ipam-pool/ipam-pool-005d58a8aa8147abc"},{"Cidr":"2.2.2.0/24","IpamPoolArn":"arn:aws:ec2::123456789012:ipam-pool/ipam-pool-005d58a8aa8147abc"},{"Cidr":"3.3.3.0/24","IpamPoolArn":"arn:aws:ec2::123456789012:ipam-pool/ipam-pool-005d58a8aa8147abc"}]'
   ```

**참고**  
풀에서 특정 IP 주소를 선택할 수 없습니다. CloudFront는 이를 자동으로 수행합니다.

## 3단계: CloudFront 배포 생성
<a name="create-cloudfront-distribution"></a>

CloudFront의 경우 지침에 따라 [표준 배포를 생성](distribution-web-creating-console.md)하거나 [다중 테넌트 배포](distribution-config-options.md)를 사용할 수 있습니다.

## 4단계: CloudFront 리소스와 연결
<a name="associate-with-cloudfront-resources"></a>
+ [애니캐스트 고정 IP 목록을 기존 배포와 연결](request-static-ips.md#associate-static-ip-list-existing)
+ [애니캐스트 고정 IP 목록을 새 배포와 연결](request-static-ips.md#associate-static-ip-list-new)
+ [애니캐스트 고정 IP 목록을 연결 그룹과 연결](request-static-ips.md#associate-anycast-ip-connection-group)

## 5단계: 마이그레이션 준비
<a name="prepare-for-migration"></a>

자세한 내용은 *Amazon VPC 사용 설명서*의 [4단계: 마이그레이션 준비](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-cloudfront.html#step-4-prepare-for-migration)를 참조하세요.

## 6단계: CIDR을 전역에 보급
<a name="advertise-cidr-globally"></a>

자세한 내용은 *Amazon VPC 사용 설명서*의 [5단계: CIDR 글로벌 알림](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-cloudfront.html#step-5-advertise-cidr-globally)을 참조하세요.

# CloudFront 배포에 gRPC 사용
<a name="distribution-using-grpc"></a>

Amazon CloudFront는 HTTP/2를 기반으로 구축된 오픈 소스 원격 프로시저 호출(RPC) 프레임워크인 gRPC를 지원합니다. gRPC는 양방향 스트리밍 및 바이너리 프로토콜 버퍼 페이로드를 제공하므로 지연 시간이 짧은 통신이 필요한 애플리케이션에 적합합니다.

CloudFront는 gRPC 요청을 수신하여 오리진에 직접 프록시 처리합니다. CloudFront를 사용하여 다음 4가지 유형의 gRPC 서비스를 프록시 처리할 수 있습니다.
+ 단항 RPC
+ 서버 스트리밍 RPC
+ 클라이언트 스트리밍 RPC
+ 양방향 스트리밍 RPC

## CloudFront에서 gRPC가 작동하는 방식
<a name="how-grpc-works-cloudfront"></a>

CloudFront에서 gRPC를 구성하려면 gRPC 서비스를 제공하는 오리진을 배포의 오리진으로 설정합니다. 비 gRPC 서비스와 gRPC 서비스를 모두 제공하는 오리진을 사용할 수 있습니다. CloudFront는 수신 요청이 gRPC 요청인지 아니면 `Content-Type` 헤더를 기반으로 하는 HTTP/HTTPS 요청인지 확인합니다. 요청의 `Content-Type` 헤더 값이 `application/grpc`인 경우 요청이 gRPC 요청으로 간주되며 CloudFront는 해당 요청을 오리진으로 프록시 처리합니다.

**참고**  
배포에서 gRPC 요청을 처리하도록 사용 설정하려면 HTTP/2를 지원되는 HTTP 버전 중 하나로 포함하고 `POST`를 비롯한 HTTP 메서드를 허용해야 합니다. CloudFront는 보안(HTTPS 기반) gRPC 연결만 지원하므로 gRPC 오리진 엔드포인트는 HTTPS를 지원하도록 구성되어야 합니다. gRPC는 엔드 투 엔드 HTTPS만 지원합니다. 사용자 지정 오리진을 사용하는 경우 [프로토콜](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) 설정이 HTTPS를 지원하는지 확인합니다.

배포에서 gRPC 지원을 사용 설정하려면 다음 단계를 완료합니다.

1. 배포의 캐시 동작을 업데이트하여 `POST` 메서드를 포함한 HTTP 메서드를 허용합니다.

1. `POST` 메서드를 선택한 후 나타나는 gRPC 확인란을 선택합니다.

1. **HTTP/2**를 지원되는 HTTP 버전 중 하나로 지정합니다.

자세한 내용은 다음 항목을 참조하세요.
+ [HTTP/2를 통한 gRPC 요청 허용](DownloadDistValuesCacheBehavior.md#enable-grpc-distribution)
+ *Amazon CloudFront API 참조*의 [GrpcConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_GrpcConfig.html)

gRPC는 캐시할 수 없는 API 트래픽에만 사용되므로 캐시 구성은 gRPC 요청에 영향을 주지 않습니다. gRPC 오리진으로 전송된 gRPC 요청에 사용자 지정 헤더를 추가하는 데 오리진 요청 정책을 사용할 수 있습니다. CloudFront와 함께 AWS WAF를 사용하여 gRPC 배포에 대한 액세스를 관리하고, 봇을 제어하고, 웹 익스플로잇으로부터 gRPC 애플리케이션을 보호할 수 있습니다. CloudFront gRPC는 [CloudFront Functions](cloudfront-functions.md)을 지원합니다.

HTTPS 상태 외에도 gRPC 응답과 함께 grpc-status를 받게 됩니다. grpc-status에 사용할 수 있는 값 목록은 [Status codes and their use in gRPC](https://grpc.github.io/grpc/core/md_doc_statuscodes.html)를 참조하시기 바랍니다.

**참고**  
gRPC는 다음의 CloudFront 기능을 지원하지 않습니다.  
[사용자 지정 오류 응답](GeneratingCustomErrorResponses.md)
 gRPC는 `POST` 메서드를 사용하므로 [오리진 장애 조치](high_availability_origin_failover.md)는 gRPC에서 지원되지 않습니다. CloudFront는 최종 사용자 요청의 HTTP 메서드가 `GET`, `HEAD` 또는 `OPTIONS`인 경우에만 보조 오리진으로 장애 조치합니다.
CloudFront는 gRPC 요청을 오리진으로 직접 프록시 처리하고 리전 엣지 캐시(REC)를 우회합니다. gRPC는 REC를 우회하기 때문에 gRPC는 [Lambda@Edge](lambda-at-the-edge.md) 또는 [Origin Shield](origin-shield.md)를 지원하지 않습니다.
gRPC는 AWS WAF 요청 본문 검사 규칙을 지원하지 않습니다. 배포의 웹 ACL에서 이러한 규칙을 사용 설정한 경우 gRPC를 사용하는 모든 요청은 요청 본문 검사 규칙을 무시합니다. 모든 다른 AWS WAF 규칙은 계속 적용됩니다. 자세한 내용은 [배포에 AWS WAF 활성화](WAF-one-click.md) 섹션을 참조하세요.