# 캐싱 및 가용성 CloudFront를 사용하여 오리진 서버에서 직접 응답해야 하는 요청의 수를 줄일 수 있습니다. CloudFront 캐싱을 사용하면 사용자에게 더 가까운 CloudFront 엣지 로케이션에서 더 많은 객체가 제공됩니다. 따라서 오리진 서버에 걸리는 부하가 줄어들고 지연 시간이 단축됩니다. 엣지 캐시에서 CloudFront가 처리할 수 있는 요청이 많을수록 객체의 최신 버전 또는 고유한 버전을 얻기 위해 CloudFront가 오리진에 전달해야 하는 최종 사용자 요청 수가 줄어듭니다. 오리진에 최대한 적게 요청하도록 CloudFront를 최적화하려면 CloudFront Origin Shield 사용을 고려해 보십시오. 자세한 내용은 [Amazon CloudFront Origin Shield 사용](origin-shield.md) 단원을 참조하세요. 모든 요청과 비교하여 CloudFront 캐시에서 직접 처리되는 요청의 비율을 *캐시 적중률*이라고 합니다. CloudFront 콘솔에서 최종 사용자 요청의 적중, 누락, 오류 백분율을 확인할 수 있습니다. 자세한 내용은 [CloudFront 캐시 통계 보고서 보기](cache-statistics.md) 단원을 참조하세요. 적중률에 영향을 주는 요인은 매우 많습니다. [CloudFront 캐시에서 직접 처리되는 요청의 비율 증가(캐시 적중률)](cache-hit-ratio.md)의 지침을 수행하여 CloudFront 배포 구성을 조정하고 적중률을 높일 수 있습니다. CloudFront가 제공하게 하려는 콘텐츠를 추가하고 제거하는 방법을 알아보려면 [CloudFront가 배포하는 콘텐츠 추가, 제거 또는 교체](AddRemoveReplaceObjects.md) 단원을 참조하십시오. **Topics** + [ # CloudFront 캐시에서 직접 처리되는 요청의 비율 증가(캐시 적중률) ](cache-hit-ratio.md) + [ # Amazon CloudFront Origin Shield 사용 ](origin-shield.md) + [ # CloudFront 오리진 장애 조치를 통한 고가용성 최적화 ](high_availability_origin_failover.md) + [ # 콘텐츠가 캐시에 유지되는 기간(만료) 관리 ](Expiration.md) + [ # 쿼리 문자열 파라미터 기반의 콘텐츠 캐싱 ](QueryStringParameters.md) + [ # 쿠키 기반의 콘텐츠 캐싱 ](Cookies.md) + [ # 요청 헤더 기반의 콘텐츠 캐싱 ](header-caching.md) # CloudFront 캐시에서 직접 처리되는 요청의 비율 증가(캐시 적중률) 오리진 서버에서 콘텐츠를 제공하는 대신 CloudFront 캐시에서 직접 콘텐츠를 제공하는 최종 사용자 요청의 비율을 높임으로써 성능을 향상시킬 수 있습니다. 이를 캐시 적중률 개선이라고 합니다. 다음 섹션에서는 캐시 적중률을 개선하는 방법을 설명합니다. **Topics** + [ ## CloudFront에서 객체를 캐싱하는 시간 지정 ](#cache-hit-ratio-duration) + [ ## Origin Shield 사용 ](#cache-hit-ratio-use-origin-shield) + [ ## 쿼리 문자열 파라미터 기반 캐싱 ](#cache-hit-ratio-query-string-parameters) + [ ## 쿠키 값 기반 캐싱 ](#cache-hit-ratio-cookies) + [ ## 요청 헤더 기반 캐싱 ](#cache-hit-ratio-request-headers) + [ ## 압축이 불필요할 때 `Accept-Encoding` 헤더 제거 ](#cache-hit-ratio-remove-accept-encoding) + [ ## HTTP를 통한 미디어 콘텐츠 제공 ](#cache-hit-ratio-http-streaming) ## CloudFront에서 객체를 캐싱하는 시간 지정 캐시 적중률을 높이기 위해 객체에 [Cache-Control max-age](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) 명령을 추가하도록 오리진을 구성하고 `max-age`에 실질적으로 가장 긴 값을 지정할 수 있습니다. 캐시 주기가 짧을수록 CloudFront에서는 요청을 오리진에 더 자주 보내서 객체가 변경되었는지 여부를 확인하고 최신 버전을 가져옵니다. `max-age`를 `stale-while-revalidate` 및 `stale-if-error` 지시문으로 보완하여 특정 조건에서 캐시 적중률을 더욱 개선할 수 있습니다. 자세한 내용은 [콘텐츠가 캐시에 유지되는 기간(만료) 관리](Expiration.md) 섹션을 참조하세요. ## Origin Shield 사용 CloudFront Origin Shield는 오리진 앞에 캐싱의 추가 계층을 제공하기 때문에 CloudFront 배포의 캐시 적중률을 개선하는 데 도움이 됩니다. Origin Shield를 사용하면 CloudFront의 모든 캐싱 계층에서 오리진에 이르는 모든 요청은 단일 위치에서 이루어집니다. CloudFront는 Origin Shield의 단일 오리진 요청을 사용하여 각 객체를 검색할 수 있으며 CloudFront 캐시의 다른 모든 계층(엣지 로케이션 및 [리전 엣지 캐시](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches))은 Origin Shield에서 객체를 검색할 수 있습니다. 자세한 내용은 [Amazon CloudFront Origin Shield 사용](origin-shield.md) 단원을 참조하세요. ## 쿼리 문자열 파라미터 기반 캐싱 쿼리 문자열 파라미터를 기반으로 캐싱하도록 CloudFront를 구성한 경우, 다음을 수행하면 캐싱 성능을 개선할 수 있습니다. + 오리진에서 고유한 객체를 반환하는 쿼리 문자열 파라미터만 전달하도록 CloudFront를 구성합니다. + 동일 파라미터의 전체 인스턴스에 대해서는 대문자 또는 소문자만 사용합니다. 예를 들어 하나의 요청에 `parameter1=A`가 포함되어 있고 다른 요청에는 `parameter1=a`가 포함된 경우, CloudFront에서는 요청에 `parameter1=A`가 포함되었을 때와 `parameter1=a`가 포함되었을 때 각각 별도의 요청을 오리진에 전달합니다. 그런 다음 CloudFront는 오리진에서 개별적으로 반환된 해당 객체를 별도로 캐싱합니다. 이는 이러한 객체가 실제로는 동일하더라도 마찬가지입니다. `A` 또는 `a`만 사용하는 경우, CloudFront에서는 오리진에 더 적은 요청을 전달하게 됩니다. + 파라미터를 같은 순서로 나열합니다. 다른 순서로 나열하는 경우, 객체에 대한 하나의 요청에 쿼리 문자열 `parameter1=a¶meter2=b`가 포함되어 있고 같은 객체의 다른 요청에는 `parameter2=b¶meter1=a`가 포함되어 있다면, CloudFront에서는 두 요청을 오리진에 모두 전달하고 해당 객체가 실제로는 동일한 경우라도 이를 개별적으로 캐싱합니다. 파라미터에 언제나 같은 순서를 사용한다면 CloudFront에서는 오리진에 더 적은 요청을 전달하게 됩니다. 자세한 내용은 [쿼리 문자열 파라미터 기반의 콘텐츠 캐싱](QueryStringParameters.md) 단원을 참조하세요. CloudFront에서 오리진에 전달한 쿼리 문자열을 검토하려는 경우, CloudFront 로그 파일에서 `cs-uri-query` 열의 값을 확인합니다. 자세한 내용은 [액세스 로그(표준 로그)](AccessLogs.md) 단원을 참조하세요. ## 쿠키 값 기반 캐싱 쿠키 값을 기반으로 캐싱하도록 CloudFront를 구성한 경우, 다음을 수행하면 캐싱 성능을 개선할 수 있습니다. + 전체 쿠키를 전달하는 대신 지정된 쿠키만 전달하도록 CloudFront를 구성합니다. CloudFront가 오리진에 전달하도록 구성하는 쿠키의 경우 CloudFront에서 쿠키 이름과 값의 모든 조합을 전달합니다. 그런 다음 오리진이 반환하는 객체를 별도로 캐시합니다(객체가 모두 동일한 경우도 마찬가지). 예를 들어, 최종 사용자가 각 요청에 두 개의 쿠키를 포함했다고 가정하면, 각 쿠키는 3가지 값을 가질 수 있으며 이 모든 쿠키 값의 조합이 가능합니다. CloudFront에서는 각 객체의 오리진에 최대 9개의 다양한 요청을 전달합니다. 오리진에서 오직 하나의 쿠키를 기반으로 서로 다른 버전의 객체를 반환하는 경우, CloudFront에서는 오리진에 필요한 것 이상의 요청을 전달하게 되며 불필요하게 동일한 버전의 객체를 여러 번 캐싱하게 됩니다. + 정적 콘텐츠와 동적 콘텐츠의 캐시 동작을 별도로 만들고 오리진에는 동적 콘텐츠에 대해서만 쿠키를 전달하도록 CloudFront를 구성합니다. 예를 들어, 배포에 대한 하나의 캐시 동작이 있고 `.js` 파일 및 `.css` 파일과 같은 거의 변동이 없는 두 동적 콘텐츠에 대한 배포를 사용 중이라고 가정합니다. CloudFront에서는 쿠키 값을 바탕으로 `.css` 파일의 개별 버전을 캐싱하여 각 CloudFront 엣지 로케이션에서 각각의 새 쿠키 값 또는 쿠키 값들의 조합에 대한 요청을 오리진에 전달하도록 합니다. 경로 패턴이 `*.css`이고 CloudFront에서 쿠키 값에 따라 캐싱하지 않는 캐시 동작을 만든 경우, CloudFront에서는 `.css` 파일에 대한 요청 중 엣지 로케이션에서 수신하는 지정된 `.css` 파일에 대한 첫 번째 요청과 `.css` 파일이 만료된 후의 첫 번째 요청만 오리진에 전달합니다. + 가능한 경우, 각 사용자(예: 사용자 ID)별로 쿠키 값이 고유한 동적 콘텐츠에 대해서와 더 작은 수의 고유 값에 따라 달라지는 동적 콘텐츠에 대해서 별도의 캐시 동작을 만듭니다. 자세한 내용은 [쿠키 기반의 콘텐츠 캐싱](Cookies.md) 단원을 참조하세요. CloudFront에서 오리진에 전달한 쿠키를 검토하려는 경우, CloudFront 로그 파일에서 `cs(Cookie)` 열의 값을 확인합니다. 자세한 내용은 [액세스 로그(표준 로그)](AccessLogs.md) 단원을 참조하세요. ## 요청 헤더 기반 캐싱 요청 헤더를 기반으로 캐싱하도록 CloudFront를 구성한 경우, 다음을 수행하면 캐싱 성능을 개선할 수 있습니다. + 전체 헤더를 기반으로 전달 및 캐싱하는 대신 지정된 헤더를 기반으로만 전달하고 캐싱하도록 CloudFront를 구성합니다. 지정한 헤더의 경우 CloudFront에서 헤더 이름과 값의 모든 조합을 전달합니다. 그런 다음 오리진이 반환하는 객체를 별도로 캐시합니다(객체가 모두 동일한 경우도 마찬가지). **참고** CloudFront에서는 다음 주제에서 지정한 헤더를 오리진에 항상 전달합니다. CloudFront에서 요청을 처리하고 Amazon S3 오리진 서버에 요청을 전달하는 방법> [CloudFront에서 제거하거나 업데이트하는 HTTP 요청 헤더](RequestAndResponseBehaviorS3Origin.md#request-s3-removed-headers) CloudFront에서 요청을 처리하고 사용자 지정 오리진 서버에 요청을 전달하는 방법 > [HTTP 요청 헤더 및 CloudFront 동작(사용자 지정 및 Amazon S3 오리진)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior) 요청 헤더에 따라 캐싱하도록 CloudFront를 구성한 경우, CloudFront에서 헤더 값에 따라 객체를 캐싱하는 경우를 제외하고는 CloudFront에서 전달하는 헤더를 변경하지 않습니다. + 큰 수의 고유 값을 갖는 요청 헤더를 기반으로 캐싱하지 않도록 하십시오. 예를 들어 사용자 디바이스에 따라 서로 다른 크기의 이미지를 제공하려는 경우, 매우 큰 값을 가질 수 있는 `User-Agent` 헤더를 기반으로 캐싱하도록 CloudFront를 구성하지 마십시오. 대신 CloudFront 디바이스 유형 헤더인 `CloudFront-Is-Desktop-Viewer`, `CloudFront-Is-Mobile-Viewer`, `CloudFront-Is-SmartTV-Viewer` 및 `CloudFront-Is-Tablet-Viewer`를 기반으로 캐싱하도록 CloudFront를 구성하십시오. 또한 태블릿과 데스크톱에 대해 같은 버전의 이미지를 반환하려는 경우, `CloudFront-Is-Tablet-Viewer` 헤더가 아닌 `CloudFront-Is-Desktop-Viewer` 헤더만 전달하세요. 자세한 내용은 [요청 헤더 기반의 콘텐츠 캐싱](header-caching.md) 섹션을 참조하세요. ## 압축이 불필요할 때 `Accept-Encoding` 헤더 제거 압축이 오리진이나 CloudFront에서 지원되지 않거나 압축 자체가 불가한 콘텐츠라서 압축 활성화가 어렵다면 다음과 같이 Custom Origin Header를 설정하는 오리진에 배포의 캐시 동작을 연결하여 캐시 적중률을 높일 수 있습니다. + **Header name(헤더 이름**)`Accept-Encoding`: + **Header value(헤더 값)**: (공백으로 유지) 이 구성을 사용하면 CloudFront가 캐시 키에서 `Accept-Encoding` 헤더를 제거하며 오리진 요청에 해당 헤더를 포함하지 않습니다. 이 구성은 CloudFront가 해당 오리진에서의 배포를 통해 제공하는 모든 콘텐츠에 적용됩니다. ## HTTP를 통한 미디어 콘텐츠 제공 온디맨드 비디오(VOD) 및 스트리밍 비디오 콘텐츠를 최적화하는 방법에 대한 자세한 내용은 [CloudFront를 사용한 온디맨드 비디오 및 라이브 스트리밍 비디오](on-demand-streaming-video.md) 단원을 참조하십시오. # Amazon CloudFront Origin Shield 사용 CloudFront Origin Shield는 CloudFront 캐싱 인프라의 추가 계층으로 오리진의 부하를 최소화하고 가용성을 높이며 운영 비용을 절감하는 데 도움이 됩니다. CloudFront Origin Shield를 사용하면 다음과 같은 이점을 얻을 수 있습니다. **향상된 캐시 적중률** Origin Shield는 오리진 앞에 캐싱의 추가 계층을 제공하기 때문에 CloudFront 배포의 캐시 적중률을 개선하는 데 도움이 됩니다. Origin Shield를 사용하면 모든 CloudFront의 캐싱 계층에서 오리진에 이르는 모든 요청이 Origin Shield를 통과하여 캐시 적중 가능성을 높입니다. CloudFront는 Origin Shield에서 오리진으로의 단일 오리진 요청을 사용하여 각 객체를 검색할 수 있으며 CloudFront 캐시의 다른 모든 계층(엣지 로케이션 및 [리전 엣지 캐시](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches))은 Origin Shield에서 객체를 검색할 수 있습니다. **오리진 부하 감소** Origin Shield는 동일한 객체에 대해 오리진으로 전송되는 [동시 요청](RequestAndResponseBehaviorCustomOrigin.md#request-custom-traffic-spikes) 수를 추가로 줄일 수 있습니다. Origin Shield의 캐시에 없는 콘텐츠에 대한 요청은 동일한 객체에 대한 다른 요청과 통합되어 오리진에 대한 요청이 하나만 발생합니다. 오리진에서 요청을 적게 처리하면 최대 부하 또는 예기치 않은 트래픽 급증 시에도 오리진의 가용성을 유지할 수 있으며, JIT(Just-in-time) 패키징, 이미지 변환 및 DTO(데이터 송신)와 같은 비용을 절감할 수 있습니다. **향상된 네트워크 성능** [오리진에 대한 대기 시간이 가장 짧은](#choose-origin-shield-region) AWS 리전에서 Origin Shield를 활성화하면 향상된 네트워크 성능을 얻을 수 있습니다. AWS 리전의 오리진의 경우 CloudFront 네트워크 트래픽은 오리진에 이르기까지 처리량이 높은 CloudFront 네트워크에 남아 있습니다. AWS 외부에 있는 오리진의 경우 CloudFront 네트워크 트래픽은 오리진에 대한 연결 대기 시간이 짧은 Origin Shield에 이르기까지 CloudFront 네트워크에 남아 있습니다. Origin Shield 사용 시 추가 요금이 발생합니다. 자세한 내용은 [CloudFront 요금](https://aws.amazon.com/cloudfront/pricing/)을 참조하십시오. **참고** Origin Shield는 gRPC 요청에서 지원되지 않습니다. gRPC를 지원하는 배포에 Origin Shield가 사용 설정된 경우 gRPC 요청은 계속 작동합니다. 하지만 요청은 Origin Shield를 통과하지 않고 gRPC 오리진으로 직접 프록시됩니다. 자세한 내용은 [CloudFront 배포에 gRPC 사용](distribution-using-grpc.md) 섹션을 참조하세요. **Topics** + [ ## Origin Shield 사용 사례 ](#origin-shield-use-cases) + [ ## Origin Shield의 AWS 리전 선택 ](#choose-origin-shield-region) + [ ## Origin Shield 사용 ](#enable-origin-shield) + [ ## Origin Shield 비용 추정 ](#origin-shield-costs) + [ ## Origin Shield 고가용성 ](#origin-shield-high-availability) + [ ## Origin Shield가 다른 CloudFront 기능과 상호 작용하는 방법 ](#origin-shield-and-other-features) ## Origin Shield 사용 사례 CloudFront Origin Shield는 다음과 같은 많은 사용 사례에 도움이 될 수 있습니다. + 서로 다른 지리적 리전에 분산되어 있는 최종 사용자 + 라이브 스트리밍 또는 즉석 이미지 처리를 위한 JIT(Just-in-time) 패키징을 제공하는 오리진 + 용량 또는 대역폭 제약이 있는 온프레미스 오리진 + 여러 CDN(콘텐츠 전송 네트워크)을 사용하는 워크로드 Origin Shield는 오리진으로 프록시되는 동적 콘텐츠, 캐시 가능성이 낮은 콘텐츠, 자주 요청되지 않는 콘텐츠 등 다른 경우에는 적합하지 않을 수 있습니다. 다음 섹션에서는 다음과 같은 사용 사례에 대한 Origin Shield의 이점에 대해 설명합니다. **Topics** + [ ### 서로 다른 지리적 리전의 최종 사용자 ](#os-use-cases-global-viewers) + [ ### 여러 CDN ](#os-use-cases-multi-cdn) ### 서로 다른 지리적 리전의 최종 사용자 Amazon CloudFront를 사용하면 CloudFront가 캐시에서 처리할 수 있는 요청이 오리진으로 이동하지 않기 때문에 본질적으로 오리진의 부하를 줄일 수 있습니다. CloudFront의 [엣지 로케이션의 글로벌 네트워크](https://aws.amazon.com/cloudfront/features/#Amazon_CloudFront_Infrastructure) 외에도 [리전 엣지 캐시](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)는 미드티어 캐싱 계층 역할을 하여 가까운 지리적 리전의 최종 사용자에 대한 캐시 적중을 제공하고 오리진 요청을 통합합니다. 최종 사용자 요청은 먼저 가까운 CloudFront 엣지 로케이션으로 라우팅되며 객체가 해당 위치에 캐싱되지 않으면 요청이 리전 엣지 캐시로 전송됩니다. 최종 사용자가 서로 다른 지리적 리전에 있는 경우 요청을 서로 다른 리전 엣지 캐시를 통해 라우팅할 수 있으며, 각 캐시에서는 동일한 콘텐츠에 대한 요청을 오리진에 보낼 수 있습니다. 하지만 Origin Shield를 사용하면 리전 엣지 캐시와 오리진 사이에 추가 캐싱 계층이 생깁니다. 모든 리전 엣지 캐시의 모든 요청은 Origin Shield를 통과하여 오리진의 부하를 더욱 줄입니다. 다음 다이어그램에서는 이 개념을 보여줍니다. 다음 다이어그램에서 오리진은 AWS Elemental MediaPackage입니다. **Origin Shield 미사용** Origin Shield를 사용하지 않으면 다음 다이어그램과 같이 오리진에서 동일한 콘텐츠에 대한 중복 요청을 수신할 수 있습니다. ![\[CloudFront Origin Shield를 사용하지 않으면 오리진에서 중복 요청을 수신할 수 있습니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without.png) **Origin Shield 사용** Origin Shield를 사용하면 다음 다이어그램과 같이 오리진의 부하를 줄일 수 있습니다. ![\[CloudFront Origin Shield를 사용하면 오리진에서 중복 요청을 더 적게 수신할 수 있습니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with.png) ### 여러 CDN 라이브 동영상 이벤트 또는 인기 있는 주문형 콘텐츠를 제공하기 위해 여러 CDN(콘텐츠 전송 네트워크)을 사용할 수 있습니다. 여러 CDN을 사용하면 특정 이점을 얻을 수 있지만 오리진에서는 동일한 콘텐츠에 대해 여러 개의 중복 요청을 수신할 수 있습니다. 각 요청은 서로 다른 CDN 또는 동일한 CDN 내의 다른 위치에서 발생합니다. 이러한 중복 요청은 오리진의 가용성에 부정적인 영향을 미치거나 JIT(Just-in-time) 패키징 또는 DTO(데이터 송신)와 같은 프로세스에 추가적인 운영 비용을 야기할 수 있습니다. 다른 CDN의 오리진으로 CloudFront 배포를 사용하여 Origin Shield를 결합하면 다음과 같은 이점을 얻을 수 있습니다. + 오리진에서 수신되는 중복 요청 수가 적기 때문에 여러 CDN을 사용할 때의 부정적인 영향을 줄일 수 있습니다. + CDN 전반의 공통 [캐시 키](controlling-the-cache-key.md) 및 오리진 방향 기능을 위한 중앙 집중식 관리. + 네트워크 성능이 향상되었습니다. 다른 CDN의 네트워크 트래픽은 가까운 CloudFront 엣지 로케이션에서 종료되어 로컬 캐시에서 적중을 제공할 수 있습니다. 요청된 객체가 엣지 로케이션 캐시에 없는 경우 오리진에 대한 요청은 오리진에 대한 높은 처리량과 짧은 대기 시간을 제공하는 Origin Shield까지 CloudFront 네트워크에 남아 있습니다. 요청된 객체가 Origin Shield의 캐시에 있는 경우 오리진에 대한 요청은 완전히 방지됩니다. **중요** 다중 CDN 아키텍처에서 Origin Shield를 사용하는 데 관심이 있고 요금을 할인받고 있는 경우 [AWS에 문의](https://aws.amazon.com/contact-us/)하거나 AWS 영업 담당자에게 연락하여 자세한 내용을 알아보세요. 추가 요금이 적용될 수 있습니다. 다음 다이어그램은 여러 CDN으로 인기 있는 라이브 동영상 이벤트를 제공할 때 이 구성을 통해 오리진의 부하를 최소화하는 방법을 보여줍니다. 다음 다이어그램에서 오리진은 AWS Elemental MediaPackage입니다. **Origin Shield 미사용(여러 CDN)** Origin Shield를 사용하지 않으면 다음 다이어그램과 같이 오리진에서 동일한 콘텐츠에 대해 각각 서로 다른 CDN에서 오는 여러 개의 중복 요청을 수신할 수 있습니다. ![\[오리진이 각각 서로 다른 CDN에서 오는 중복 요청을 수신할 수 있는 방법을 보여 주는 그림.\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without-multi-cdn.png) **Origin Shield 사용(여러 CDN)** Origin Shield를 사용하고 다른 CDN의 오리진으로 CloudFront를 함께 사용하면 다음 다이어그램과 같이 오리진의 부하를 줄일 수 있습니다. ![\[CloudFront Origin Shield에 수신되는 중복 요청 수가 더 적은 것을 보여 주는 그림.\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with-multi-cdn.png) ## Origin Shield의 AWS 리전 선택 Amazon CloudFront는 CloudFront에 [리전 엣지 캐시](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)가 있는 AWS 리전에서 Origin Shield를 제공합니다. Origin Shield를 활성화하면 Origin Shield에 대해 AWS 리전을 선택합니다. 오리진에 대한 지연 시간이 가장 짧은 AWS 리전을 선택해야 합니다. Origin Shield는 AWS 리전에 있는 오리진 및 AWS에 없는 오리진과 함께 사용할 수 있습니다. ### AWS 리전에 있는 오리진의 경우 오리진이 AWS 리전에 있는 경우 먼저 CloudFront가 Origin Shield를 제공하는 리전에 오리진이 있는지 확인합니다. CloudFront는 다음과 같은 AWS 리전에서 Origin Shield를 제공합니다. + 미국 동부(오하이오) – `us-east-2` + 미국 동부(버지니아 북부) – `us-east-1` + 미국 서부(오레곤) – `us-west-2` + 아시아 태평양(뭄바이) – `ap-south-1` + 아시아 태평양(서울) – `ap-northeast-2` + 아시아 태평양(싱가포르) – `ap-southeast-1` + 아시아 태평양(시드니) – `ap-southeast-2` + 아시아 태평양(도쿄) – `ap-northeast-1` + 유럽(프랑크푸르트) – `eu-central-1` + 유럽(아일랜드) – `eu-west-1` + 유럽(런던) – `eu-west-2` + 남아메리카(상파울루) – `sa-east-1` + 중동(UAE) - `me-central-1` **CloudFront가 Origin Shield를 제공하는 AWS 리전에 오리진이 있는 경우** CloudFront가 Origin Shield를 제공하는 AWS 리전에 오리진이 있는 경우(이전 목록 참조) 오리진과 동일한 리전에서 Origin Shield를 활성화합니다. **CloudFront가 Origin Shield를 제공하는 AWS 리전에 오리진이 없는 경우** CloudFront가 Origin Shield를 제공하는 AWS 리전에 오리진이 없는 경우 다음 표를 참조하여 Origin Shield를 활성화할 리전을 결정합니다. | **오리진이 다음에 있는 경우** | **Origin Shield 활성화** | | --- | --- | | 미국 서부(캘리포니아 북부) – `us-west-1` | 미국 서부(오레곤) – `us-west-2` | | 아프리카(케이프타운) – `af-south-1` | 유럽(아일랜드) – `eu-west-1` | | 아시아 태평양(홍콩) – `ap-east-1` | 아시아 태평양(싱가포르) – `ap-southeast-1` | | 캐나다(중부) – `ca-central-1` | 미국 동부(버지니아 북부) – `us-east-1` | | 유럽(밀라노) – `eu-south-1` | 유럽(프랑크푸르트) – `eu-central-1` | | 유럽(파리) – `eu-west-3` | 유럽(런던) – `eu-west-2` | | 유럽(스톡홀름) – `eu-north-1` | 유럽(런던) – `eu-west-2` | | 중동(바레인) – `me-south-1` | 아시아 태평양(뭄바이) – `ap-south-1` | ### 외부에 있는 오리진의 경우AWS Origin Shield는 온프레미스에 있거나 AWS 리전에 있지 않은 오리진과 함께 사용할 수 있습니다. 이 경우 오리진에 대한 지연 시간이 가장 짧은 AWS 리전에서 Origin Shield를 활성화합니다. 오리진에 대한 지연 시간이 가장 짧은 AWS 리전이 확실하지 않은 경우 다음 제안 사항을 사용하여 결정할 수 있습니다. + 오리진의 지리적 위치를 기준으로 오리진에 대한 지연 시간이 가장 짧은 AWS 리전을 대략적으로 알아보려면 이전 표를 참조하십시오. + 오리진과 지리적으로 가까운 몇 가지 다른 AWS 리전에서 Amazon EC2 인스턴스를 시작하고, `ping`을 사용하여 해당 리전과 오리진 간의 일반적인 네트워크 대기 시간을 측정하는 몇 가지 테스트를 실행할 수 있습니다. ## Origin Shield 사용 Origin Shield를 활성화하면 캐시 적중률을 개선하고 오리진의 부하를 줄이며 성능을 향상시킬 수 있습니다. Origin Shield를 활성화하려면 CloudFront 배포에서 오리진 설정을 변경합니다. Origin Shield는 오리진의 속성입니다. CloudFront 배포의 각 오리진에 대해 Origin Shield가 해당 오리진에 대해 최상의 성능을 제공하는 AWS 리전에서 Origin Shield를 별도로 활성화할 수 있습니다. CloudFront 콘솔, CloudFormation 또는 CloudFront API를 사용하여 Origin Shield를 활성화할 수 있습니다. ------ #### [ Console ] **기존 오리진에 대해 Origin Shield를 활성화하려면(콘솔)** 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. **Origin Shield 활성화**에 대해 **예**를 선택합니다. 1. **Origin Shield 리전**의 경우 Origin Shield를 활성화하려는 AWS 리전을 선택합니다. 리전 선택에 대한 도움말은 [Origin Shield의 AWS 리전 선택](#choose-origin-shield-region) 단원을 참조하십시오. 1. **변경 사항 저장**을 선택합니다. 배포 상태가 **배포됨**이면 Origin Shield가 준비됩니다. 이 작업에는 몇 분이 걸립니다. **새 오리진에 대해 Origin Shield를 활성화하려면(콘솔)** 1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다. 1. 기존 배포에서 새 오리진을 생성하려면 다음을 수행합니다. 1. 오리진을 생성할 배포를 선택합니다. 1. **오리진 생성**을 선택한 다음 3단계로 이동합니다. 새 표준 배포에서 새 오리진을 생성하려면 다음을 수행합니다. 1. 각 단계에 따라 콘솔에서 표준 배포를 생성합니다. 자세한 내용은 [콘솔에서 CloudFront 배포 생성](distribution-web-creating-console.md#create-console-distribution) 섹션을 참조하세요. 1. **설정** 섹션에서 **오리진 설정 사용자 지정**을 선택합니다. 3단계로 이동합니다. 1. **Origin Shield 활성화**에 대해 **예**를 선택합니다. 1. **Origin Shield 리전**의 경우 Origin Shield를 활성화하려는 AWS 리전을 선택합니다. 리전 선택에 대한 도움말은 [Origin Shield의 AWS 리전 선택](#choose-origin-shield-region) 단원을 참조하십시오. 1. 콘솔에서 각 단계에 따라 오리진 또는 배포 생성을 완료합니다. 배포 상태가 **배포됨**이면 Origin Shield가 준비됩니다. 이 작업에는 몇 분이 걸립니다. ------ #### [ CloudFormation ] CloudFormation에서 Origin Shield를 활성화하려면 `OriginShield` 리소스의 `Origin` 속성 유형에서 `AWS::CloudFront::Distribution` 속성을 사용합니다. `OriginShield` 속성을 기존 `Origin`에 추가하거나 새 `Origin`을 생성할 때 포함할 수 있습니다. 다음 예제에서는 미국 서부(오레곤) 리전(`OriginShield`)에서 `us-west-2`를 활성화하는 구문을 YAML 형식으로 보여줍니다. 리전 선택에 대한 도움말은 [Origin Shield의 AWS 리전 선택](#choose-origin-shield-region) 단원을 참조하십시오. 이 예제에서는 전체 `Origin` 리소스가 아니라 `AWS::CloudFront::Distribution` 속성 유형만 보여줍니다. ``` Origins: - DomainName: 3ae97e9482b0d011.mediapackage.us-west-2.amazonaws.com Id: Example-EMP-3ae97e9482b0d011 OriginShield: Enabled: true OriginShieldRegion: us-west-2 CustomOriginConfig: OriginProtocolPolicy: match-viewer OriginSSLProtocols: TLSv1 ``` 자세한 내용은 *AWS CloudFormation 사용 설명서*의 리소스 및 속성 참조 섹션에서 [AWS::CloudFront::Distribution Origin](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origin.html)을 참조하세요. ------ #### [ API ] AWS SDK 또는 AWS Command Line Interface(AWS CLI)를 사용하여 CloudFront API에서 Origin Shield를 활성화하려면 `OriginShield` 유형을 사용합니다. `OriginShield`의 `Origin`에서 `DistributionConfig`를 지정합니다. `OriginShield` 유형에 대한 자세한 내용은 *Amazon CloudFront API 참조*에서 다음 정보를 참조하십시오. + [OriginShield](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginShield.html)(유형) + [오리진](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_Origin.html)(유형) + [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html)(유형) + [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)(작업) + [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)(작업) 이러한 유형 및 작업을 사용하기 위한 특정 구문은 SDK, CLI 또는 API 클라이언트에 따라 다릅니다. 자세한 내용은 SDK, CLI 또는 클라이언트에 대한 참조 설명서를 참조하십시오. ------ ## Origin Shield 비용 추정 증분 계층인 Origin Shield로 이동하는 요청 수를 기준으로 Origin Shield에 대한 요금이 발생합니다. 오리진으로 프록시되는 동적(캐시할 수 없음) 요청의 경우 Origin Shield는 항상 증분 계층입니다. 동적 요청에는 `PUT`, `POST`, `PATCH`, `DELETE`와 같은 HTTP 메서드가 사용됩니다. `GET` 및 `HEAD`는 TTL 설정이 3600초 미만인 요청은 동적 요청으로 간주됩니다. 또한, `GET` 및 `HEAD`는 캐싱을 비활성화한 요청도 동적 요청으로 간주됩니다. 동적 요청에 대한 Origin Shield 요금을 추정하려면 다음 공식을 사용하십시오. 총 동적 요청 수 **x** 요청 10,000개당 Origin Shield 요금**/**10,000 HTTP 메서드 , `GET`, `HEAD`, 및 `OPTIONS`를 사용하는 비동적 요청의 경우 Origin Shield가 증분 계층이 되기도 합니다. Origin Shield를 활성화하면 Origin Shield에 대해 AWS 리전을 선택합니다. Origin Shield와 동일한 리전에 있는 [리전 엣지 캐시](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)로 자연스럽게 이동하는 요청의 경우 Origin Shield는 증분 계층이 아닙니다. 이러한 요청에는 Origin Shield 요금은 발생하지 않습니다. Origin Shield와 다른 리전에서 리전 엣지 캐시로 이동한 다음 Origin Shield로 이동하는 요청의 경우 Origin Shield는 증분 계층입니다. 이러한 요청에는 Origin Shield 요금이 발생합니다. 캐시 가능한 요청에 대한 Origin Shield의 요금을 추정하려면 다음 공식을 사용하십시오. 캐시 가능한 총 요청 수 **x**(1 - 캐시 적중률) **x** 다른 리전의 리전 엣지 캐시에서 Origin Shield로 이동하는 요청의 비율 **x** 요청 10,000개당 Origin Shield 요금**/**10,000 Origin Shield에 대한 요청 10,000개당 요금에 대한 자세한 내용은 [CloudFront 요금](https://aws.amazon.com/cloudfront/pricing/)을 참조하십시오. ## Origin Shield 고가용성 Origin Shield는 CloudFront의 [리전 엣지 캐시](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) 기능을 활용합니다. 이러한 각 엣지 캐시는 Auto-Scaling Amazon EC2 인스턴스의 플릿과 함께 최소 3개의 [가용 영역](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)을 사용하여 AWS 리전에서 빌드됩니다. 또한 CloudFront 위치와 Origin Shield 간의 연결에서는 각 요청에 활성 오류 추적 기능을 사용해 주 Origin Shield 위치를 사용할 수 없으면 요청을 보조 Origin Shield 위치로 자동 라우팅합니다. ## Origin Shield가 다른 CloudFront 기능과 상호 작용하는 방법 다음 섹션에서는 Origin Shield가 다른 CloudFront 기능과 상호 작용하는 방식에 대해 설명합니다. ### Origin Shield 및 CloudFront 로깅 Origin Shield가 요청을 처리한 시기를 확인하려면 다음 중 하나를 활성화해야 합니다. + [CloudFront 표준 로그(액세스 로그)](AccessLogs.md) 표준 로그는 무료로 제공됩니다. + [CloudFront 실시간 액세스 로그](real-time-logs.md). 실시간 액세스 로그 사용에 대한 추가 요금이 발생합니다. [Amazon CloudFront 요금](https://aws.amazon.com/cloudfront/pricing/)을 참조하십시오. Origin Shield의 캐시 적중은 CloudFront 로그의 `OriginShieldHit` 필드로 `x-edge-detailed-result-type`로 표시됩니다. Origin Shield는 Amazon CloudFront의 [리전 엣지 캐시](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)를 활용합니다. 요청이 CloudFront 엣지 로케이션에서 Origin Shield 역할을 하는 리전 엣지 캐시로 라우팅되는 경우, 로그에서 `Hit`가 아닌 `OriginShieldHit`로 보고됩니다. ### Origin Shield 및 오리진 그룹 Origin Shield는 [CloudFront 오리진 그룹](high_availability_origin_failover.md)과 호환됩니다. Origin Shield는 오리진의 속성이므로 오리진이 오리진 그룹의 일부인 경우에도 요청은 항상 각 오리진에 대해 Origin Shield를 통과합니다. 지정된 요청에 대해 CloudFront는 기본 오리진의 Origin Shield를 통해 오리진 그룹의 기본 오리진으로 요청을 라우팅합니다. 요청이 실패하면(오리진 그룹 장애 조치 기준에 따라) CloudFront는 보조 오리진의 Origin Shield를 통해 요청을 보조 오리진으로 라우팅합니다. ### Origin Shield 및 Lambda@Edge Origin Shield는 [Lambda@Edge](lambda-at-the-edge.md) 함수의 기능에 영향을 미치지 않지만 해당 함수가 실행되는 AWS 리전에 영향을 줄 수 있습니다. Lambda@Edge와 함께 Origin Shield를 사용하면 Origin Shield가 활성화된 AWS 리전에서 [오리진 방향 트리거](lambda-cloudfront-trigger-events.md)(오리진 요청 및 오리진 응답)가 실행됩니다. 기본 Origin Shield 위치를 사용할 수 없고 CloudFront가 요청을 보조 Origin Shield 위치로 라우팅하는 경우 Lambda@Edge 오리진 연결 트리거는 보조 Origin Shield 위치를 사용하도록 전환합니다. 최종 사용자 방향 트리거는 영향을 받지 않습니다. # CloudFront 오리진 장애 조치를 통한 고가용성 최적화 고가용성을 필요로 하는 시나리오에 대한 오리진 장애 조치를 사용하여 이제 CloudFront를 설정할 수 있습니다. 시작하려면 2개의 오리진(기본 오리진 및 보조 오리진)이 포함된 *오리진 그룹*을 만듭니다. 기본 오리진을 사용할 수 없거나 실패를 나타내는 특정 HTTP 응답 상태 코드를 반환하는 경우 CloudFront는 자동으로 보조 오리진으로 전환합니다. 오리진 장애 조치를 설정하려면 최소 2개의 오리진이 있는 배포가 전제되어야 합니다. 다음으로, 2개의 오리진이 포함된 배포에 대한 오리진 그룹을 만들고 그 중 1개의 오리진을 기본 오리진으로 설정합니다. 마지막으로, 오리진 그룹을 사용하도록 캐시 동작을 생성하거나 업데이트합니다. 오리진 그룹을 설정하고 특정 오리진 장애 조치 옵션을 구성하는 단계는 [오리진 그룹 생성](#concept_origin_groups.creating) 단원을 참조하십시오. 캐시 동작에 대한 오리진 장애 조치를 구성한 후에, CloudFront가 최종 사용자의 요청에 대해 다음을 수행합니다. + 캐시 적중이 있는 경우 CloudFront는 요청된 객체를 반환합니다. + 캐시 누락이 있는 경우, CloudFront는 오리진 그룹 내에서 기본 오리진으로 요청을 라우팅합니다. + 기본 원본이 HTTP 2xx 또는 3xx 상태 코드와 같이 장애 조치용으로 구성되지 않은 상태 코드를 반환하면 CloudFront는 요청된 객체를 뷰어에게 제공합니다. + 다음과 같은 문제가 발생하는 경우: + 기본 오리진이 장애 조치를 위해 구성된 HTTP 상태 코드를 반환합니다. + CloudFront가 기본 오리진에 연결하지 못함(503이 장애 조치 코드로 설정된 경우) + 기본 오리진의 응답은 너무 오래 걸립니다(시간 초과). (504가 장애 조치 코드로 설정된 경우) 그러면 CloudFront는 요청을 오리진 그룹의 보조 오리진으로 라우팅합니다. **참고** 비디오 콘텐츠 스트리밍과 같은 일부 사용 사례의 경우 CloudFront가 보조 오리진으로 신속하게 장애 조치하도록 할 수 있습니다. CloudFront가 보조 오리진으로 장애 조치하는 속도를 조정하려면 [오리진 제한 시간 및 시도 횟수 제어](#controlling-attempts-and-timeouts) 단원을 참조하십시오. CloudFront는 이전 요청이 보조 오리진으로 장애 조치되는 경우에도 수신되는 모든 요청을 기본 오리진으로 라우팅합니다. CloudFront는 기본 오리진에 대한 요청이 실패한 후에만 보조 오리진에 요청을 보냅니다. CloudFront는 최종 사용자 요청의 HTTP 메서드가 `GET`, `HEAD` 또는 `OPTIONS`인 경우에만 보조 오리진으로 장애 조치합니다. 최종 사용자가 다른 HTTP 메서드(예: `POST`, `PUT` 등)를 보내면 CloudFront는 장애 조치를 수행하지 않습니다. **참고** 캐시 동작에서 `OPTIONS`가 [캐싱된 HTTP 메서드](DownloadDistValuesCacheBehavior.md#DownloadDistValuesCachedHTTPMethods)로 설정되지 않은 경우 CloudFront는 장애 조치를 수행하지 않습니다. 다음 다이어그램에서는 오리진 장애 조치의 작동 방식을 보여 줍니다. ![\[오리진 장애 조치의 작동 방식\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-overview.png) **Topics** + [ ## 오리진 그룹 생성 ](#concept_origin_groups.creating) + [ ## 오리진 제한 시간 및 시도 횟수 제어 ](#controlling-attempts-and-timeouts) + [ ## Lambda@Edge 함수와 함께 오리진 장애 조치 사용 ](#concept_origin_groups.lambda) + [ ## 오리진 장애 조치와 함께 사용자 지정 오류 페이지 사용 ](#concept_origin_groups.custom-error) ## 오리진 그룹 생성 **오리진 그룹을 생성하려면** 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. **원본(Origins)** 탭의 **원본 그룹(Origin groups)** 창에서 **원본 그룹 생성(Create origin group)**을 선택합니다. 1. 오리진 그룹에 대한 오리진을 선택합니다. 오리진을 추가한 후 화살표를 사용하여 우선순위를 설정합니다. 즉, 기본 오리진과 보조 오리진을 지정합니다. 1. 원본 그룹의 이름을 입력합니다. 1. 장애 조치 기준으로 사용할 HTTP 상태 코드를 선택합니다. 상태 코드 400, 403, 404, 416, 500, 502, 503 또는 504의 어떠한 조합도 선택할 수 있습니다. 지정한 상태 코드 중 하나가 포함된 응답을 CloudFront에서 수신하면 보조 오리진으로 장애 조치됩니다. **참고** CloudFront는 최종 사용자 요청의 HTTP 메서드가 `GET`, `HEAD` 또는 `OPTIONS`인 경우에만 보조 오리진으로 장애 조치합니다. 최종 사용자가 다른 HTTP 메서드(예: `POST`, `PUT` 등)를 보내면 CloudFront는 장애 조치를 수행하지 않습니다. 1. **오리진 선택 기준**에서 배포가 뷰어 요청을 라우팅할 때 오리진을 선택하는 방법을 지정합니다. 다음 옵션을 선택할 수 있습니다. **기본값** CloudFront는 **설정** 페이지에서 지정한 기본 오리진 우선순위를 사용합니다. **미디어 품질 점수** CloudFront는 이 점수를 추적하고 사용하여 요청을 전달할 첫 번째 오리진을 확인합니다. 또한 이를 통해 CloudFront는 미디어 품질 점수를 확인하기 위해 오리진 그룹의 대체 오리진에 비동기식 `HEAD` 요청을 할 수 있습니다. AWS Elemental MediaPackage v2 오리진의 경우에만 이 옵션을 선택할 수 있습니다. 자세한 내용은 [미디어 품질 인식 복원력](media-quality-score.md) 섹션을 참조하세요. 1. **원본 그룹 생성(Create origin group)**을 선택합니다. 분산 캐시 동작에 대한 오리진 그룹을 오리진으로 지정해야 합니다. 자세한 내용은 [이름](DownloadDistValuesOrigin.md#DownloadDistValuesId) 섹션을 참조하세요. ## 오리진 제한 시간 및 시도 횟수 제어 기본적으로 CloudFront는 오리진 그룹의 기본 오리진에 최대 30초(각각 10초 동안 연결 시도 3회) 동안 연결을 시도한 후 보조 오리진으로 장애 조치합니다. 비디오 콘텐츠 스트리밍과 같은 일부 사용 사례의 경우 CloudFront가 보조 오리진으로 보다 신속하게 장애 조치하도록 할 수 있습니다. 다음 설정을 조정하여 CloudFront가 보조 오리진으로 장애 조치하는 속도에 영향을 줄 수 있습니다. 오리진이 보조 오리진이거나 오리진 그룹의 일부가 아닌 오리진인 경우 이러한 설정은 CloudFront가 HTTP 504 응답을 최종사용자에게 얼마나 빨리 반환하는지에 영향을 줍니다. 더욱 신속하게 장애 조치하려면 더 짧은 연결 제한 시간, 더 적은 연결 시도 횟수 또는 둘 다를 지정합니다. 사용자 지정 오리진(정적 웹 사이트 호스팅으로 *구성된* Amazon S3 버킷 오리진 포함)의 경우 오리진 응답 제한 시간을 조정할 수도 있습니다. **오리진 연결 제한 시간** 오리진 연결 제한 시간 설정은 오리진에 대한 연결을 설정하려고 할 때 CloudFront의 대기 시간에 영향을 줍니다. 기본적으로 CloudFront는 연결을 설정하기 위해 10초 동안 대기하지만 1\$110초를 지정할 수 있습니다. 자세한 내용은 [연결 제한 시간](DownloadDistValuesOrigin.md#origin-connection-timeout) 단원을 참조하세요. **오리진 연결 시도 횟수** 오리진 연결 시도 횟수 설정은 CloudFront가 오리진에 연결을 시도하는 횟수에 영향을 줍니다. 기본적으로 CloudFront에서는 세 번 연결을 시도하지만 1\$13회를 지정할 수 있습니다. 자세한 내용은 [연결 시도](DownloadDistValuesOrigin.md#origin-connection-attempts) 단원을 참조하세요. 사용자 지정 오리진(정적 웹 사이트 호스팅으로 구성된 Amazon S3 버킷 포함)의 경우 이 설정은 또한 오리진 응답 제한 시간이 발생했을 때 CloudFront가 오리진에서 응답을 얻으려고 시도하는 횟수에 영향을 미칩니다. **오리진 응답 제한 시간** 오리진 읽기 제한 시간이라고도 하는 오리진 응답 제한 시간은 CloudFront가 오리진으로부터 응답을 수신(또는 전체 응답을 수신)하기 위해 대기하는 시간에 영향을 줍니다. 기본적으로 CloudFront는 30초 동안 대기하지만 1\$1120초를 지정할 수 있습니다. 자세한 내용은 [응답 제한 시간](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout) 섹션을 참조하세요. ### 이러한 설정을 변경하는 방법 **[CloudFront 콘솔](https://console.aws.amazon.com/cloudfront/v4/home)에서 이러한 설정을 변경하려면** + 새 오리진 또는 새 배포의 경우 리소스를 생성할 때 이러한 값을 지정하십시오. + 기존 배포의 기존 오리진의 경우 오리진을 편집할 때 이 값을 지정하십시오. 자세한 내용은 [모든 배포 설정 참조](distribution-web-values-specify.md) 단원을 참조하세요. ## Lambda@Edge 함수와 함께 오리진 장애 조치 사용 Lambda@Edge 함수를 오리진 그룹에 설정한 CloudFront 배포와 함께 사용할 수 있습니다. Lambda 함수를 사용하려면, 캐시 동작을 생성할 때 오리진 그룹에 대한 [오리진 요청 또는 오리진 응답 트리거](lambda-cloudfront-trigger-events.md)에 이 함수를 지정합니다. 오리진 그룹과 함께 Lambda@Edge 함수를 사용하는 경우, 단일 최종 사용자 요청에 대해 함수를 두 번 트리거할 수 있습니다. 예를 들어 다음 시나리오를 고려해 보십시오. 1. 오리진 요청 트리거를 사용하여 Lambda@Edge 함수를 생성합니다. 1. Lambda 함수는 CloudFront가 (캐시 누락 시) 기본 오리진에 요청을 보낼 때 한 번 트리거됩니다. 1. 기본 오리진은 장애 조치를 위해 구성된 HTTP 상태 코드로 응답합니다. 1. Lambda 함수는 CloudFront가 보조 오리진에 동일한 요청을 보낼 때 다시 트리거됩니다. 다음 다이어그램에서는 오리진 요청이나 응답 트리거에 Lambda@Edge 함수가 포함된 경우 오리진 장애 조치가 작동하는 방식을 보여 줍니다. ![\[오리진 장애 조치가 Lambda@Edge 함수와 함께 작동하는 방식\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-with-lambda-edge.png) Lambda@Edge 트리거 사용에 대한 자세한 내용은 [Lambda@Edge 함수에 대한 트리거 추가](lambda-edge-add-triggers.md) 단원을 참조하십시오. DNS 장애 조치 관리에 대한 자세한 내용은 Amazon Route 53 개발자 안내서의 [DNS 장애 조치 구성](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)을 참조합니다.** ## 오리진 장애 조치와 함께 사용자 지정 오류 페이지 사용 사용자 지정 오류 페이지를 오리진 장애 조치에 대해 설정되지 않은 오리진에 사용하는 경우와 유사한 방식으로 사용자 지정 오류 페이지를 오리진 그룹에 사용할 수 있습니다. 오리진 장애 조치를 사용할 때, CloudFront를 기본 오리진 또는 보조 오리진에 대해(또는 양쪽 모두에 대해) 사용자 지정 오류 페이지를 반환하도록 구성할 수 있습니다. + **기본 오리진에 대해 사용자 지정 오류 페이지 반환** — 장애 조치를 위해 구성되지 않은 HTTP 상태 코드를 기본 오리진에서 반환하는 경우 CloudFront는 사용자 지정 오류 페이지를 최종 사용자에게 반환합니다. + **보조 오리진에 대해 사용자 지정 오류 페이지 반환** — CloudFront가 보조 오리진에서 실패 상태 코드를 수신하면 CloudFront는 사용자 지정 오류 페이지를 반환합니다. CloudFront에서 사용자 지정 오류 페이지를 사용하는 방법에 대한 자세한 내용은 [사용자 지정 오류 응답 생성](GeneratingCustomErrorResponses.md) 단원을 참조하십시오. # 콘텐츠가 캐시에 유지되는 기간(만료) 관리 CloudFront에서 다른 요청을 오리진에 전달하기 전에 파일을 CloudFront 캐시에 보관하는 시간을 제어할 수 있습니다. 이 기간을 단축함으로써 동적 콘텐츠를 제공할 수 있습니다. 이 기간이 늘어나면 파일이 엣지 캐시에서 바로 제공될 가능성이 높으므로 사용자에게 제공되는 성능이 향상됩니다. 보관 기간이 늘어나면 오리진에 걸리는 부하 역시 줄어듭니다. 일반적으로 CloudFront는 지정한 캐시 기간이 지날 때까지, 즉 파일이 만료될 때까지 엣지 로케이션에서 파일을 제공합니다. 파일이 만료된 후 다음에 엣지 로케이션에서 이 파일에 대한 요청을 받으면, CloudFront에서는 이 요청을 오리진으로 전달하여 캐시에 최신 버전의 파일이 포함되어 있는지 확인합니다. 오리진의 응답은 파일 변경 여부에 따라 달라집니다. + CloudFront 캐시에 이미 최신 버전이 있는 경우 오리진에서는 상태 코드 `304 Not Modified`를 반환합니다. + CloudFront 캐시에 최신 버전이 없는 경우 오리진에서는 상태 코드 `200 OK`와 최신 버전의 파일을 반환합니다. 엣지 로케이션의 파일이 자주 요청되지 않는 경우 CloudFront에서는 만료 날짜 전에 이 파일을 제거하여 보다 최근에 요청된 파일을 위한 공간을 마련할 수 있습니다. 배포의 캐시 정책을 업데이트하여 캐시 기간을 관리하는 것이 좋습니다. 캐시 정책 사용을 옵트아웃하는 경우 기본 TTL(Time to Live)은 24시간이지만 다음 설정을 업데이트하여 기본 설정을 재정의할 수 있습니다. + 동일한 경로 패턴과 일치하는 모든 파일에 대해 캐시 기간을 변경하려면 캐시 동작에 대한 **Minimum TTL(최소 TTL)**, **Maximum TTL(최대 TTL)** 및 **Default TTL(기본 TTL)**의 CloudFront 설정을 변경할 수 있습니다. 개별 설정에 관한 자세한 내용은 [Minimum TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL), [Maximum TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) 및 [기본 TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesDefaultTTL) 섹션을 참조하세요. + 개별 파일의 캐시 기간을 변경하려면 `max-age` 또는 `s-maxage` 지시문이 있는 `Cache-Control` 헤더 또는 `Expires` 헤더를 파일에 추가하도록 오리진을 구성할 수 있습니다. 자세한 내용은 [헤더를 사용하여 개별 객체의 캐시 기간 제어](#expiration-individual-objects) 섹션을 참조하세요. **최소 TTL(Minimum TTL)**, **기본 TTL(Default TTL)** 및 **최대 TTL(Maximum TTL)**이 `max-age` 및 `s-maxage` 명령 및 `Expires` 헤더 필드와 상호 작용하는 방식에 대한 자세한 내용은 [CloudFront에서 객체를 캐싱하는 시간 지정](#ExpirationDownloadDist) 섹션을 참조하세요. 또한 CloudFront 에서 다른 요청을 오리진에 전달하여 요청된 객체의 가져오기를 다시 시도하기 전에 오류(예: `404 Not Found`)가 CloudFront 캐시에 보관되는 시간 역시 제어할 수 있습니다. 자세한 내용은 [CloudFront에서 오리진의 HTTP 4xx 및 5xx 상태 코드를 처리하는 방법](HTTPStatusCodes.md) 섹션을 참조하세요. **Topics** + [ ## 헤더를 사용하여 개별 객체의 캐시 기간 제어 ](#expiration-individual-objects) + [ ## 오래된(만료된) 콘텐츠 제공 ](#stale-content) + [ ## CloudFront에서 객체를 캐싱하는 시간 지정 ](#ExpirationDownloadDist) + [ ## Amazon S3 콘솔을 사용하여 객체에 헤더 추가 ](#ExpirationAddingHeadersInS3) ## 헤더를 사용하여 개별 객체의 캐시 기간 제어 `Cache-Control` 및 `Expires` 헤더를 사용하여 객체가 캐시에 머무르는 시간을 제어할 수 있습니다. **최소 TTL**, **기본 TTL** 및 **최대 TTL**에 대한 설정은 캐시 기간에도 영향을 주지만 캐시 기간에 영향을 미치는 방식에 대한 개요는 다음과 같습니다. + `Cache-Control max-age` 명령을 사용하면 CloudFront가 오리진 서버에서 객체를 다시 가져오기 전에 이 객체를 캐시에 보관하려는 시간(초)을 지정할 수 있습니다. CloudFront가 지원하는 최소 만료 시간은 0초입니다. 최대값은 100년입니다. 다음 형식으로 값을 지정합니다. `Cache-Control: max-age=`*초* 예를 들어 다음 명령은 CloudFront에 3,600초(1시간) 동안 관련 객체를 캐시에 보관하도록 지시합니다. `Cache-Control: max-age=3600` 브라우저 캐시에 보관하는 기간과는 다른 기간 동안 객체를 CloudFront 엣지 캐시에 보관하려는 경우, `Cache-Control max-age` 및 `Cache-Control s-maxage` 명령을 함께 사용할 수 있습니다. 자세한 내용은 [CloudFront에서 객체를 캐싱하는 시간 지정](#ExpirationDownloadDist) 단원을 참조하세요. + `Expires` 헤더 필드를 사용하면 다음과 같이 [RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1 Section 3.3.1, Full Date](https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1)에 지정된 형식을 사용하여 만료 날짜와 시간을 지정할 수 있습니다. `Sat, 27 Jun 2015 23:59:59 GMT` `Expires` 헤더 필드 대신 `Cache-Control max-age` 명령을 사용하여 객체 캐싱을 제어하는 것이 좋습니다. `Cache-Control max-age` 및 `Expires` 모두에 대해 값을 지정한 경우, CloudFront에서는 `Cache-Control max-age`의 값만 사용합니다. 자세한 내용은 [CloudFront에서 객체를 캐싱하는 시간 지정](#ExpirationDownloadDist) 단원을 참조하세요. 최종 사용자의 `Cache-Control` 요청에 HTTP `Pragma` 또는 `GET` 헤더 필드를 사용하여 CloudFront가 객체에 대한 오리진 서버로 돌아가도록 할 수는 없습니다. CloudFront에서는 최종 사용자 요청의 헤더 필드를 무시합니다. `Cache-Control` 및 `Expires` 헤더 필드에 대한 자세한 내용은 *RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1*의 다음 단원을 참조하십시오. + [섹션 14.9 Cache Control](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9) + [섹션 14.21 Expires](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21) ## 오래된(만료된) 콘텐츠 제공 CloudFront는 `Stale-While-Revalidate` 및 `Stale-If-Error` 캐시 제어 지시문을 지원합니다. 이러한 지시문을 사용하여 뷰어가 기한 경과 콘텐츠를 사용할 수 있는 기간을 지정할 수 있습니다. **Topics** + [ ### `Stale-While-Revalidate` ](#stale-while-revalidate) + [ ### `Stale-If-Error` ](#stale-if-error-only) + [ ### 두 지시문 모두 사용 ](#use-both-stale-directives) ### `Stale-While-Revalidate` 이 지시문을 통해 CloudFront는 오리진에서 새 버전을 비동기적으로 가져오는 동안 캐시에서 기한 경과 콘텐츠를 제공할 수 있습니다. 이렇게 하면 뷰어가 백그라운드 가져오기를 기다릴 필요 없이 엣지 로케이션에서 즉시 응답을 받을 때 지연 시간이 향상됩니다. 새 콘텐츠는 향후 요청을 위해 백그라운드에 로드됩니다. **Example 예시: `Stale-While-Revalidate`** CloudFront는 이러한 지시문을 사용하도록 `Cache-Control` 헤더를 설정할 때 다음을 수행합니다. ``` Cache-Control: max-age=3600, stale-while-revalidate=600 ``` 1. CloudFront는 1시간(`max-age=3600`) 동안 응답을 캐싱합니다. 1. 이 기간 이후에 요청이 이루어지면 CloudFront는 기한 경과 콘텐츠를 제공하는 동시에 캐시된 콘텐츠를 재검증하고 새로 고침하라는 요청을 오리진에 전송합니다. 1. 콘텐츠가 재검증되는 동안 CloudFront는 최대 10분(`stale-while-revalidate=600`) 동안 기한 경과 콘텐츠를 제공합니다. **참고** CloudFront는 `stale-while-revalidate` 지시문의 값 또는 CloudFront [최대 TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL)의 값 중 더 적은 값까지 기한 경과 콘텐츠를 제공합니다. 최대 TTL 기간이 지나면 `stale-while-revalidate` 값에 관계없이 엣지 캐시에서 기한 경과 객체를 사용할 수 없습니다. ### `Stale-If-Error` 이 지시문을 통해 CloudFront는 오리진에 연결할 수 없거나 500에서 600 사이의 오류 코드를 반환하는 경우 캐시에서 기한 경과 콘텐츠를 제공할 수 있습니다. 이를 통해 뷰어가 오리진 가동 중단 중에도 콘텐츠에 액세스할 수 있습니다. **Example 예시: `Stale-If-Error`** CloudFront는 이러한 지시문을 사용하도록 `Cache-Control` 헤더를 설정할 때 다음을 수행합니다. ``` Cache-Control: max-age=3600, stale-if-error=86400 ``` 1. CloudFront는 1시간(`max-age=3600`) 동안 응답을 캐싱합니다. 1. 이 기간 이후에 오리진이 다운되거나 오류가 반환되는 경우 CloudFront는 최대 24시간(`stale-if-error=86400`) 동안 기한 경과 콘텐츠를 계속 제공합니다. 1. 사용자 지정 오류 응답이 구성된 경우 CloudFront는 지정된 `stale-if-error` 기간 내에 오류가 발생하면 먼저 기한 경과 콘텐츠를 제공하려고 시도합니다. 기한 경과 콘텐츠를 사용할 수 없으면 CloudFront는 해당 오류 상태 코드에 대해 구성된 사용자 지정 오류 응답을 제공합니다. 자세한 내용은 [사용자 지정 오류 응답 생성](GeneratingCustomErrorResponses.md) 섹션을 참조하세요. **참고** CloudFront는 `stale-if-error` 지시문의 값 또는 CloudFront [최대 TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL)의 값 중 더 적은 값까지 기한 경과 콘텐츠를 제공합니다. 최대 TTL 기간이 지나면 `stale-if-error` 값에 관계없이 엣지 캐시에서 기한 경과 객체를 사용할 수 없습니다. `stale-if-error` 또는 사용자 지정 오류 응답을 구성하지 않으면 CloudFront는 요청된 객체가 엣지 캐시에 있는지 여부에 따라 기한 경과 객체를 반환하거나 오류 응답을 뷰어에게 다시 전달합니다. 자세한 내용은 [사용자 지정 오류 페이지를 구성하지 않은 경우 CloudFront에서 오류를 처리하는 방법](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages) 섹션을 참조하세요. ### 두 지시문 모두 사용 `stale-while-revalidate` 및 `stale-if-error`는 지연 시간을 줄이고 오리진이 응답하거나 복구하기 위한 버퍼를 추가하도록 함께 사용할 수 있는 독립적인 캐시 제어 지시문입니다. **Example 예: 두 지시문 모두 사용** CloudFront는 다음 지시문을 사용하도록 `Cache-Control` 헤더를 설정할 경우 다음을 수행합니다. ``` Cache-Control: max-age=3600, stale-while-revalidate=600, stale-if-error=86400 ``` 1. CloudFront는 1시간(`max-age=3600`) 동안 응답을 캐싱합니다. 1. 이 기간 이후에 요청이 이루어지면 CloudFront는 콘텐츠가 재검증되는 동안 최대 10분(`stale-while-revalidate=600`)간 기한 경과 콘텐츠를 제공합니다. 1. CloudFront가 콘텐츠 재검증을 시도하는 동안 오리진 서버에서 오류가 반환되는 경우 CloudFront는 최대 24시간(`stale-if-error=86400`) 동안 기한 경과 콘텐츠를 계속 제공합니다. 캐싱은 성능과 최신 상태 사이의 균형을 유지하는 것입니다. `stale-while-revalidate` 및 `stale-if-error`와 같은 지시문을 사용하면 성능과 사용자 경험을 향상할 수 있지만 원하는 콘텐츠의 최신 상태에 맞게 구성을 조정해야 합니다. 오래된 콘텐츠 지시문은 콘텐츠를 새로 고쳐야 하지만 최신 버전이 필요하지 않은 사용 사례에 가장 적합합니다. 또한 콘텐츠가 전혀 또는 거의 변경되지 않는 경우 `stale-while-revalidate`로 인해 불필요한 네트워크 요청이 추가될 수 있습니다. 대신 캐시 기간을 길게 설정하는 것이 좋습니다. ## CloudFront에서 객체를 캐싱하는 시간 지정 CloudFront에서 오리진에 다른 요청을 보내기 전에 객체를 캐시에 보관하는 시간을 제어하려면 다음을 수행할 수 있습니다. + CloudFront 배포의 캐시 동작에서 최소값, 최대값 및 기본 TTL 값을 설정합니다. 캐시 동작에 연결된 [캐시 정책](controlling-the-cache-key.md)(권장) 또는 레거시 캐시 설정에서 이러한 값을 설정할 수 있습니다. + 오리진의 응답에 `Cache-Control` 또는 `Expires` 헤더를 포함합니다. 또한 이러한 헤더는 CloudFront로 다른 요청을 보내기 전에 브라우저에서 브라우저 캐시에 객체를 유지하는 기간을 결정하는 데 도움이 됩니다. 다음 표에는 오리진에서 전송된 `Cache-Control` 및 `Expires` 헤더와 캐시 동작의 TTL 설정이 캐싱에 미치는 영향이 설명되어 있습니다. **** | 오리진 헤더 | 최소 TTL = 0 | 최소 TTL > 0 | | --- | --- | --- | | **오리진에서 `Cache-Control: max-age` 지시문을 객체에 추가** | **CloudFront 캐싱** CloudFront는 `Cache-Control: max-age` 지시문의 값 또는 CloudFront 최대 TTL의 값 중 더 작은 값 동안 객체를 캐싱합니다. **브라우저 캐싱** 브라우저는 `Cache-Control: max-age` 지시문의 값 동안 객체를 캐싱합니다. | **CloudFront 캐싱** CloudFront 캐싱은 CloudFront 최소 TTL과 최대 TTL 및 `Cache-Control max-age` 지시문의 값에 따라 달라집니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **브라우저 캐싱** 브라우저는 `Cache-Control: max-age` 지시문의 값 동안 객체를 캐싱합니다. | | **오리진에서 `Cache-Control: max-age` 지시문을 객체에 추가하지 않음** | **CloudFront 캐싱** CloudFront는 CloudFront 기본 TTL의 값 동안 객체를 캐싱합니다. **브라우저 캐싱** 브라우저에 따라 다릅니다. | **CloudFront 캐싱** CloudFront는 CloudFront 최소 TTL 또는 기본 TTL의 값 중 더 큰 값 동안 객체를 캐싱합니다. **브라우저 캐싱** 브라우저에 따라 다릅니다. | | **오리진에서 `Cache-Control: max-age` 및 `Cache-Control: s-maxage` 지시문을 객체에 추가** | **CloudFront 캐싱** CloudFront는 `Cache-Control: s-maxage` 지시문의 값 또는 CloudFront 최대 TTL의 값 중 더 작은 값 동안 객체를 캐싱합니다. **브라우저 캐싱** 브라우저는 `Cache-Control max-age` 지시문의 값 동안 객체를 캐싱합니다. | **CloudFront 캐싱** CloudFront 캐싱은 CloudFront 최소 TTL과 최대 TTL 및 `Cache-Control: s-maxage` 지시문의 값에 따라 달라집니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **브라우저 캐싱** 브라우저는 `Cache-Control: max-age` 지시문의 값 동안 객체를 캐싱합니다. | | **오리진에서 `Expires` 헤더를 객체에 추가** | **CloudFront 캐싱** CloudFront는 `Expires` 헤더의 날짜 또는 CloudFront 최대 TTL의 값 중 더 빨리 도래하는 객체를 캐싱합니다. **브라우저 캐싱** 브라우저는 `Expires` 헤더의 날짜까지 객체를 캐싱합니다. | **CloudFront 캐싱** CloudFront 캐싱은 CloudFront 최소 TTL과 최대 TTL 및 `Expires` 지시문의 값에 따라 달라집니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **브라우저 캐싱** 브라우저는 `Expires` 헤더의 날짜와 시간까지 객체를 캐싱합니다. | | **오리진에서 `Cache-Control: no-cache`, `no-store` 및/또는 `private` 지시문을 객체에 추가** | CloudFront 및 브라우저에서는 헤더의 설정을 따릅니다. | **CloudFront 캐싱** CloudFront는 CloudFront 최소 TTL의 값 동안 객체를 캐싱합니다. [이 표 아래의 경고를 참조하세요](#stale-if-error). **브라우저 캐싱** 브라우저에서는 헤더의 설정을 따릅니다. | **주의** 최소 TTL이 0보다 큰 경우 CloudFront는 `Cache-Control: no-cache`, `no-store` 및/또는 `private` 지시문이 오리진 헤더에 있더라도 캐시 정책의 최소 TTL을 사용합니다. 오리진에 연결할 수 있는 경우 CloudFront는 오리진에서 객체를 가져와 최종 사용자에게 반환합니다. 오리진에 연결할 수 없고 최소 또는 최대 TTL이 0보다 큰 경우 CloudFront는 이전에 오리진에서 가져온 객체를 제공합니다.** 이 동작을 방지하려면 오리진에서 반환된 객체에 `Cache-Control: stale-if-error=0` 지시문을 포함합니다. 이렇게 하면 향후 요청 시 오리진에 연결할 수 없을 때 CloudFront가 이전에 오리진에서 가져온 객체를 반환하는 대신 오류를 반환합니다. 오리진 헤더에 `Cache-Control: no-cache`, `no-store` 및/또는 `private` 명령이 포함된 경우 CloudFront는 S3 오리진에서 HTTP 501 상태 코드(구현되지 않음)를 캐싱하지 않습니다. 이는 [최소 TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL) 설정이 0보다 큰 경우에도 S3 오리진의 기본 동작입니다. CloudFront 콘솔을 사용하여 배포에 대한 설정을 변경하는 방법에 대한 자세한 내용은 [배포 업데이트](HowToUpdateDistribution.md) 섹션을 참조하세요. CloudFront API를 사용하여 배포에 대한 설정을 변경하는 방법에 대한 자세한 내용은 [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)을 참조하세요. ## Amazon S3 콘솔을 사용하여 객체에 헤더 추가 Amazon S3 객체에 `Cache-Control` 또는 `Expires` 헤더 필드를 추가할 수 있습니다. 이렇게 하려면 객체의 메타데이터 필드를 수정합니다. **Amazon S3 객체에 `Cache-Control` 또는 `Expires` 헤더 필드 추가** 1. *Amazon S3 사용 설명서*의 [Amazon S3 콘솔에서 객체 메타데이터 편집](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html) 주제에 있는 **시스템 정의 메타데이터 바꾸기** 섹션의 절차를 따릅니다. 1. [**키(Key)**]에서 추가할 헤더의 이름(**Cache-Control** 또는 **Expires**)을 선택합니다. 1. [**값(Value)**]에 헤더 값을 입력합니다. 예를 들어, `Cache-Control` 헤더의 경우 `max-age=86400`을 입력할 수 있습니다. `Expires`의 경우 만료 날짜 및 시간(예: `Wed, 30 Jun 2021 09:28:00 GMT`)을 입력할 수 있습니다. 1. 나머지 절차에 따라 메타데이터 변경 사항을 저장합니다. # 쿼리 문자열 파라미터 기반의 콘텐츠 캐싱 일부 웹 애플리케이션은 쿼리 문자열을 사용하여 오리진에 정보를 전송합니다. 쿼리 문자열은 `?` 문자 다음에 오는 웹 요청의 일부이며 이 문자열은 `&` 문자로 구분된 하나 이상의 파라미터를 포함할 수 있습니다. 다음 예의 쿼리 문자열에는 *color=red*와 *size=large*의 두 가지 파라미터가 포함되어 있습니다. `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large` 배포의 경우 CloudFront에서 쿼리 문자열을 오리진에 전달하도록 선택할 수 있으며, 콘텐츠를 모든 파라미터를 기준으로 캐싱할지 아니면 일부 파라미터를 기준으로 캐싱할지를 선택합니다. 이 기능이 유용한 이유를 알아보려면 다음 예제를 살펴보십시오. 웹사이트가 5개 언어로 제공되는 경우를 가정하겠습니다. 5개 웹사이트 버전의 디렉터리 구조와 파일 이름은 동일합니다. 사용자가 웹사이트를 볼 때 CloudFront로 전달되는 요청에는 사용자가 선택한 언어를 기준으로 하는 언어 쿼리 문자열 파라미터가 포함됩니다. 쿼리 문자열을 오리진으로 전달하고 언어 파라미터를 기준으로 캐싱하도록 CloudFront를 구성할 수 있습니다. 웹 서버에서 선택한 언어에 해당하는 특정 페이지의 버전을 반환하도록 구성할 경우 CloudFront는 언어 쿼리 문자열 파라미터 값을 기준으로 각 언어 버전을 별도로 캐싱합니다. 이 예에서 웹 사이트의 메인 페이지가 `main.html`인 경우 다음과 같은 5개 요청이 발생하면 CloudFront에서 언어 쿼리 문자열 파라미터의 각 값에 대해 한 번씩 `main.html`을 다섯 번 캐싱합니다. + `https://d111111abcdef8.cloudfront.net/main.html?language=de` + `https://d111111abcdef8.cloudfront.net/main.html?language=en` + `https://d111111abcdef8.cloudfront.net/main.html?language=es` + `https://d111111abcdef8.cloudfront.net/main.html?language=fr` + `https://d111111abcdef8.cloudfront.net/main.html?language=jp` 다음을 참조하십시오. + 일부 HTTP 서버는 쿼리 문자열 파라미터를 처리하지 않으므로 파라미터 값을 기준으로 객체의 다른 버전을 반환하지 않습니다. 이러한 오리진의 경우 CloudFront에서 쿼리 문자열 파라미터를 오리진으로 전달하도록 구성할 경우 CloudFront는 오리진에서 모든 파라미터 값에 대해 CloudFront에 동일한 객체 버전을 반환할 경우에도 파라미터 값을 기준으로 캐싱합니다. + 쿼리 문자열 파라미터가 위의 예제에서 설명한 대로 작동하려면 쿼리 문자열 파라미터 간에 `&` 문자를 구분 기호로 사용해야 합니다. 다른 구분 기호를 사용하는 경우에는 캐싱 기준으로 CloudFront에서 지정하는 파라미터 및 쿼리 문자열에서 파라미터가 나타나는 순서에 따라 결과가 달라질 수 있습니다. 다음 예는 다른 구분 기호를 사용하고, `color` 파라미터에 따라서만 캐싱하도록 CloudFront를 구성할 경우의 결과를 보여줍니다. + 다음 요청에서 CloudFront는 `color` 파라미터 값을 기준으로 콘텐츠를 캐싱하지만 CloudFront는 이 값을 *red;size=large*로 해석합니다. `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red;size=large` + 다음 요청에서 CloudFront는 콘텐츠를 캐싱하지만 쿼리 문자열 파라미터를 기준으로 캐싱하지 않습니다. 그 이유는 CloudFront에서 `color` 파라미터를 기준으로 캐싱하도록 구성했지만 CloudFront는 다음 문자열에 *large;color=red* 값을 가진 `size` 파라미터만 포함된 것으로 해석하기 때문입니다. `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large;color=red` CloudFront에서 다음 중 하나를 수행하도록 구성할 수 있습니다. + 쿼리 문자열을 오리진에 전혀 전달하지 않음. 쿼리 문자열을 전달하지 않을 경우 CloudFront는 쿼리 문자열 파라미터를 기준으로 캐싱하지 않습니다. + 쿼리 문자열을 오리진으로 전달하며 쿼리 문자열의 모든 파라미터를 기준으로 캐싱함 + 쿼리 문자열을 오리진으로 전달하며 쿼리 문자열 중 지정된 파라미터를 기준으로 캐싱함 자세한 내용은 [캐싱 최적화](#query-string-parameters-optimizing-caching) 섹션을 참조하세요. **Topics** + [ ## 쿼리 문자열 전달 및 캐싱에 대한 콘솔 및 API 설정 ](#query-string-parameters-console) + [ ## 캐싱 최적화 ](#query-string-parameters-optimizing-caching) + [ ## 쿼리 문자열 파라미터 및 CloudFront 표준 로그(액세스 로그) ](#query-string-parameters-access-logs) ## 쿼리 문자열 전달 및 캐싱에 대한 콘솔 및 API 설정 CloudFront 콘솔에서 배포를 생성하면 CloudFront는 오리진 유형에 따라 쿼리 문자열 전달 및 캐싱을 구성합니다. 선택적으로 이러한 설정을 수동으로 편집할 수 있습니다. 자세한 내용은 [모든 배포 설정 참조](distribution-web-values-specify.md)에서 다음 설정을 참조하세요. + [쿼리 문자열 전달 및 캐싱](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryString) + [쿼리 문자열 허용 목록](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryStringAllowlist) CloudFront API를 사용하여 쿼리 문자열 전달 및 캐싱을 구성하려면 **Amazon CloudFront API 참조의 [CachePolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CachePolicy.html) 및 [OriginRequestPolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginRequestPolicy.html)를 참조하세요. ## 캐싱 최적화 쿼리 문자열 파라미터를 기반으로 캐싱하도록 CloudFront를 구성하는 경우 다음 단계를 수행하여 CloudFront에서 오리진에 전달되는 요청 수를 줄일 수 있습니다. CloudFront 엣지 로케이션에서 객체를 제공하면 사용자에게 보다 엣지 로케이션에서 객체가 제공되므로 오리진 서버의 부하를 줄이고 지연 시간을 단축할 수 있습니다. **원본이 다른 버전의 객체를 반환하는 파라미터만 기반으로 캐시** 웹 애플리케이션에서 CloudFront로 각 쿼리 문자열 파라미터를 전달할 때마다 CloudFront는 모든 파라미터 값에 대해 오리진에 요청을 전달하며 모든 파라미터 값에 대해 별도의 객체 버전을 캐싱합니다. 이는 오리진에서 파라미터 값과 상관없이 항상 같은 객체를 반환하는 경우라도 그렇습니다. 복수 파라미터의 경우 요청 수와 객체 수를 곱합니다. 오리진에서 다른 버전을 반환하는 쿼리 문자열 파라미터만 기준으로 캐싱하도록 CloudFront를 구성하고 각 파라미터를 기준으로 캐싱하는 이점을 주의 깊게 고려하는 것이 좋습니다. 예를 들어, 소매 웹사이트가 있다고 가정해봅시다. 6가지 색상의 자켓 사진이 있고 이 자켓은 10가지 사이즈로 제공됩니다. 가지고 있는 자켓 사진은 다른 색상을 보여주지만 다른 사이즈는 보여주지 않습니다. 캐싱을 최적화하려면 CloudFront에서 크기 파라미터가 아닌 색상 파라미터만 기준으로 캐싱하도록 구성해야 합니다. 이렇게 하면 CloudFront에서 캐시로부터 요청을 제공할 수 있는 가능성이 높아지고, 그에 따라 성능이 향상되며 오리진에 걸리는 부하가 줄어듭니다. **파라미터를 항상 동일한 순서로 나열** 쿼리 문자열에서 파라미터의 순서는 중요합니다. 다음 예에서 쿼리 문자열은 파라미터 순서가 다른 것을 제외하고 동일합니다. 이 경우 CloudFront는 image.jpg에 대한 별도의 두 가지 요청을 오리진에 전달하고 객체의 두 가지 별도 버전을 캐싱합니다. + `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large` + `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large&color=red` 사전순과 같이 파라미터 이름을 항상 동일한 순서로 나열하는 것이 좋습니다. **파라미터 이름 및 값에 대해 항상 동일한 대소문자 사용** CloudFront는 쿼리 문자열 파라미터를 기준으로 캐싱할 때 파라미터 이름과 값의 대소문자를 고려합니다. 다음 예에서 쿼리 문자열은 파라미터 이름과 값의 대소문자가 다른 것을 제외하고 동일합니다. 이 경우 CloudFront는 image.jpg에 대한 별도의 네 가지 요청을 오리진에 전달하고 객체의 네 가지 별도 버전을 캐싱합니다. + `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red` + `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=Red` + `https://d111111abcdef8.cloudfront.net/images/image.jpg?Color=red` + `https://d111111abcdef8.cloudfront.net/images/image.jpg?Color=Red` 파라미터 이름과 값을 모두 소문자로 하는 경우와 같이 대소문자를 일관적으로 사용하는 것이 좋습니다. **서명된 URL과 충돌하는 파라미터 이름은 사용하지 않음** 서명된 URL을 사용하여 콘텐츠에 대한 액세스를 제한하는 경우(신뢰할 수 있는 서명자를 배포에 추가한 경우), CloudFront에서는 나머지 URL을 오리진에 전달하기 전에 다음 쿼리 문자열 파라미터를 제거합니다. + `Expires` + `Key-Pair-Id` + `Policy` + `Signature` 서명된 URL을 사용하면서 CloudFront에서 쿼리 문자열을 오리진에 전달하도록 구성하려는 경우 자체 쿼리 문자열 파라미터를 `Expires`, `Key-Pair-Id`, `Policy` 또는 `Signature`라는 이름으로 지정할 수 없습니다. ## 쿼리 문자열 파라미터 및 CloudFront 표준 로그(액세스 로그) 로깅을 활성화한 경우 CloudFront는 쿼리 문자열 파라미터를 포함해 전체 URL을 로깅합니다. 오리진에 쿼리 문자열을 전달하도록 CloudFront를 구성했는지와 관계없이 로깅합니다. CloudFront 로깅에 대한 자세한 내용은 [액세스 로그(표준 로그)](AccessLogs.md) 단원을 참조하십시오. # 쿠키 기반의 콘텐츠 캐싱 CloudFront에서는 요청 및 응답을 처리할 때나 엣지 로케이션의 객체를 캐싱할 때 쿠키를 기본적으로 고려하지 않습니다. `Cookie` 헤더의 내용을 제외하고 동일한 두 개의 요청을 CloudFront가 수신하면 기본적으로 CloudFront는 요청을 동일하게 처리하고 두 요청에 대해 동일한 객체를 반환합니다. 최종 사용자 요청의 쿠키 일부 또는 전체를 오리진으로 전달하고, 전달되는 쿠키 값에 따라 별도의 객체 버전을 캐싱하도록 CloudFront를 구성할 수 있습니다. 이렇게 하면 CloudFront에서 최종 사용자 요청에서 전달하도록 구성된 일부 또는 전체 쿠키를 사용하여 캐시의 객체를 고유하게 식별합니다. 예를 들어, `locations.html`에 대한 요청에 `country` 또는 `uk` 값을 가진 `fr` 쿠키가 포함되어 있다고 가정합니다. `country` 쿠키 값을 기반으로 객체를 캐싱하도록 CloudFront를 구성할 경우, CloudFront에서는 `locations.html`에 대한 요청을 오리진에 전달하고 `country` 쿠키 및 쿠키 값을 포함합니다. 오리진에서는 `locations.html`을 반환하고 CloudFront에서는 `country` 쿠키의 값이 `uk`인 요청에 대해 한 번, 값이 `fr`인 요청에 대해 한 번, 객체를 캐싱합니다. **중요** Amazon S3 및 일부 HTTP 서버에서는 쿠키를 처리하지 않습니다. 쿠키를 처리하지 않거나 쿠키에 따라 다른 응답을 제공하지 않는 오리진에 쿠키를 전달하도록 CloudFront를 구성하지 마십시오. 그렇지 않으면 CloudFront가 동일한 객체에 대해 더 많은 요청을 오리진에 전달할 수 있으므로 성능이 저하되고 오리진의 로드가 증가합니다. 앞의 예제를 예로 들면, 오리진이 `country` 쿠키를 처리하지 않거나 `locations.html` 쿠키의 값에 관계없이 항상 동일한 버전의 `country`을 CloudFront로 반환하는 경우 해당 쿠키를 전달하도록 CloudFront를 구성하지 마십시오. 반대로 사용자 지정 오리진이 특정 쿠키에 의존하거나 쿠키에 따라 다른 응답을 보내는 경우 해당 쿠키를 오리진에 전달하도록 CloudFront를 구성해야 합니다. 그렇지 않을 경우 CloudFront는 오리진에 요청을 전달하기 전에 쿠키를 제거합니다. 쿠키 전달을 구성하려면 배포의 캐시 동작을 업데이트합니다. 캐시 동작에 대한 자세한 내용은 [캐시 동작 설정](DownloadDistValuesCacheBehavior.md)(특히 [쿠키 전달](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardCookies) 및 [허용 목록 쿠키](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies) 단원)를 참조하십시오. 다음 중 하나를 수행하도록 각 캐시 동작을 구성할 수 있습니다. + **오리진에 모든 쿠키 전달 – **CloudFront가 오리진에 요청을 전달할 때 최종 사용자가 보내는 모든 쿠키를 포함시킵니다. 오리진에서 응답을 반환할 때 CloudFront는 최종 사용자 요청의 쿠키 이름 및 쿠키 값을 사용하여 응답을 캐싱합니다. 오리진 응답에 `Set-Cookie` 헤더가 포함되면 CloudFront는 요청된 객체와 함께 최종 사용자에게 해당 헤더를 반환합니다. 또한 CloudFront는 오리진에서 반환된 객체와 함께 `Set-Cookie` 헤더를 캐싱하고 모든 캐시 적중 시 최종 사용자에게 해당 `Set-Cookie` 헤더를 보냅니다. + **지정한 쿠키 세트 전달 – ** CloudFront는 요청을 원본에 전달하기 전에 뷰어가 보내는 쿠키 중 허용 목록에 없는 모든 쿠키를 제거합니다. CloudFront는 뷰어 요청에 나열된 쿠키 이름과 값을 사용하여 응답을 캐시합니다. 오리진 응답에 `Set-Cookie` 헤더가 포함되면 CloudFront는 요청된 객체와 함께 최종 사용자에게 해당 헤더를 반환합니다. 또한 CloudFront는 오리진에서 반환된 객체와 함께 `Set-Cookie` 헤더를 캐싱하고 모든 캐시 적중 시 최종 사용자에게 해당 `Set-Cookie` 헤더를 보냅니다. 쿠키 이름에 와일드카드를 지정하는 방법에 대한 자세한 내용은 [허용 목록 쿠키](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies) 단원을 참조하십시오. 각 캐시 동작에 대해 전달할 수 있는 쿠키 이름 수에 대한 현재 할당량을 확인하거나 더 높은 할당량을 요청하려면 [쿼리 문자열에 대한 할당량(레거시 캐시 설정)](cloudfront-limits.md#limits-allowlisted-query-strings)을 참조하십시오. + **오리진에 쿠키를 전달하지 않음 – **CloudFront는 최종 사용자가 보낸 쿠키에 따라 객체를 캐싱하지 않습니다. 또한 CloudFront는 오리진에 요청을 전달하기 전에 쿠키를 제거하고 최종 사용자에게 응답을 반환하기 전에 응답에서 `Set-Cookie` 헤더를 제거합니다. 이는 오리진 리소스를 사용하는 최적의 방법이 아니므로 이 캐시 동작을 선택할 때는 오리진이 기본적으로 오리진 응답에 쿠키를 포함하지 않도록 해야 합니다. 전달하려는 쿠키를 지정할 때는 다음 사항에 유의하십시오. **액세스 로그** 요청 및 쿠키를 로그하도록 CloudFront를 구성하면 CloudFront에서 원본에 쿠키를 전달하지 않도록 구성하거나 특정 쿠키만 전달하도록 CloudFront를 구성한 경우에도 CloudFront는 모든 쿠키와 모든 쿠키 속성을 로그합니다. CloudFront 로깅에 대한 자세한 내용은 [액세스 로그(표준 로그)](AccessLogs.md) 단원을 참조하십시오. **대소문자 구분** 쿠키 이름과 값은 모두 대소문자를 구분합니다. 예를 들어 CloudFront가 모든 쿠키를 전달하도록 구성되어 있고 동일한 객체에 대한 두 개의 최종 사용자 요청에 대소문자를 제외하고 동일한 쿠키가 있는 경우 CloudFront는 객체를 두 번 캐싱합니다. **CloudFront에서 쿠키 정렬** CloudFront가 쿠키(전체 또는 일부)를 전달하도록 구성된 경우 CloudFront에서는 요청을 원본에 전달하기 전에 쿠키 이름을 기준으로 쿠키를 자연스러운 순서로 정렬합니다. `$` 문자로 시작하는 쿠키 이름은 지원되지 않습니다. CloudFront는 오리진에 요청을 전달하기 전에 쿠키를 제거합니다. `$` 문자를 제거하거나 쿠키 이름의 시작 부분에 다른 문자를 지정할 수 있습니다. **`If-Modified-Since` 및 `If-None-Match`** CloudFront가 쿠키(전체 또는 일부)를 전달하도록 구성된 경우 `If-Modified-Since` 및 `If-None-Match` 조건부 요청이 지원되지 않습니다. **표준 이름-값 페어 형식 필요** CloudFront에서는 값이 [표준 이름-값 페어 형식](https://tools.ietf.org/html/rfc6265#section-4.1.1)을 따를 경우에만 쿠키 헤더를 전달합니다(예: `"Cookie: cookie1=value1; cookie2=value2"`). **`Set-Cookie` 헤더 캐싱 비활성화** CloudFront가 쿠키를 원본에 전달하도록 구성된 경우(전체 또는 특정 쿠키인지 여부에 관계없이) 원본 응답에서 수신된 `Set-Cookie` 헤더도 캐시합니다. CloudFront는 원래 최종 사용자의 응답에 이러한 `Set-Cookie` 헤더를 포함하며 CloudFront 캐시에서 제공되는 후속 응답에도 이러한 헤더를 포함합니다. 오리진에서 쿠키를 받지만 CloudFront가 오리진 응답에 `Set-Cookie` 헤더를 캐싱하지 않도록 하려면 `Cache-Control`를 필드 이름으로 지정하는 `no-cache` 지시문이 있는`Set-Cookie` 헤더를 추가하도록 오리진을 구성합니다. 예를 들면 `Cache-Control: no-cache="Set-Cookie"`입니다. 자세한 내용은 *Hypertext Transfer Protocol(HTTP/1.1): 캐싱* 표준의 [응답 캐시 제어 지시문](https://tools.ietf.org/html/rfc7234#section-5.2.2)을 참조하십시오. **쿠키 이름의 최대 길이** 특정 쿠키를 원본으로 전달하도록 CloudFront를 구성하는 경우 전달하도록 CloudFront를 구성하는 모든 쿠키 이름의 총 바이트 수는 512에서 전달하는 쿠키 수를 뺀 값을 초과할 수 없습니다. 예를 들어 오리진에 10개의 쿠키를 전달하도록 CloudFront를 구성하는 경우, 이 10개의 쿠키 이름들을 합친 길이는 502바이트(512-10)를 초과할 수 없습니다. 오리진에 전체 쿠키를 전달하도록 CloudFront를 구성하는 경우, 쿠키 이름의 길이는 문제가 되지 않습니다. CloudFront에서 오리진에 쿠키를 전달하도록 CloudFront 콘솔을 사용하여 웹 배포를 업데이트하는 방법에 대한 자세한 내용은 [배포 업데이트](HowToUpdateDistribution.md) 단원을 참조하십시오. CloudFront API를 사용한 배포 업데이트에 대한 자세한 내용은 *Amazon CloudFront API 참조*의 [배포 업데이트](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)를 참조하십시오. # 요청 헤더 기반의 콘텐츠 캐싱 CloudFront에서 헤더를 오리진으로 전송할지, 최종 사용자 요청의 헤더 값에 따라 지정된 객체의 개별 버전을 캐싱할지 여부를 선택할 수 있습니다. 이렇게 하면 사용자가 사용하는 디바이스, 최종 사용자의 위치, 최종 사용자가 사용하는 언어 및 다양한 조건에 따라 서로 다른 버전의 콘텐츠를 제공할 수 있습니다. **Topics** + [ ## 헤더 및 배포 – 개요 ](#header-caching-web) + [ ## 캐싱의 기반이 되는 헤더 선택 ](#header-caching-web-selecting) + [ ## CORS 설정을 준수하도록 CloudFront 구성 ](#header-caching-web-cors) + [ ## 디바이스 유형을 기반으로 캐싱하도록 구성 ](#header-caching-web-device) + [ ## 뷰어 언어를 기반으로 캐싱하도록 구성 ](#header-caching-web-language) + [ ## 뷰어 언어를 기반으로 캐싱하도록 구성 ](#header-caching-web-location) + [ ## 요청의 프로토콜을 기반으로 캐싱하도록 구성 ](#header-caching-web-protocol) + [ ## 압축 파일에 대한 캐싱 구성 ](#header-caching-web-compressed) + [ ## 헤더를 기반으로 한 캐싱이 성능에 미치는 영향 ](#header-caching-web-performance) + [ ## 헤더 및 헤더 값의 대소문자가 캐싱에 미치는 영향 ](#header-caching-web-case) + [ ## CloudFront에서 최종 사용자에게 반환하는 헤더 ](#header-caching-web-response) ## 헤더 및 배포 – 개요 기본적으로 CloudFront에서는 엣지 로케이션의 객체를 캐싱할 때 헤더를 고려하지 않습니다. 오리진에서 두 개의 객체를 반환하고 이들 객체는 요청 헤더의 값에만 차이가 있는 경우, CloudFront에서는 한 가지 버전의 객체만 캐싱합니다. 오리진에 헤더를 전달하도록 CloudFront를 구성할 수 있으며, 이러한 경우 CloudFront에서는 하나 이상의 요청 헤더 값에 따라 여러 버전의 객체를 캐싱합니다. 특정 헤더의 값에 따라 객체를 캐싱하기 위한 CloudFront를 구성하려면, 배포에 대한 캐시 동작 설정을 지정해야 합니다. 자세한 내용은 [선택한 요청 헤더 기반의 캐시](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesForwardHeaders) 단원을 참조하십시오. 예를 들어, `logo.jpg`에 대한 최종 사용자 요청에 `Product` 또는 `Acme` 값을 가진 사용자 지정 `Apex` 헤더가 포함되어 있다고 가정합니다. `Product` 헤더 값을 기반으로 객체를 캐싱하도록 CloudFront를 구성하는 경우, CloudFront에서는 `logo.jpg`에 대한 요청을 오리진에 전달하고 `Product` 헤더 및 헤더 값을 포함합니다. CloudFront에서는 `logo.jpg` 헤더의 값이 `Product`인 요청에 대해 한 번, 값이 `Acme`인 요청에 대해 한 번 `Apex`를 캐싱합니다. 다음 중 하나를 수행하도록 배포의 각 캐시 동작을 구성할 수 있습니다. + 오리진에 전체 헤더를 전달합니다. **참고** **레거시 캐시 설정** - 전체 헤더를 오리진에 전달하도록 CloudFront를 구성한 경우, CloudFront에서는 이 캐시 동작과 연결된 객체를 캐싱하지 않습니다. 대신 각 요청을 오리진에 보냅니다. + 지정한 헤더 목록을 전달합니다. CloudFront에서는 모든 지정된 헤더의 값을 기반으로 객체를 캐싱합니다. 또한 CloudFront에서는 기본적으로 전달하는 헤더를 모두 전달하지만 지정한 헤더를 기반으로만 객체를 캐싱합니다. + 기본 헤더만 전달합니다. 이 구성의 경우 CloudFront에서는 요청 헤더의 값을 기반으로 객체를 캐싱하지 않습니다. 각 캐시 동작에 대해 전달할 수 있는 헤더 수에 대한 현재 할당량을 확인하거나 또는 더 높은 할당량을 요청하려면 [헤더에 대한 할당량](cloudfront-limits.md#limits-custom-headers)을 참조하십시오. CloudFront에서 오리진에 헤더를 전달하도록 CloudFront 콘솔을 사용하여 웹 배포를 업데이트하는 방법에 대한 자세한 내용은 [배포 업데이트](HowToUpdateDistribution.md) 단원을 참조하십시오. CloudFront API를 사용한 기존 배포 업데이트에 대한 자세한 내용은 *Amazon CloudFront API 참조*의 [배포 업데이트](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)를 참조하십시오. ## 캐싱의 기반이 되는 헤더 선택 오리진에 전달할 수 있고 CloudFront에서 캐싱의 기반이 되는 헤더는 오리진이 Amazon S3 버킷인지 사용자 지정 오리진인지에 따라 달라집니다. + **Amazon S3 – **다수의 특정 헤더를 기반으로 객체를 전달하고 캐싱하도록 CloudFront를 구성할 수 있습니다(다음 예외 목록 참조). 그러나 교차 원본 리소스 공유(CORS)를 구현해야 하거나 원본 대면 이벤트에서 Lambda@Edge를 사용하여 콘텐츠를 개인화하려는 경우가 아니면 Amazon S3 원본으로 헤더를 전달하지 않는 것이 좋습니다. + CORS를 구성하려면 CloudFront가 CORS에 대해 활성화된 웹 사이트용 콘텐츠를 배포할 수 있도록 헤더를 전달해야 합니다. 자세한 내용은 [CORS 설정을 준수하도록 CloudFront 구성](#header-caching-web-cors) 단원을 참조하세요. + Amazon S3 오리진에 전달된 헤더를 사용하여 콘텐츠를 개인 설정하려면 Lambda@Edge 함수를 작성 및 추가하고 이를 오리진 방향 이벤트에서 트리거되는 CloudFront 배포에 연결합니다. 콘텐츠를 개인 설정하기 위해 헤더를 처리하는 방법에 대한 자세한 내용은 [국가 또는 디바이스 유형 헤더별 콘텐츠 개인화 - 예제](lambda-examples.md#lambda-examples-redirecting-examples) 단원을 참조하십시오. 추가 헤더를 전달하면 캐시 적중률이 감소할 수 있으므로 콘텐츠를 개인화하는 데 사용하지 않는 헤더는 전달하지 않는 것이 좋습니다. 즉, CloudFront는 모든 요청의 비율로서 엣지 캐시에서 제공되는 다수의 요청을 처리할 수 없습니다. + **사용자 지정 오리진** – 다음과 같이 요청 헤더 값을 기반으로 캐싱하도록 CloudFront를 구성할 수 있습니다. + `Connection` + `Cookie` – 쿠키를 기반으로 전달 및 캐싱을 수행하려는 경우, 배포에 개별 설정을 사용합니다. 자세한 내용은 [쿠키 기반의 콘텐츠 캐싱](Cookies.md) 단원을 참조하세요. + `Host (for Amazon S3 origins)` + `Proxy-Authorization` + `TE` + `Upgrade` `Date` 및 `User-Agent` 헤더의 값에 따라 객체를 캐싱하도록 CloudFront를 구성할 수 있지만, 권장되지는 않습니다. 이러한 헤더는 여러 가지 값을 가질 수 있으며, 헤더의 값에 따른 캐싱으로 인해 CloudFront에서 오리진에 전달되는 요청이 눈에 띄게 증가할 수 있습니다. HTTP 요청 헤더의 전체 목록과 CloudFront에서 이를 처리하는 방법은 [HTTP 요청 헤더 및 CloudFront 동작(사용자 지정 및 Amazon S3 오리진)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior) 단원을 참조하십시오. ## CORS 설정을 준수하도록 CloudFront 구성 Amazon S3 버킷 또는 사용자 지정 오리진에서 CORS를 활성화한 경우에는 CORS 설정을 준수하도록 전달할 특정 헤더를 선택해야 합니다. 오리진(Amazon S3 또는 사용자 지정)과 `OPTIONS` 응답의 캐싱 여부에 따라 서로 다른 헤더를 전달해야 합니다. **Amazon S3** + `OPTIONS` 응답을 캐싱하고 싶으면 다음을 수행하세요. + `OPTIONS` 응답에 대해 캐싱을 활성화하는 기본 캐시 동작 설정에 대한 옵션을 선택합니다. + `Origin`, `Access-Control-Request-Headers` 및 `Access-Control-Request-Method` 헤더를 전달하도록 CloudFront를 구성합니다. + `OPTIONS` 응답을 캐싱하고 싶지 않으면 오리진에서 요청된 다른 모든 헤더와 함께 `Origin` 헤더를 전달하도록 CloudFront를 구성합니다(예: `Access-Control-Request-Headers`, `Access-Control-Request-Method`, 또는 기타). **사용자 지정 오리진** – 오리진에서 요구하는 나머지 헤더와 함께 `Origin` 헤더를 전달합니다. CORS를 기반으로 응답을 캐싱하도록 CloudFront를 구성하려면 캐시 정책을 사용하여 헤더를 전달하도록 CloudFront를 구성해야 합니다. 자세한 내용은 [정책으로 캐시 키 제어](controlling-the-cache-key.md) 섹션을 참조하세요. CORS 및 Amazon S3에 대한 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [교차 원본 리소스 공유(CORS) 사용](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html)을 참조하세요. ## 디바이스 유형을 기반으로 캐싱하도록 구성 CloudFront에서 사용자가 콘텐츠를 보기 위해 사용 중인 디바이스에 따라 여러 버전의 객체를 캐싱하려는 경우, 다음과 같이 적용 가능한 헤더를 사용자 지정 오리진에 전달하도록 CloudFront를 구성합니다. + `CloudFront-Is-Desktop-Viewer` + `CloudFront-Is-Mobile-Viewer` + `CloudFront-Is-SmartTV-Viewer` + `CloudFront-Is-Tablet-Viewer` `User-Agent` 헤더의 값에 따라 CloudFront에서는 요청을 오리진에 전달하기 전에 이러한 헤더의 값을 `true` 또는 `false`로 설정합니다. 디바이스가 둘 이상의 범주에 해당하는 경우 둘 이상의 값이 `true`일 수 있습니다. 예를 들어 일부 태블릿 디바이스의 경우 CloudFront에서는 `CloudFront-Is-Mobile-Viewer`와 `CloudFront-Is-Tablet-Viewer`를 모두 `true`로 설정할 수 있습니다. ## 뷰어 언어를 기반으로 캐싱하도록 구성 CloudFront에서 요청에 지정된 언어에 따라 여러 버전의 객체를 캐싱하려는 경우, `Accept-Language` 헤더를 오리진에 전달하도록 CloudFront를 구성합니다. ## 뷰어 언어를 기반으로 캐싱하도록 구성 CloudFront에서 요청이 시작된 국가에 따라 여러 버전의 객체를 캐싱하려는 경우, `CloudFront-Viewer-Country` 헤더를 오리진에 전달하도록 CloudFront를 구성합니다. CloudFront에서는 자동으로 요청이 시작된 IP 주소를 두 자로 된 국가 코드로 변환합니다. 코드와 국가 이름으로 정렬이 가능하고 사용이 간편한 국가 코드 목록에 대해서는 Wikipedia 항목 [ISO 3166-1 alpha-2](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2)를 참조하십시오. ## 요청의 프로토콜을 기반으로 캐싱하도록 구성 CloudFront에서 HTTP 또는 HTTPS 중 요청의 프로토콜에 따라 여러 버전의 객체를 캐싱하려는 경우, `CloudFront-Forwarded-Proto` 헤더를 오리진에 전달하도록 CloudFront를 구성합니다. ## 압축 파일에 대한 캐싱 구성 원본이 Brotli 압축을 지원하는 경우 `Accept-Encoding` 헤더를 기반으로 캐시할 수 있습니다. 오리진이 이 헤더를 기반으로 하여 다른 콘텐츠를 제공하는 경우에만 `Accept-Encoding`을 기반으로 캐싱하도록 구성합니다. ## 헤더를 기반으로 한 캐싱이 성능에 미치는 영향 하나 이상의 헤더를 기반으로 캐싱하도록 CloudFront를 구성하고 그러한 헤더가 둘 이상의 값을 가질 수 있는 경우, CloudFront에서는 동일한 객체에 대해 더 많은 요청을 오리진 서버에 전달합니다. 이는 성능을 저하시키고 오리진 서버에 걸리는 부하를 가중시킵니다. 오리진 서버에서 지정된 헤더의 값에 상관없이 동일한 객체를 반환하는 경우, 해당 헤더를 기반으로 캐싱하도록 CloudFront를 구성하지 않는 것이 좋습니다. 둘 이상의 헤더를 전달하도록 CloudFront를 구성하는 경우, 최종 사용자 요청의 헤더 순서는 헤더의 값이 동일하다면 캐싱에 영향을 주지 않습니다. 예를 들어 하나의 요청에 A:1,B:2 헤더가 포함되어 있고 다른 요청에는 B:2,A:1이 포함되어 있는 경우, CloudFront에서는 하나의 객체 사본만 캐싱합니다. ## 헤더 및 헤더 값의 대소문자가 캐싱에 미치는 영향 CloudFront에서 헤더 값에 따라 캐싱을 수행할 경우 헤더 이름의 대소문자는 구별하지 않지만 헤더 값의 대소문자는 구별합니다. + 최종 사용자 요청에 `Product:Acme` 및 `product:Acme`가 모두 포함된 경우, CloudFront에서는 객체를 한 번만 캐싱합니다. 이들은 헤더 이름의 대소문자만 다른 경우로, 캐싱에는 영향을 미치지 않습니다. + 최종 사용자 요청에 `Product:Acme` 및 `Product:acme`가 모두 포함된 경우, CloudFront에서는 객체를 두 번 캐싱합니다. 이는 일부 요청에서는 값이 `Acme`이고 다른 요청에서는 `acme`이기 때문입니다. ## CloudFront에서 최종 사용자에게 반환하는 헤더 특정 헤더를 전달하고 캐싱하도록 CloudFront를 구성하는 것은 CloudFront에서 최종 사용자에게 반환하는 헤더의 종류에 영향을 미치지 않습니다. CloudFront에서는 오리진에서 가져온 헤더를 모두 반환하며, 여기에는 몇 가지 예외 사항이 적용됩니다. 자세한 내용은 관련 주제를 참조하십시오. + **Amazon S3 오리진 – **[CloudFront에서 제거하거나 업데이트하는 HTTP 응답 헤더](RequestAndResponseBehaviorS3Origin.md#response-s3-removed-headers) 단원을 참조하십시오. + **사용자 지정 오리진 – **[CloudFront에서 제거하거나 교체하는 HTTP 응답 헤더](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomRemovedHeaders)단원을 참조하십시오.