# 요청 및 응답 동작 다음 주제에서는 CloudFront에서 요청 및 응답을 처리하는 방법을 설명합니다. CloudFront가 Amazon S3 또는 사용자 지정 오리진과 상호 작용하고, 다양한 HTTP 메서드 및 헤더를 취급하고, 상태 코드를 처리하고, 캐싱 및 오류 응답을 관리하는 방법에 대해 알아볼 수 있습니다. **Topics** + [CloudFront에서 HTTP 및 HTTPS 요청을 처리하는 방법](HTTPandHTTPSRequests.md) + [Amazon S3 오리진에 대한 요청 및 응답 동작](RequestAndResponseBehaviorS3Origin.md) + [사용자 지정 오리진에 대한 요청 및 응답 동작](RequestAndResponseBehaviorCustomOrigin.md) + [오리진 그룹에 대한 요청 및 응답 동작](RequestAndResponseBehaviorOriginGroups.md) + [사용자 지정 헤더를 오리진 요청에 추가](add-origin-custom-headers.md) + [CloudFront에서 객체에 대한 부분적인 요청을 처리하는 방법(범위 GET)](RangeGETs.md) + [CloudFront에서 오리진의 HTTP 3xx 상태 코드를 처리하는 방법](http-3xx-status-codes.md) + [CloudFront에서 오리진의 HTTP 4xx 및 5xx 상태 코드를 처리하는 방법](HTTPStatusCodes.md) + [사용자 지정 오류 응답 생성](GeneratingCustomErrorResponses.md) # CloudFront에서 HTTP 및 HTTPS 요청을 처리하는 방법 Amazon S3 오리진의 경우, CloudFront에서는 기본적으로 CloudFront 배포의 객체에 대한 HTTP 및 HTTPS 프로토콜 모두의 요청을 수락합니다. 그런 뒤 CloudFront에서는 요청이 전달된 프로토콜과 같은 프로토콜을 사용하여 이 요청을 Amazon S3 버킷에 전달합니다. 사용자 지정 오리진의 경우 배포를 만들 때 HTTP 전용 또는 최종 사용자가 사용한 프로토콜과 일치 중에 CloudFront에서 오리진에 액세스하는 방법을 지정할 수 있습니다. CloudFront에서 사용자 지정 오리진에 대한 HTTP 및 HTTPS 요청을 처리하는 방법에 대한 자세한 내용은 [프로토콜](RequestAndResponseBehaviorCustomOrigin.md#RequestCustomProtocols) 단원을 참조하십시오. 최종 사용자가 HTTPS만 사용하여 객체에 액세스할 수 있도록 배포를 제한하는 방법에 대한 자세한 내용은 [CloudFront에서 HTTPS 사용](using-https.md) 섹션을 참조하세요. **참고** HTTPS 요청에 대한 요금은 HTTP 요청에 대한 요금에 비해 높습니다. 부과되는 요율에 대한 자세한 내용은 [CloudFront 요금](https://aws.amazon.com/cloudfront/#pricing)을 참조하세요. # Amazon S3 오리진에 대한 요청 및 응답 동작 오리진으로 Amazon S3를 사용할 때 CloudFront에서 요청과 응답을 처리하는 방법을 이해하려면 다음 섹션을 참조하세요. **Topics** + [CloudFront에서 요청을 처리하고 Amazon S3 오리진에 요청을 전달하는 방법](#RequestBehaviorS3Origin) + [CloudFront에서 Amazon S3 오리진의 요청을 처리하는 방법](#ResponseBehaviorS3Origin) ## CloudFront에서 요청을 처리하고 Amazon S3 오리진에 요청을 전달하는 방법 CloudFront에서 뷰어 요청을 처리하고 이 요청을 Amazon S3 오리진에 전달하는 방법을 알아봅니다. **Contents** + [캐싱 시간 및 최소 TTL](#RequestS3Caching) + [클라이언트 IP 주소](#RequestS3IPAddresses) + [조건부 GET 요청](#RequestS3ConditionalGETs) + [Cookies](#RequestS3Cookies) + [교차 오리진 리소스 공유(CORS)](#RequestS3-cors) + [본문이 포함되는 GET 요청](#RequestS3-get-body) + [HTTP 메소드](#RequestS3HTTPMethods) + [CloudFront에서 제거하거나 업데이트하는 HTTP 요청 헤더](#request-s3-removed-headers) + [요청의 최대 길이 및 최대 URL 길이](#RequestS3MaxRequestStringLength) + [OCSP 스테이플링](#request-s3-ocsp-stapling) + [프로토콜](#RequestS3Protocol) + [쿼리 문자열](#RequestS3QueryStrings) + [오리진 연결 제한 시간 및 시도 횟수](#s3-origin-timeout-attempts) + [오리진 응답 제한 시간](#RequestS3RequestTimeout) + [동일 객체에 대한 동시 요청(요청 축소)](#request-s3-traffic-spikes) ### 캐싱 시간 및 최소 TTL CloudFront에서 다른 요청을 오리진에 전달하기 전에 객체를 CloudFront 캐시에 보관하는 시간을 제어하려면 다음을 수행합니다. + `Cache-Control` 또는 `Expires` 헤더 파일을 각 객체에 추가하도록 오리진을 구성합니다. + CloudFront 캐시 동작에 최소 TTL 값을 지정합니다. + 기본값인 24시간을 사용합니다. 자세한 내용은 [콘텐츠가 캐시에 유지되는 기간(만료) 관리](Expiration.md) 단원을 참조하세요. ### 클라이언트 IP 주소 뷰어가 CloudFront에 요청을 보내고 `X-Forwarded-For` 요청 헤더를 포함하지 않는 경우, CloudFront는 TCP 연결에서 뷰어의 IP 주소를 가져오고 IP 주소를 포함하는 `X-Forwarded-For` 헤더를 추가하고 오리진에 요청을 전달합니다. 예를 들어, CloudFront가 TCP 연결에서 IP 주소 `192.0.2.2`를 가져오면 오리진에 다음 헤더를 전달합니다. `X-Forwarded-For: 192.0.2.2` 최종 사용자가 CloudFront에 요청을 보내고 `X-Forwarded-For` 요청 헤더를 포함하는 경우, CloudFront는 TCP 연결에서 최종 사용자의 IP 주소를 가져와 `X-Forwarded-For` 헤더의 끝에 첨부하고 오리진에 요청을 전달합니다. 예를 들어, 최종 사용자 요청에 `X-Forwarded-For: 192.0.2.4,192.0.2.3`이 포함되고 CloudFront가 TCP 연결에서 IP 주소 `192.0.2.2`를 가져오면 오리진에 다음 헤더를 전달합니다. `X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2` **참고** `X-Forwarded-For` 헤더에는 IPv4 주소(예: 192.0.2.44)와 IPv6 주소(예: 2001:0db8:85a3::8a2e:0370:7334)가 포함됩니다. ### 조건부 GET 요청 CloudFront는 엣지 캐시에서 만료된 객체에 대한 요청을 받으면 이 요청을 Amazon S3 오리진으로 전달하여 최신 버전의 객체를 가져오거나 CloudFront 엣지 캐시에 이미 최신 버전이 있는지 Amazon S3의 확인을 받습니다. Amazon S3에서는 처음에 CloudFront에 객체를 보낼 때 `ETag` 값과 `LastModified` 값을 응답에 포함하여 보냈습니다. CloudFront에서 Amazon S3에 전달하는 새 요청에서 CloudFront는 다음 헤더 중 하나 또는 둘 모두를 추가합니다. + 만료된 버전의 객체에 대한 `If-Match` 값을 포함하는 `If-None-Match` 또는 `ETag` 헤더 + 만료된 버전의 객체에 대한 `If-Modified-Since` 값을 포함하는 `LastModified` 헤더 Amazon S3에서는 이 정보를 사용하여 객체가 업데이트되는지와, 그에 따라 전체 객체를 CloudFront에 반환할지 아니면 HTTP 304 상태 코드만 반환할지(수정되지 않음) 여부를 결정합니다. ### Cookies Amazon S3는 쿠키를 처리하지 않습니다. 쿠키를 Amazon S3 오리진에 전달하도록 캐시 동작을 구성하는 경우, CloudFront에서는 이 쿠키를 전달하지만 Amazon S3에서는 이를 무시합니다. 향후 동일한 객체에 대한 모든 요청은 쿠키 변경 여부와 관계없이 캐시에 들어 있는 기존 객체로 처리합니다. ### 교차 오리진 리소스 공유(CORS) CloudFront에서 Amazon S3 CORS(Cross-Origin Resource Sharing) 설정을 준수하도록 하려는 경우 선택한 헤더를 Amazon S3로 전달하도록 CloudFront를 구성합니다. 자세한 내용은 [요청 헤더 기반의 콘텐츠 캐싱](header-caching.md) 단원을 참조하세요. ### 본문이 포함되는 GET 요청 최종 사용자 `GET` 요청에 본문이 포함되는 경우, CloudFront에서는 HTTP 상태 코드 403(금지됨)을 최종 사용자에게 반환합니다. ### HTTP 메소드 지원되는 모든 HTTP 메소드를 처리하도록 CloudFront를 구성하는 경우, CloudFront에서는 최종 사용자의 다음 요청을 수락하고 이를 Amazon S3 오리진에 전달합니다. + `DELETE` + `GET` + `HEAD` + `OPTIONS` + `PATCH` + `POST` + `PUT` CloudFront에서는 `GET` 및 `HEAD` 요청에 대한 응답을 항상 캐싱합니다. 또한 `OPTIONS` 요청에 대한 응답을 캐싱하도록 CloudFront를 구성할 수도 있습니다. CloudFront에서는 다른 메서드를 사용하는 요청에 대한 응답을 캐싱하지 않습니다. 다중 파트 업로드를 사용하여 객체를 Amazon S3 버킷에 추가하려는 경우, CloudFront 오리진 액세스 제어(OAC)를 배포에 추가하고 이 OAC에 필요한 사용 권한을 부여해야 합니다. 자세한 내용은 [Amazon S3 오리진에 대한 액세스 제한](private-content-restricting-access-to-s3.md) 섹션을 참조하세요. **중요** CloudFront에서 지원하는 모든 HTTP 메서드를 허용하고 Amazon S3에 전달하도록 CloudFront를 구성하는 경우, Amazon S3 콘텐츠에 대한 액세스를 제한하는 CloudFront OAC를 만들어 이 OAC에 필수 사용 권한을 부여해야 합니다. 예를 들어, `PUT` 메서드를 사용할 의도로 이러한 메서드를 허용 및 전달하도록 CloudFront를 구성한 경우, 뷰어에 의해 삭제되는 것을 원치 않는 리소스를 이들이 삭제할 수 없도록 `DELETE` 요청을 적절히 처리하여 Amazon S3 버킷 정책을 구성해야 합니다. 자세한 내용은 [Amazon S3 오리진에 대한 액세스 제한](private-content-restricting-access-to-s3.md) 섹션을 참조하세요. Amazon S3에서 지원되는 동작에 대한 자세한 내용은 [Amazon S3 설명서](https://docs.aws.amazon.com/s3/index.html)를 참조하십시오. ### CloudFront에서 제거하거나 업데이트하는 HTTP 요청 헤더 CloudFront는 Amazon S3 오리진에 요청을 전달하기 전에 몇몇 헤더를 제거하거나 업데이트합니다. 대부분의 헤더에서 이 동작은 사용자 지정 오리진에서의 동작과 같습니다. HTTP 요청 헤더의 전체 목록과 CloudFront에서 이를 처리하는 방법은 [HTTP 요청 헤더 및 CloudFront 동작(사용자 지정 및 Amazon S3 오리진)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior) 단원을 참조하십시오. ### 요청의 최대 길이 및 최대 URL 길이 경로, 쿼리 문자열(있는 경우), 헤더를 모두 포함한 요청의 최대 길이는 20,480바이트입니다. CloudFront에서는 이 요청으로부터 URL을 구성합니다. 이 URL의 최대 길이는 8,192바이트입니다. 요청 또는 URL이 최대 길이를 초과할 경우 CloudFront에서는 HTTP 요청 코드 413(요청 개체가 너무 큼)을 반환한 후 뷰어와의TCP 연결을 종료합니다. ### OCSP 스테이플링 뷰어가 객체에 대한 HTTPS 요청을 제출할 때 CloudFront 또는 뷰어는 CA(인증 기관)을 통해 도메인의 SSL 인증서가 해지되지 않았는지 확인해야 합니다. OCSP 스테이플링은 CloudFront에서 인증서의 유효성을 검사하고 CA로부터 응답을 캐싱할 수 있도록 함으로써 클라이언트가 CA를 통해 직접 인증서의 유효성을 검사하지 않아도 되므로 인증서 유효성 검사 속도가 향상됩니다. OSCP 스테이플링의 성능 개선은 CloudFront에서 같은 도메인 내의 객체에 대해 많은 HTTPS 요청을 받은 경우 더욱 확연히 드러납니다. CloudFront 엣지 로케이션의 각 서버는 개별적인 유효성 검사 요청을 제출해야 합니다. CloudFront에서 같은 도메인에 대해 다수의 HTTPS 요청을 받은 경우, 엣지 로케이션의 각 서버에서는 곧 CA로부터 SSL 핸드쉐이크의 패킷에 스테이플할 수 있다는 응답을 받습니다. 뷰어가 인증서가 유효하다는 조건을 충족하면 CloudFront에서는 요청된 객체를 제공할 수 있습니다. 배포가 CloudFront 엣지 로케이션에서 많은 양의 트래픽을 받지 않는 경우, 새로운 요청은 아직 CA를 통해 인증서의 유효성을 검사하지 않은 서버로 리디렉션될 가능성이 높습니다. 그러한 경우, 최종 사용자는 유효성 검사 단계를 개별적으로 수행하고 CloudFront 서버에서는 객체를 제공합니다. 해당 CloudFront 서버에서는 또한 유효성 검사 요청을 CA에 제출하고, 다음에 동일한 도메인 이름을 포함한 요청을 수신하면 CA로부터 유효성 검사 응답을 받습니다. ### 프로토콜 CloudFront에서는 HTTP 또는 HTTPS 요청을 최종 사용자 요청의 프로토콜(HTTP 또는 HTTPS)을 바탕으로 오리진 서버에 전달합니다. **중요** 웹 사이트 엔드포인트로 Amazon S3 버킷이 구성되어 있는 경우, Amazon S3에서 해당 구성으로 HTTPS 연결을 지원하지 않으므로 HTTPS를 사용하여 오리진과 통신하도록 CloudFront를 구성할 수 없습니다. ### 쿼리 문자열 CloudFront에서 쿼리 문자열 파라미터를 Amazon S3 오리진에 전달할지 여부를 구성할 수 있습니다. 자세한 내용은 [쿼리 문자열 파라미터 기반의 콘텐츠 캐싱](QueryStringParameters.md) 단원을 참조하세요. ### 오리진 연결 제한 시간 및 시도 횟수 *오리진 연결 제한 시간*은 CloudFront가 오리진에 대한 연결을 설정하려고 할 때 기다리는 시간(초)입니다. *오리진 연결 시도*는 CloudFront가 오리진에 대한 연결을 시도하는 횟수입니다. 이러한 설정은 모두 CloudFront가 보조 오리진에 대해 장애 조치하거나(오리진 그룹의 경우) 뷰어에 대한 오류 응답을 반환하기 전에 오리진에 대한 연결을 시도하는 시간을 결정합니다. 기본적으로 CloudFront는 보조 오리진에 연결하거나 오류 응답을 반환하기 전에 30초(각각 10초 동안 3회 시도)까지 기다립니다. 더 짧은 연결 제한 시간, 더 적은 시도 횟수 중 하나 또는 둘 다를 지정하여 이 시간을 줄일 수 있습니다. 자세한 내용은 [오리진 제한 시간 및 시도 횟수 제어](high_availability_origin_failover.md#controlling-attempts-and-timeouts) 단원을 참조하세요. ### 오리진 응답 제한 시간 *오리진 응답 제한 시간*(*오리진 읽기 제한 시간* 또는 *오리진 요청 제한 시간*이라고도 함)은 다음 두 값에 모두 적용됩니다. + CloudFront가 오리진에 요청을 전달한 후 응답을 기다리는 시간(초). + CloudFront가 오리진으로부터 응답 패킷을 수신한 후 다음 패킷을 수신할 때까지 대기하는 시간(초). CloudFront 동작은 최종 사용자 요청의 HTTP 메서드에 따라 달라집니다. + `GET` 및 `HEAD` 요청 – 오리진에서 30초 내에 응답하지 않거나 30초 동안 응답이 중지된 경우, CloudFront에서는 연결을 끊습니다. 지정된 [오리진 연결 시도](DownloadDistValuesOrigin.md#origin-connection-attempts) 횟수가 1보다 많으면 CloudFront가 다시 연결을 설정하려고 시도합니다. CloudFront는 *오리진 연결 시도* 설정 값에 따라 최대 3회까지 시도합니다. 오리진이 마지막 시도에 응답하지 않는 경우, CloudFront에서는 동일한 오리진의 콘텐츠에 대해 다른 요청을 받을 때까지 다시 시도하지 않습니다. + `DELETE`, `OPTIONS`, `PATCH`, `PUT` 및 `POST` 요청 – 오리진에서 30초 내에 응답하지 않는 경우, CloudFront에서는 연결을 끊고 오리진에 다시 연결을 시도하지 않습니다. 필요한 경우 클라이언트는 요청을 다시 제출할 수 있습니다. Amazon S3 오리진(정적 웹 사이트 호스팅으로 구성되지 *않은* S3 버킷)에 대한 응답 제한 시간을 변경할 수 없습니다. ### 동일 객체에 대한 동시 요청(요청 축소) CloudFront 엣지 로케이션에서 객체에 대한 요청을 받을 때 객체가 캐시에 있지 않거나 캐시된 객체가 만료된 경우, CloudFront에서는 즉시 요청을 오리진으로 보냅니다. 하지만 동일 객체에 대한 동시 요청이 있는 경우, 즉 CloudFront가 첫 번째 요청에 대한 응답을 수신하기 전에 동일 객체에 대한 추가 요청(동일 캐시 키 포함)이 엣지 로케이션에 도착하는 경우 CloudFront는 추가 요청을 오리진에 전달하기 전에 작업을 일시 중지합니다. 이러한 일시 중지는 오리진에 부하가 걸리는 것을 줄여 줍니다. CloudFront는 원래 요청의 응답을 일시 중지된 동안 수신한 모든 요청에 보냅니다. 이를 *요청 축소*라고 합니다. CloudFront 로그에서, 첫 번째 요청은 `x-edge-result-type` 필드에서 `Miss`로 식별되고 축소된 요청은 `Hit`로 식별됩니다. CloudFront 로그에 대한 자세한 내용은 [CloudFront 및 엣지 함수 로깅](logging.md) 단원을 참조하세요. CloudFront는 [*캐시 키*](understanding-the-cache-key.md)를 공유하는 요청만 축소합니다. 요청 헤더 또는 쿠키 또는 쿼리 문자열에 따라 캐시하도록 CloudFront를 구성하는 등의 이유로 추가 요청이 동일한 캐시 키를 공유하지 않는 경우, CloudFront에서는 고유한 캐시 키가 있는 모든 요청을 오리진에 전달합니다. 모든 요청이 축소되는 것을 방지하려면 캐싱을 방지하는 관리형 캐시 정책 `CachingDisabled`를 사용하면 됩니다. 자세한 내용은 [관리형 캐시 정책 사용](using-managed-cache-policies.md) 섹션을 참조하세요. 특정 객체에 대한 요청 축소를 방지하려면 캐시 동작의 최소 TTL을 0으로 설정하고, *그 후* `Cache-Control: private`, `Cache-Control: no-store`, `Cache-Control: no-cache`, `Cache-Control: max-age=0` 또는 `Cache-Control: s-maxage=0`을 보내도록 오리진을 구성합니다. 이 구성을 사용하면 오리진에 걸리는 부하가 가중되고 CloudFront가 첫 번째 요청에 대한 응답을 기다리는 동안 일시 중지된 동시 요청으로 인한 추가 지연 시간이 발생합니다. **중요** 현재 CloudFront는 [캐시 정책](controlling-the-cache-key.md), [오리진 요청 정책](controlling-origin-requests.md) 또는 레거시 캐시 설정에서 쿠키 전달을 활성화한 경우 요청 축소를 지원하지 않습니다. ## CloudFront에서 Amazon S3 오리진의 요청을 처리하는 방법 CloudFront에서 Amazon S3 오리진의 응답을 처리하는 방법을 알아봅니다. **Contents** + [취소된 요청](#response-s3-canceled-requests) + [CloudFront에서 제거하거나 업데이트하는 HTTP 응답 헤더](#response-s3-removed-headers) + [최대 캐시 가능 파일 크기](#ResponseS3MaxFileSize) + [리디렉션](#ResponseS3Redirects) ### 취소된 요청 객체가 엣지 캐시에 있지 않은 경우 최종 사용자가 CloudFront가 오리진에서 객체를 가져온 뒤 요청된 객체를 제공하기 전에 브라우저 닫기 등으로 세션을 종료하면, CloudFront에서는 엣지 로케이션의 객체를 캐싱하지 않습니다. ### CloudFront에서 제거하거나 업데이트하는 HTTP 응답 헤더 CloudFront는 Amazon S3 오리진에서 최종 사용자에게 응답을 전달하기 전에 다음 헤더 필드를 제거하거나 업데이트합니다. + `X-Amz-Id-2` + `X-Amz-Request-Id` + `Set-Cookie` – 쿠키를 전달하도록 CloudFront를 구성하는 경우, `Set-Cookie` 헤더 필드가 클라이언트에 전달됩니다. 자세한 내용은 [쿠키 기반의 콘텐츠 캐싱](Cookies.md) 단원을 참조하세요. + `Trailer` + `Transfer-Encoding` – Amazon S3 오리진에서 이 헤더 필드를 반환하는 경우, CloudFront에서는 최종 사용자에게 응답을 반환하기 전에 `chunked`에 값을 설정합니다. + `Upgrade` + `Via` – CloudFront는 최종 사용자에 대한 응답으로 값을 다음과 같이 설정합니다. `Via: `*http-version* *alphanumeric-string*`.cloudfront.net (CloudFront)` 예를 들어, 값은 다음과 같습니다. `Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)` ### 최대 캐시 가능 파일 크기 CloudFront에서 캐시에 저장하는 응답 본문의 최대 크기는 50GB입니다. 여기에는 `Content-Length` 헤더 값으로 지정하지 않은 조각난 전송 응답이 포함됩니다. CloudFront를 사용하면 범위 요청을 사용하여 각각 50GB 이하인 부분으로 객체를 요청하여 이보다 큰 객체를 캐시할 수 있습니다. CloudFront는 각 부분이 50GB 이하이기 때문에 이러한 부분을 캐시합니다. 뷰어는 객체의 모든 부분을 검색한 후 원래의 더 큰 객체를 재구성할 수 있습니다. 자세한 내용은 [범위 요청을 사용하여 대형 객체 캐시](RangeGETs.md#cache-large-objects-with-range-requests) 섹션을 참조하세요. ### 리디렉션 모든 요청을 다른 호스트 이름으로 리디렉션하도록 Amazon S3 버킷을 구성할 수 있습니다. 이 대상은 다른 Amazon S3 버킷 또는 HTTP 서버가 될 수 있습니다. 모든 요청을 리디렉션하도록 버킷을 구성하는 경우와 버킷이 CloudFront 배포에 대한 오리진인 경우, 배포의 도메인 이름(예: d111111abcdef8.cloudfront.net) 또는 배포와 연결된 대체 도메인 이름(CNAME)(예: example.com)을 사용하여 모든 요청을 CloudFront 배포에 리디렉션하도록 버킷을 구성하는 것이 좋습니다. 그렇지 않은 경우 최종 사용자는 CloudFront를 우회하도록 요청하고 객체는 새 오리진에서 직접 제공됩니다. **참고** 요청을 대체 도메인 이름으로 리디렉션하는 경우, CNAME 레코드를 추가하여 도메인에 대한 DNS 서비스 역시 업데이트해야 합니다. 자세한 내용은 [대체 도메인 이름(CNAME)을 추가하여 사용자 지정 URL 사용](CNAMEs.md) 단원을 참조하세요. 모든 요청을 리디렉션하도록 버킷을 구성했을 경우 다음과 같은 상황이 발생합니다. 1. 브라우저 등의 최종 사용자가 CloudFront에서 객체를 요청합니다. 1. CloudFront에서는 이 요청을 배포에 대한 오리진인 Amazon S3 버킷에 전달합니다. 1. Amazon S3에서는 HTTP 상태 코드 301(영구적으로 옮겨짐)과 함께 새 위치를 반환합니다. 1. CloudFront에서는 리디렉션 상태 코드와 새 위치를 캐싱하고 최종 사용자에게 값을 반환합니다. CloudFront는 이 리디렉션을 따라가지 않고 새 위치에서 객체를 가져옵니다. 1. 최종 사용자는 객체에 대한 다른 요청을 보내지만, 이때 최종 사용자는 CloudFront에서 가져온 새 위치를 지정합니다. + Amazon S3 버킷에서 모든 요청을 CloudFront 배포로 리디렉션하는 경우, CloudFront에서는 배포의 도메인 이름 또는 대체 도메인 이름을 사용하여 새 위치의 Amazon S3 버킷 또는 HTTP 서버에서 객체를 요청합니다. 새 위치에서 객체를 반환하는 경우, CloudFront에서는 최종 사용자에게 이를 반환하고 엣지 로케이션에 이를 캐싱합니다. + Amazon S3 버킷에서 요청을 다른 위치로 리디렉션하는 경우, 두 번째 요청은 CloudFront를 우회합니다. 새 위치의 Amazon S3 버킷 또는 HTTP 서버에서 최종 사용자에게 직접 객체를 반환하므로 객체는 CloudFront 엣지 캐시에서 캐싱되지 않습니다. # 사용자 지정 오리진에 대한 요청 및 응답 동작 사용자 지정 오리진을 사용할 때 CloudFront에서 요청과 응답을 처리하는 방법을 이해하려면 다음 섹션을 참조하세요. **Topics** + [CloudFront에서 요청을 처리하고 사용자 지정 오리진에 요청을 전달하는 방법](#RequestBehaviorCustomOrigin) + [CloudFront에서 사용자 지정 오리진 서버의 요청을 처리하는 방법](#ResponseBehaviorCustomOrigin) ## CloudFront에서 요청을 처리하고 사용자 지정 오리진에 요청을 전달하는 방법 CloudFront에서 뷰어 요청을 처리하고 이 요청을 사용자 지정 오리진에 전달하는 방법을 알아봅니다. **Contents** + [Authentication](#RequestCustomClientAuth) + [캐싱 시간 및 최소 TTL](#RequestCustomCaching) + [클라이언트 IP 주소](#RequestCustomIPAddresses) + [클라이언트측 SSL 인증](#RequestCustomClientSideSslAuth) + [압축](#RequestCustomCompression) + [조건부 요청](#RequestCustomConditionalGETs) + [Cookies](#RequestCustomCookies) + [교차 오리진 리소스 공유(CORS)](#request-custom-cors) + [암호화](#RequestCustomEncryption) + [본문이 포함되는 GET 요청](#RequestCustom-get-body) + [HTTP 메소드](#RequestCustomHTTPMethods) + [HTTP 요청 헤더 및 CloudFront 동작(사용자 지정 및 Amazon S3 오리진)](#request-custom-headers-behavior) + [HTTP 버전](#RequestCustomHTTPVersion) + [요청의 최대 길이 및 최대 URL 길이](#RequestCustomMaxRequestStringLength) + [OCSP 스테이플링](#request-custom-ocsp-stapling) + [지속적인 연결](#request-custom-persistent-connections) + [프로토콜](#RequestCustomProtocols) + [쿼리 문자열](#RequestCustomQueryStrings) + [오리진 연결 제한 시간 및 시도 횟수](#custom-origin-timeout-attempts) + [오리진 응답 제한 시간](#request-custom-request-timeout) + [동일 객체에 대한 동시 요청(요청 축소)](#request-custom-traffic-spikes) + [`User-Agent` 헤더](#request-custom-user-agent-header) ### Authentication `Authorization` 헤더를 오리진에 전달하는 경우, 다음 요청 유형에 대해 클라이언트 인증을 요청하도록 오리진 서버를 구성할 수 있습니다. + `DELETE` + `GET` + `HEAD` + `PATCH` + `PUT` + `POST` `OPTIONS` 요청의 경우 클라이언트 인증은 다음 CloudFront 설정을 사용하는 경우에만 구성할 수 있습니다:** + CloudFront는 `Authorization` 헤더를 오리진으로 전달하도록 구성됩니다. + CloudFront는 `OPTIONS` 요청에 대한 응답을 캐시하지 않도록 구성됩니다.** 자세한 내용은 [`Authorization` 헤더를 전달하도록 CloudFront 구성](add-origin-custom-headers.md#add-origin-custom-headers-forward-authorization) 섹션을 참조하세요. HTTP 또는 HTTPS를 사용하여 오리진 서버에 요청을 전달할 수 있습니다. 자세한 내용은 [CloudFront에서 HTTPS 사용](using-https.md) 섹션을 참조하세요. ### 캐싱 시간 및 최소 TTL CloudFront에서 다른 요청을 오리진에 전달하기 전에 객체를 CloudFront 캐시에 보관하는 시간을 제어하려면 다음을 수행합니다. + `Cache-Control` 또는 `Expires` 헤더 파일을 각 객체에 추가하도록 오리진을 구성합니다. + CloudFront 캐시 동작에 최소 TTL 값을 지정합니다. + 기본값인 24시간을 사용합니다. 자세한 내용은 [콘텐츠가 캐시에 유지되는 기간(만료) 관리](Expiration.md) 단원을 참조하세요. ### 클라이언트 IP 주소 최종 사용자가 CloudFront에 요청을 보내고 `X-Forwarded-For` 요청 헤더를 포함하지 않는 경우, CloudFront는 TCP 연결에서 최종 사용자의 IP 주소를 가져오고 IP 주소를 포함하는 `X-Forwarded-For` 헤더를 추가하고 오리진에 요청을 전달합니다. 예를 들어, CloudFront가 TCP 연결에서 IP 주소 `192.0.2.2`를 가져오면 오리진에 다음 헤더를 전달합니다. `X-Forwarded-For: 192.0.2.2` 최종 사용자가 CloudFront에 요청을 보내고 `X-Forwarded-For` 요청 헤더를 포함하는 경우, CloudFront는 TCP 연결에서 최종 사용자의 IP 주소를 가져와 `X-Forwarded-For` 헤더의 끝에 첨부하고 오리진에 요청을 전달합니다. 예를 들어, 최종 사용자 요청에 `X-Forwarded-For: 192.0.2.4,192.0.2.3`이 포함되고 CloudFront가 TCP 연결에서 IP 주소 `192.0.2.2`를 가져오면 오리진에 다음 헤더를 전달합니다. `X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2` 로드 밸런서(Elastic Load Balancing 포함), 웹 애플리케이션 방화벽, 역방향 프록시, 침입 방지 시스템 및 API Gateway와 같은 일부 애플리케이션들은 해당 요청을 전달한 CloudFront 엣지 서버의 IP 주소를 `X-Forwarded-For` 헤더의 끝에 추가합니다. 예를 들어, CloudFront가 ELB에 전달하는 요청에 `X-Forwarded-For: 192.0.2.2`를 포함시키고 CloudFront 엣지 서버의 IP 주소가 192.0.2.199인 경우, EC2 인스턴스가 수신하는 요청에는 다음과 같은 헤더가 들어 있습니다. `X-Forwarded-For: 192.0.2.2,192.0.2.199` **참고** `X-Forwarded-For` 헤더에는 IPv4 주소(예: 192.0.2.44)와 IPv6 주소(예: 2001:0db8:85a3::8a2e:0370:7334)가 포함됩니다. 또한 `X-Forwarded-For` 헤더는 현재 서버(CloudFront) 경로에 있는 모든 노드에서 수정할 수 있습니다. 자세한 내용은 [RFC 7239](https://datatracker.ietf.org/doc/html/rfc7239)의 섹션 8.1을 참조하세요. CloudFront 엣지 컴퓨팅 함수를 사용하여 헤더를 수정할 수도 있습니다. ### 클라이언트측 SSL 인증 CloudFront는 클라이언트와 서버가 인증서를 사용하여 서로 인증하는 상호 TLS(mTLS) 인증을 지원합니다. mTLS가 구성된 경우 CloudFront는 TLS 핸드셰이크 중에 클라이언트 인증서를 검증하고 선택적으로 CloudFront Functions를 실행하여 사용자 지정 검증 로직을 구현할 수 있습니다. mTLS가 구성되지 않은 상태에서 오리진이 클라이언트 측 인증서를 요청하는 경우 CloudFront는 요청을 삭제합니다. mTLS 구성에 대한 자세한 내용은 [CloudFront 연결 함수 연결](connection-functions.md) 섹션을 참조하세요. CloudFront는 클라이언트측 SSL 인증서와 클라이언트 인증을 지원하지 않습니다. 오리진이 클라이언트측 인증서를 요청하는 경우 CloudFront에서는 이 요청을 삭제합니다. ### 압축 자세한 내용은 [압축된 파일 제공](ServingCompressedFiles.md) 섹션을 참조하세요. ### 조건부 요청 CloudFront는 엣지 캐시에서 만료된 객체에 대한 요청을 받으면 이 요청을 오리진으로 전달하여 최신 버전의 객체를 가져오거나 CloudFront 엣지 캐시에 이미 최신 버전이 있는지 오리진의 확인을 받습니다. 대개 오리진에서 마지막에 CloudFront에 객체를 보낼 때는 `ETag` 값, `LastModified` 값 또는 두 값 모두를 응답에 포함하여 보냅니다. CloudFront에서 오리진에 전달하는 새 요청에서 CloudFront는 다음 중 하나 또는 둘 모두를 추가합니다. + 만료된 버전의 객체에 대한 `If-Match` 값을 포함하는 `If-None-Match` 또는 `ETag` 헤더 + 만료된 버전의 객체에 대한 `If-Modified-Since` 값을 포함하는 `LastModified` 헤더 오리진에서는 이 정보를 사용하여 객체가 업데이트되는지와, 그에 따라 전체 객체를 CloudFront에 반환할지 아니면 HTTP 304 상태 코드만 반환할지(수정되지 않음) 여부를 결정합니다. **참고** CloudFront가 쿠키(전체 또는 일부)를 전달하도록 구성된 경우 `If-Modified-Since` 및 `If-None-Match` 조건부 요청이 지원되지 않습니다. 자세한 내용은 [쿠키 기반의 콘텐츠 캐싱](Cookies.md) 섹션을 참조하세요. ### Cookies 쿠키를 오리진에 전달하도록 CloudFront를 구성할 수 있습니다. 자세한 내용은 [쿠키 기반의 콘텐츠 캐싱](Cookies.md) 단원을 참조하세요. ### 교차 오리진 리소스 공유(CORS) CloudFront에서 CORS(Cross-Origin Resource Sharing) 설정을 준수하도록 하려는 경우 `Origin` 헤더를 오리진으로 전달하도록 CloudFront를 구성합니다. 자세한 내용은 [요청 헤더 기반의 콘텐츠 캐싱](header-caching.md) 섹션을 참조하세요. ### 암호화 최종 사용자는 HTTPS를 사용하여 CloudFront에 요청을 전송하도록 하고 CloudFront에는 최종 사용자에 의해 사용된 프로토콜을 사용하여 사용자 지정 오리진에 요청을 전달하도록 할 수 있습니다. 자세한 내용은 다음 배포 설정을 참조하십시오. + [뷰어 프로토콜 정책](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy) + [프로토콜(사용자 지정 오리진만 해당)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) CloudFront에서는 SSLv3, TLSv1.0, TLSv1.1, TLSv1.2 및 TLSv1.3 프로토콜을 사용하여 HTTPS 요청을 오리진 서버에 전달합니다. 사용자 지정 오리진의 경우, 오리진과 통신할 때 CloudFront에서 사용하려는 SSL 프로토콜을 선택할 수 있습니다. + CloudFront 콘솔을 사용하는 경우, **오리진 SSL 프로토콜** 확인란을 사용하여 프로토콜을 선택합니다. 자세한 내용은 [배포 생성](distribution-web-creating-console.md) 단원을 참조하세요. + CloudFront API를 사용하는 경우, `OriginSslProtocols` 요소를 사용하여 프로토콜을 지정합니다. 자세한 내용은 *Amazon CloudFront API 참조*의 [OriginSslProtocols](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginSslProtocols.html) 및 [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html)를 참조하십시오. 오리진이 Amazon S3 버킷인 경우 CloudFront는 기본적으로 TLSv1.3을 사용합니다. **중요** 다른 버전의 SSL 및 TLS는 지원되지 않습니다. CloudFront에서 HTTPS를 사용하는 방법은 [CloudFront에서 HTTPS 사용](using-https.md) 단원을 참조하십시오. 최종 사용자와 CloudFront 간의 HTTPS 통신 및 CloudFront와 오리진 간의 HTTPS 통신에 대해 CloudFront가 지원하는 암호 목록은 [최종 사용자와 CloudFront 간에 지원되는 프로토콜 및 암호](secure-connections-supported-viewer-protocols-ciphers.md) 단원을 참조하십시오. ### 본문이 포함되는 GET 요청 최종 사용자 `GET` 요청에 본문이 포함되는 경우, CloudFront에서는 HTTP 상태 코드 403(금지됨)을 최종 사용자에게 반환합니다. ### HTTP 메소드 지원되는 모든 HTTP 메서드를 처리하도록 CloudFront를 구성하는 경우, CloudFront에서는 최종 사용자의 다음 요청을 수락하고 이를 사용자 지정 오리진에 전달합니다. + `DELETE` + `GET` + `HEAD` + `OPTIONS` + `PATCH` + `POST` + `PUT` CloudFront에서는 `GET` 및 `HEAD` 요청에 대한 응답을 항상 캐싱합니다. 또한 `OPTIONS` 요청에 대한 응답을 캐싱하도록 CloudFront를 구성할 수도 있습니다. CloudFront에서는 다른 메서드를 사용하는 요청에 대한 응답을 캐싱하지 않습니다. 사용자 지정 오리진에서 이러한 메소드를 처리할지 여부를 구성하는 방법에 대한 자세한 내용은 오리진에 대한 설명서를 참조하십시오. **중요** CloudFront에서 지원되는 모든 HTTP 메서드를 허용하고 오리진에 전달하도록 CloudFront를 구성한 경우, 모든 메서드를 처리하도록 오리진 서버를 구성합니다. 예를 들어, `POST`를 사용할 의도로 이러한 메서드를 허용 및 전달하도록 CloudFront를 구성한 경우, 최종 사용자에 의해 삭제되는 것을 원치 않는 리소스를 이들이 삭제할 수 없도록 `DELETE` 요청을 적절히 처리하여 오리진 서버를 구성해야 합니다. 자세한 내용은 HTTP 서버에 대한 설명서를 참조하십시오. ### HTTP 요청 헤더 및 CloudFront 동작(사용자 지정 및 Amazon S3 오리진) 다음 테이블에는 사용자 지정 오리진과 Amazon S3 오리진 모두에 전달할 수 있는 HTTP 요청 헤더가 나열되어 있습니다(예외 참조). 각 헤더의 테이블에는 다음에 대한 정보가 포함되어 있습니다. + 헤더를 오리진에 전달하도록 CloudFront를 구성하지 않은 경우의 CloudFront 동작으로, CloudFront에서 헤더 값에 따라 객체를 캐싱하는 원인이 됩니다. + 해당 헤더에 대해 헤더 값에 따라 객체를 캐싱하도록 CloudFront를 구성할 수 있는지 여부. `Date` 및 `User-Agent` 헤더의 값에 따라 객체를 캐싱하도록 CloudFront를 구성할 수 있지만, 권장되지는 않습니다. 이러한 헤더는 여러 가지 값을 가질 수 있으며, 헤더의 값에 따른 캐싱으로 인해 CloudFront에서 오리진에 전달되는 요청이 눈에 띄게 증가할 수 있습니다. 헤더 값에 따른 캐싱에 대한 자세한 내용은 [요청 헤더 기반의 콘텐츠 캐싱](header-caching.md) 단원을 참조하십시오. | 헤더 | 헤더 값에 따라 캐싱하도록 CloudFront를 구성하지 않은 경우의 동작 | 헤더 값에 따른 캐싱이 지원되는지 여부 | | --- | --- | --- | | 기타 정의 헤더 | **레거지 캐시 설정** - CloudFront에서 오리진에 헤더를 전달합니다. | 예 | | `Accept` | CloudFront에서 헤더를 제거합니다. | 예 | | `Accept-Charset` | CloudFront에서 헤더를 제거합니다. | 예 | | `Accept-Encoding` | 값에 `gzip` 또는 `br`이 포함된 경우 CloudFront는 정규화된 `Accept-Encoding` 헤더를 오리진으로 전달합니다. 자세한 내용은 [ 압축 지원](cache-key-understand-cache-policy.md#cache-policy-compressed-objects) 및 [압축된 파일 제공](ServingCompressedFiles.md) 단원을 참조하십시오. | 예 | | `Accept-Language` | CloudFront에서 헤더를 제거합니다. | 예 | | `Authorization` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html) | 예 | | `Cache-Control` | CloudFront에서 오리진에 헤더를 전달합니다. | 아니요 | | `CloudFront-Forwarded-Proto` | 요청을 오리진에 전달하기 전에는 CloudFront에서 헤더를 추가하지 않습니다. 자세한 내용은 [요청의 프로토콜을 기반으로 캐싱하도록 구성](header-caching.md#header-caching-web-protocol) 단원을 참조하세요. | 예 | | `CloudFront-Is-Desktop-Viewer` | 요청을 오리진에 전달하기 전에는 CloudFront에서 헤더를 추가하지 않습니다. 자세한 내용은 [디바이스 유형을 기반으로 캐싱하도록 구성](header-caching.md#header-caching-web-device) 단원을 참조하세요. | 예 | | `CloudFront-Is-Mobile-Viewer` | 요청을 오리진에 전달하기 전에는 CloudFront에서 헤더를 추가하지 않습니다. 자세한 내용은 [디바이스 유형을 기반으로 캐싱하도록 구성](header-caching.md#header-caching-web-device) 단원을 참조하세요. | 예 | | `CloudFront-Is-Tablet-Viewer` | 요청을 오리진에 전달하기 전에는 CloudFront에서 헤더를 추가하지 않습니다. 자세한 내용은 [디바이스 유형을 기반으로 캐싱하도록 구성](header-caching.md#header-caching-web-device) 단원을 참조하세요. | 예 | | `CloudFront-Viewer-Country` | 요청을 오리진에 전달하기 전에는 CloudFront에서 헤더를 추가하지 않습니다. | 예 | | `Connection` | CloudFront 에서는 요청을 오리진에 전달하기 전에 `Connection: Keep-Alive`로 이 헤더를 대체합니다. | 아니요 | | `Content-Length` | CloudFront에서 오리진에 헤더를 전달합니다. | 아니요 | | `Content-MD5` | CloudFront에서 오리진에 헤더를 전달합니다. | 예 | | `Content-Type` | CloudFront에서 오리진에 헤더를 전달합니다. | 예 | | `Cookie` | 쿠키를 전달하도록 CloudFront를 구성한 경우, `Cookie` 헤더 필드가 오리진에 전달됩니다. 그렇지 않으면 CloudFront가 `Cookie` 헤더 필드를 제거합니다. 자세한 내용은 [쿠키 기반의 콘텐츠 캐싱](Cookies.md) 단원을 참조하세요. | 아니요 | | `Date` | CloudFront에서 오리진에 헤더를 전달합니다. | 지원되나 권장되지 않음 | | `Expect` | CloudFront에서 헤더를 제거합니다. | 예 | | `From` | CloudFront에서 오리진에 헤더를 전달합니다. | 예 | | `Host` | CloudFront에서 값을 요청된 객체와 연결된 오리진의 도메인 이름에 설정합니다. Amazon S3 또는 MediaStore 오리진에 대한 호스트 헤더를 기반으로 캐싱을 할 수 없습니다. | 예(사용자 지정) 아니요(S3 및 MediaStore) | | `If-Match` | CloudFront에서 오리진에 헤더를 전달합니다. | 예 | | `If-Modified-Since` | CloudFront에서 오리진에 헤더를 전달합니다. | 예 | | `If-None-Match` | CloudFront에서 오리진에 헤더를 전달합니다. | 예 | | `If-Range` | CloudFront에서 오리진에 헤더를 전달합니다. | 예 | | `If-Unmodified-Since` | CloudFront에서 오리진에 헤더를 전달합니다. | 예 | | `Max-Forwards` | CloudFront에서 오리진에 헤더를 전달합니다. | 아니요 | | `Origin` | CloudFront에서 오리진에 헤더를 전달합니다. | 예 | | `Pragma` | CloudFront에서 오리진에 헤더를 전달합니다. | 아니요 | | `Proxy-Authenticate` | CloudFront에서 헤더를 제거합니다. | 아니요 | | `Proxy-Authorization` | CloudFront에서 헤더를 제거합니다. | 아니요 | | `Proxy-Connection` | CloudFront에서 헤더를 제거합니다. | 아니요 | | `Range` | CloudFront에서 오리진에 헤더를 전달합니다. 자세한 내용은 [CloudFront에서 객체에 대한 부분적인 요청을 처리하는 방법(범위 GET)](RangeGETs.md) 단원을 참조하세요. | 기본적으로 지원됨 | | `Referer` | CloudFront에서 헤더를 제거합니다. | 예 | | `Request-Range` | CloudFront에서 오리진에 헤더를 전달합니다. | 아니요 | | `TE` | CloudFront에서 헤더를 제거합니다. | 아니요 | | `Trailer` | CloudFront에서 헤더를 제거합니다. | 아니요 | | `Transfer-Encoding` | CloudFront에서 오리진에 헤더를 전달합니다. | 아니요 | | `Upgrade` | CloudFront에서는 WebSocket 연결이 설정되지 않았을 경우 헤더를 제거합니다. | 아니요(WebSocket 연결 제외) | | `User-Agent` | CloudFront에서 이 헤더의 값을 `Amazon CloudFront`로 대체합니다. CloudFront에서 사용자가 이용 중인 디바이스에 따라 콘텐츠를 캐싱하도록 하려는 경우, [디바이스 유형을 기반으로 캐싱하도록 구성](header-caching.md#header-caching-web-device) 단원을 참조하십시오. | 지원되나 권장되지 않음 | | `Via` | CloudFront에서 오리진에 헤더를 전달합니다. | 예 | | `Warning` | CloudFront에서 오리진에 헤더를 전달합니다. | 예 | | `X-Amz-Cf-Id` | CloudFront에서는 요청을 오리진에 전달하기 전에 최종 사용자 요청에 헤더를 추가합니다. 헤더 값에는 요청을 고유하게 식별하는 암호화된 문자열이 포함됩니다. | 아니요 | | `X-Edge-*` | CloudFront는 모든 `X-Edge-*` 헤더를 제거합니다. | 아니요 | | `X-Forwarded-For` | CloudFront에서 오리진에 헤더를 전달합니다. 자세한 내용은 [클라이언트 IP 주소](#RequestCustomIPAddresses) 단원을 참조하세요. | 예 | | `X-Forwarded-Proto` | CloudFront에서 헤더를 제거합니다. | 아니요 | | `X-HTTP-Method-Override` | CloudFront에서 헤더를 제거합니다. | 예 | | `X-Real-IP` | CloudFront에서 헤더를 제거합니다. | 아니요 | ### HTTP 버전 CloudFront에서는 HTTP/1.1을 사용하여 사용자 지정 오리진에 요청을 전달합니다. ### 요청의 최대 길이 및 최대 URL 길이 경로, 쿼리 문자열(있는 경우), 헤더를 모두 포함한 요청의 최대 길이는 20,480바이트입니다. CloudFront에서는 이 요청으로부터 URL을 구성합니다. 이 URL의 최대 길이는 8,192바이트입니다. 요청 또는 URL이 이 최대값을 초과할 경우 CloudFront에서는 HTTP 요청 코드 413(요청 개체가 너무 큼)을 반환한 후 최종 사용자와의TCP 연결을 종료합니다. ### OCSP 스테이플링 최종 사용자가 객체에 대한 HTTPS 요청을 제출할 때 CloudFront 또는 최종 사용자는 CA(인증 기관)을 통해 도메인의 SSL 인증서가 해지되지 않았는지 확인해야 합니다. OCSP 스테이플링은 CloudFront에서 인증서의 유효성을 검사하고 CA로부터 응답을 캐싱할 수 있도록 함으로써 클라이언트가 CA를 통해 직접 인증서의 유효성을 검사하지 않아도 되므로 인증서 유효성 검사 속도가 향상됩니다. OSCP 스테이플링의 성능 개선은 CloudFront에서 같은 도메인 내의 객체에 대해 많은 HTTPS 요청을 받은 경우 더욱 확연히 드러납니다. CloudFront 엣지 로케이션의 각 서버는 개별적인 유효성 검사 요청을 제출해야 합니다. CloudFront에서 같은 도메인에 대해 다수의 HTTPS 요청을 받은 경우, 엣지 로케이션의 각 서버에서는 곧 CA로부터 SSL 핸드쉐이크의 패킷에 "스테이플"할 수 있다는 응답을 받습니다. 최종 사용자가 인증서가 유효하다는 조건을 충족하면 CloudFront에서는 요청된 객체를 제공할 수 있습니다. 배포가 CloudFront 엣지 로케이션에서 많은 양의 트래픽을 받지 않는 경우, 새로운 요청은 아직 CA를 통해 인증서의 유효성을 검사하지 않은 서버로 리디렉션될 가능성이 높습니다. 그러한 경우, 최종 사용자는 유효성 검사 단계를 개별적으로 수행하고 CloudFront 서버에서는 객체를 제공합니다. 해당 CloudFront 서버에서는 또한 유효성 검사 요청을 CA에 제출하고, 다음에 동일한 도메인 이름을 포함한 요청을 수신하면 CA로부터 유효성 검사 응답을 받습니다. ### 지속적인 연결 CloudFront가 오리진으로부터 응답을 받는 경우, 그 시간 동안 다른 요청이 도착하면 몇 초 정도 연결을 유지하려고 합니다. 지속적인 연결을 유지하면 TCP 연결 재설정 및 이후 요청에 대한 별도의 TLS 핸드쉐이크 수행에 필요한 시간이 절약됩니다. 지속적 연결의 지속 시간을 구성하는 방법 등 자세한 내용은 [연결 유지 제한 시간(사용자 지정 및 VPC 오리진만 해당)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginKeepaliveTimeout) 단원의 [모든 배포 설정 참조](distribution-web-values-specify.md)을 참조하십시오. ### 프로토콜 CloudFront에서는 다음 사항을 바탕으로 HTTP 또는 HTTPS 요청을 오리진 서버에 전달합니다. + 최종 사용자가 CloudFront에 보낸 요청의 프로토콜(HTTP 또는 HTTPS) + CloudFront 콘솔에서 **오리진 프로토콜 정책** 필드의 값 또는 CloudFront API를 사용 중인 경우 `OriginProtocolPolicy` 복합 형식의 `DistributionConfig` 요소. CloudFront 콘솔에는 **HTTP만 해당**, **HTTPS만 해당** 및 **최종 사용자 일치** 옵션이 있습니다. **HTTP만 해당** 또는 **HTTPS만 해당**을 지정하는 경우, 최종 사용자 요청의 프로토콜과 관계없이 CloudFront에서는 지정된 프로토콜을 사용하여 오리진 서버로 요청을 전달합니다. **최종 사용자 일치**를 지정하는 경우, CloudFront에서는 최종 사용자 요청의 프로토콜을 사용하여 오리진 서버에 요청을 전달합니다. 최종 사용자가 HTTP 및 HTTPS 프로토콜 모두를 사용하여 요청하더라도 CloudFront에서는 한 번만 객체를 캐싱합니다. **중요** CloudFront가 HTTPS 프로토콜을 사용하여 원본으로 요청을 전달하고 오리진 서버가 잘못된 인증서 또는 자체 서명한 인증서를 반환하는 경우, CloudFront에서는 TCP 연결을 끊습니다. CloudFront 콘솔을 사용하여 배포를 업데이트하는 방법에 대한 자세한 내용은 [배포 업데이트](HowToUpdateDistribution.md) 단원을 참조하십시오. CloudFront API를 사용하여 배포를 업데이트하는 방법에 대한 자세한 내용은 *Amazon CloudFront API 참조*의 [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)으로 이동하십시오. ### 쿼리 문자열 CloudFront에서 쿼리 문자열 파라미터를 오리진에 전달할지 여부를 구성할 수 있습니다. 자세한 내용은 [쿼리 문자열 파라미터 기반의 콘텐츠 캐싱](QueryStringParameters.md) 단원을 참조하세요. ### 오리진 연결 제한 시간 및 시도 횟수 *오리진 연결 제한 시간*은 CloudFront가 오리진에 대한 연결을 설정하려고 할 때 기다리는 시간(초)입니다. *오리진 연결 시도*는 CloudFront가 오리진에 대한 연결을 시도하는 횟수입니다. 이러한 설정은 모두 CloudFront가 보조 오리진에 대해 장애 조치하거나(오리진 그룹의 경우) 뷰어에 대한 오류 응답을 반환하기 전에 오리진에 대한 연결을 시도하는 시간을 결정합니다. 기본적으로 CloudFront는 보조 오리진에 연결하거나 오류 응답을 반환하기 전에 30초(각각 10초 동안 3회 시도)까지 기다립니다. 더 짧은 연결 제한 시간, 더 적은 시도 횟수 중 하나 또는 둘 다를 지정하여 이 시간을 줄일 수 있습니다. 자세한 내용은 [오리진 제한 시간 및 시도 횟수 제어](high_availability_origin_failover.md#controlling-attempts-and-timeouts) 단원을 참조하세요. ### 오리진 응답 제한 시간 *오리진 응답 제한 시간*(*오리진 읽기 제한 시간* 또는 *오리진 요청 제한 시간*이라고도 함)은 다음 두 값에 모두 적용됩니다. + CloudFront가 오리진에 요청을 전달한 후 응답을 기다리는 시간(초). + CloudFront가 오리진으로부터 응답 패킷을 수신한 후 다음 패킷을 수신할 때까지 대기하는 시간(초). CloudFront 동작은 최종 사용자 요청의 HTTP 메서드에 따라 달라집니다. + `GET` 및 `HEAD` 요청 - 오리진에서 응답 제한 시간 내에 응답하지 않거나 응답이 중지된 경우, CloudFront에서는 연결을 끊습니다. 지정된 [오리진 연결 시도](DownloadDistValuesOrigin.md#origin-connection-attempts) 횟수가 1보다 많으면 CloudFront가 다시 연결을 설정하려고 시도합니다. CloudFront는 *오리진 연결 시도* 설정 값에 따라 최대 3회까지 시도합니다. 오리진이 마지막 시도에 응답하지 않는 경우, CloudFront에서는 동일한 오리진의 콘텐츠에 대해 다른 요청을 받을 때까지 다시 시도하지 않습니다. + `DELETE`, `OPTIONS`, `PATCH`, `PUT` 및 `POST` 요청 - 오리진이 읽기 제한 시간 동안 응답하지 않는 경우, CloudFront는 연결을 끊고 오리진에 다시 연결을 시도하지 않습니다. 필요한 경우 클라이언트는 요청을 다시 제출할 수 있습니다. 오리진 응답 제한 시간을 구성하는 방법 등 자세한 내용은 [응답 제한 시간](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout) 단원을 참조하십시오. ### 동일 객체에 대한 동시 요청(요청 축소) CloudFront 엣지 로케이션에서 객체에 대한 요청을 받을 때 객체가 캐시에 있지 않거나 캐시된 객체가 만료된 경우, CloudFront에서는 즉시 요청을 오리진으로 보냅니다. 하지만 동일 객체에 대한 동시 요청이 있는 경우, 즉 CloudFront가 첫 번째 요청에 대한 응답을 수신하기 전에 동일 객체에 대한 추가 요청(동일 캐시 키 포함)이 엣지 로케이션에 도착하는 경우 CloudFront는 추가 요청을 오리진에 전달하기 전에 작업을 일시 중지합니다. 이러한 일시 중지는 오리진에 부하가 걸리는 것을 줄여 줍니다. CloudFront는 원래 요청의 응답을 일시 중지된 동안 수신한 모든 요청에 보냅니다. 이를 *요청 축소*라고 합니다. CloudFront 로그에서, 첫 번째 요청은 `x-edge-result-type` 필드에서 `Miss`로 식별되고 축소된 요청은 `Hit`로 식별됩니다. CloudFront 로그에 대한 자세한 내용은 [CloudFront 및 엣지 함수 로깅](logging.md) 단원을 참조하세요. CloudFront는 [*캐시 키*](understanding-the-cache-key.md)를 공유하는 요청만 축소합니다. 요청 헤더 또는 쿠키 또는 쿼리 문자열에 따라 캐시하도록 CloudFront를 구성하는 등의 이유로 추가 요청이 동일한 캐시 키를 공유하지 않는 경우, CloudFront에서는 고유한 캐시 키가 있는 모든 요청을 오리진에 전달합니다. 모든 요청이 축소되는 것을 방지하려면 캐싱을 방지하는 관리형 캐시 정책 `CachingDisabled`를 사용하면 됩니다. 자세한 내용은 [관리형 캐시 정책 사용](using-managed-cache-policies.md) 섹션을 참조하세요. 특정 객체에 대한 요청 축소를 방지하려면 캐시 동작의 최소 TTL을 0으로 설정하고, *그 후* `Cache-Control: private`, `Cache-Control: no-store`, `Cache-Control: no-cache`, `Cache-Control: max-age=0` 또는 `Cache-Control: s-maxage=0`을 보내도록 오리진을 구성합니다. 이 구성을 사용하면 오리진에 걸리는 부하가 가중되고 CloudFront가 첫 번째 요청에 대한 응답을 기다리는 동안 일시 중지된 동시 요청으로 인한 추가 지연 시간이 발생합니다. **중요** 현재 CloudFront는 [캐시 정책](controlling-the-cache-key.md), [오리진 요청 정책](controlling-origin-requests.md) 또는 레거시 캐시 설정에서 쿠키 전달을 활성화한 경우 요청 축소를 지원하지 않습니다. ### `User-Agent` 헤더 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를 구성하는 방법에 대한 자세한 내용은 [요청 헤더 기반의 콘텐츠 캐싱](header-caching.md) 단원을 참조하십시오. `User-Agent` 헤더의 값에 따라 객체를 캐싱하도록 CloudFront를 구성할 수 있지만, 권장되지는 않습니다. `User-Agent` 헤더는 여러 가지 값을 가질 수 있으며, 그러한 값에 따른 캐싱으로 인해 CloudFront에서 오리진에 전달되는 요청이 눈에 띄게 증가할 수 있습니다. `User-Agent` 헤더의 값에 따라 객체를 캐싱하도록 CloudFront를 구성하지 않는 경우, CloudFront에서는 오리진에 요청을 전달하기 전에 다음 값으로 `User-Agent` 헤더를 추가합니다. `User-Agent = Amazon CloudFront` CloudFront에서는 최종 사용자의 요청에 `User-Agent` 헤더가 포함되어 있는지와 관계없이 이 헤더를 추가합니다. 최종 사용자의 요청에 `User-Agent` 헤더가 포함되어 있는 경우, CloudFront에서는 이를 제거합니다. ## CloudFront에서 사용자 지정 오리진 서버의 요청을 처리하는 방법 CloudFront에서 사용자 지정 오리진 서버의 요청을 처리하는 방법을 알아봅니다. **Contents** + [`100 Continue` 응답](#Response100Continue) + [캐싱](#ResponseCustomCaching) + [취소된 요청](#response-custom-canceled-requests) + [콘텐츠 협상](#ResponseCustomContentNegotiation) + [Cookies](#ResponseCustomCookies) + [TCP 연결 끊김](#ResponseCustomDroppedTCPConnections) + [CloudFront에서 제거하거나 교체하는 HTTP 응답 헤더](#ResponseCustomRemovedHeaders) + [최대 캐시 가능 파일 크기](#ResponseCustomMaxFileSize) + [오리진 사용 불가](#ResponseCustomOriginUnavailable) + [리디렉션](#ResponseCustomRedirects) + [`Transfer-Encoding` 헤더](#ResponseCustomTransferEncoding) ### `100 Continue` 응답 오리진은 CloudFront에 하나 이상의 100-continue 응답을 전송할 수 없습니다. 첫 번째 100-continue 응답 후에 CloudFront는 HTTP 200 OK 응답을 예상합니다. 오리진이 첫 번째 응답 후 또 다른 100-continue 응답을 전송하면 CloudFront는 오류를 반환합니다. ### 캐싱 + 오리진 서버에서 `Date` 및 `Last-Modified` 헤더 필드에 유효하고 정확한 값을 설정했는지 확인합니다. + CloudFront에서는 오리진의 응답으로 보통 `Cache-Control: no-cache` 헤더를 신뢰합니다. 예외 사항은 [동일 객체에 대한 동시 요청(요청 축소)](#request-custom-traffic-spikes) 단원을 참조하십시오. ### 취소된 요청 객체가 엣지 캐시에 있지 않은 경우 최종 사용자가 CloudFront가 오리진에서 객체를 가져온 뒤 요청된 객체를 제공하기 전에 브라우저 닫기 등으로 세션을 종료하면, CloudFront에서는 엣지 로케이션의 객체를 캐싱하지 않습니다. ### 콘텐츠 협상 오리진이 응답에서 `Vary:*`를 반환하는 경우와 해당 캐시 동작의 **Minimum TTL** 값이 **0**인 경우, CloudFront에서는 객체를 캐싱하지만 오리진에 객체의 모든 후속 요청을 전송하여 캐시에 객체의 최신 버전이 포함되어 있음을 확인합니다. CloudFront에는 `If-None-Match` 또는 `If-Modified-Since`와 같은 조건부 헤더가 포함되지 않습니다. 결과적으로 오리진은 모든 요청에 응답하여 객체를 CloudFront에 반환합니다. 오리진이 응답에서 `Vary:*`를 반환하는 경우와 해당 캐시 동작의 **Minimum TTL** 값이 다른 값인 경우, CloudFront에서는 `Vary`에 설명된 [CloudFront에서 제거하거나 교체하는 HTTP 응답 헤더](#ResponseCustomRemovedHeaders) 헤더를 처리합니다. ### Cookies 캐시 동작에 대한 쿠키를 활성화한 경우 오리진에서 객체를 통해 쿠키를 반환하면 CloudFront에서는 객체와 쿠키를 모두 캐싱합니다. 이를 통해 객체에 대한 캐싱 가능성이 줄어듭니다. 자세한 내용은 [쿠키 기반의 콘텐츠 캐싱](Cookies.md) 단원을 참조하세요. ### TCP 연결 끊김 오리진이 객체를 CloudFront에 반환하는 동안 CloudFront와 오리진 간의 TCP 연결이 끊어진 경우, CloudFront 동작은 오리진이 응답에 `Content-Length` 헤더를 포함했는지 여부에 따라 달라집니다. + **Content-Length 헤더** – CloudFront에서는 오리진에서 객체를 가져오는 동안 최종 사용자에게 객체를 반환합니다. 그러나 `Content-Length` 헤더의 값이 객체의 크기와 일치하지 않는 경우, CloudFront에서는 객체를 캐싱하지 않습니다. + **Transfer-Encoding: Chunked** – CloudFront에서는 오리진에서 객체를 가져오는 동안 최종 사용자에게 객체를 반환합니다. 그러나 조각난 응답이 완전하지 않은 경우, CloudFront에서는 객체를 캐싱하지 않습니다. + **No Content-Length 헤더** – CloudFront에서는 최종 사용자에게 객체를 반환하고 이를 캐싱하지만, 이 객체는 불완전할 수 있습니다. CloudFront에서는 `Content-Length` 헤더 없이는 TCP 연결이 실수로 또는 고의로 끊어졌는지 여부를 판단할 수 없습니다. `Content-Length` 헤더를 추가하여 CloudFront에서 부분적인 객체를 캐싱하지 못하도록 HTTP 서버를 구성하는 것이 좋습니다. ### CloudFront에서 제거하거나 교체하는 HTTP 응답 헤더 CloudFront는 오리진에서 최종 사용자에게 응답을 전달하기 전에 다음 헤더 필드를 제거하거나 업데이트합니다. + `Set-Cookie` – 쿠키를 전달하도록 CloudFront를 구성하는 경우, `Set-Cookie` 헤더 필드가 클라이언트에 전달됩니다. 자세한 내용은 [쿠키 기반의 콘텐츠 캐싱](Cookies.md) 단원을 참조하세요. + `Trailer` + `Transfer-Encoding` – 오리진에서 이 헤더 필드를 반환하는 경우, CloudFront에서는 최종 사용자에게 응답을 반환하기 전에 `chunked`에 값을 설정합니다. + `Upgrade` + `Vary` – 다음을 참조하십시오. + 디바이스별 헤더 중 하나를 오리진(`CloudFront-Is-Desktop-Viewer`, `CloudFront-Is-Mobile-Viewer`, `CloudFront-Is-SmartTV-Viewer`, `CloudFront-Is-Tablet-Viewer`)에 전달하도록 CloudFront를 구성하고 `Vary:User-Agent`를 CloudFront에 반환하도록 오리진을 구성하는 경우, CloudFront에서는 최종 사용자에게 `Vary:User-Agent`를 반환합니다. 자세한 내용은 [디바이스 유형을 기반으로 캐싱하도록 구성](header-caching.md#header-caching-web-device) 단원을 참조하세요. + `Accept-Encoding` 헤더에서 `Cookie` 또는 `Vary`를 포함하도록 오리진을 구성하는 경우, CloudFront는 최종 사용자에 대한 응답에 대한 값을 포함합니다. + 헤더를 오리진에 전달하도록 CloudFront를 구성하는 경우와 `Vary` 헤더(예: `Vary:Accept-Charset,Accept-Language`)의 CloudFront에 헤더 이름을 반환하도록 오리진을 구성하는 경우, CloudFront에서는 최종 사용자에게 `Vary` 헤더를 그 값과 함께 반환합니다. + CloudFront가 `*` 헤더의 `Vary` 값을 처리하는 방법에 대한 자세한 내용은 [콘텐츠 협상](#ResponseCustomContentNegotiation) 단원을 참조하십시오. + `Vary` 헤더에 그 밖의 값을 포함하도록 오리진을 구성하는 경우, CloudFront는 최종 사용자에게 응답을 반환하기 전에 값을 제거합니다. + `Via` – CloudFront는 최종 사용자에 대한 응답으로 값을 다음과 같이 설정합니다. `Via: `*http-version* *alphanumeric-string*`.cloudfront.net (CloudFront)` 예를 들어, 값은 다음과 같습니다. `Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)` ### 최대 캐시 가능 파일 크기 CloudFront에서 캐시에 저장하는 응답 본문의 최대 크기는 50GB입니다. 여기에는 `Content-Length` 헤더 값으로 지정하지 않은 조각난 전송 응답이 포함됩니다. CloudFront를 사용하면 범위 요청을 사용하여 각각 50GB 이하인 부분으로 객체를 요청하여 이보다 큰 객체를 캐시할 수 있습니다. CloudFront는 각 부분이 50GB 이하이기 때문에 이러한 부분을 캐시합니다. 뷰어는 객체의 모든 부분을 검색한 후 원래의 더 큰 객체를 재구성할 수 있습니다. 자세한 내용은 [범위 요청을 사용하여 대형 객체 캐시](RangeGETs.md#cache-large-objects-with-range-requests) 섹션을 참조하세요. ### 오리진 사용 불가 오리진 서버를 사용할 수 없고 CloudFront에서 엣지 캐시에 있지만 만료된(`Cache-Control max-age` 명령에 지정된 기간이 지났다는 이유 등으로) 객체에 대한 요청을 받은 경우, CloudFront에서는 만료된 버전의 객체를 제공하거나 사용자 지정 오류 페이지를 표시합니다. 사용자 지정 오류 페이지를 구성한 경우 CloudFront 동작에 대한 자세한 내용은 [사용자 지정 오류 페이지를 구성했을 때 CloudFront에서 오류를 처리하는 방법](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages) 단원을 참조하십시오. 경우에 따라 자주 요청되지는 않는 객체는 제거되고 엣지 캐시에서 더 이상 사용할 수 없게 됩니다. CloudFront에서는 제거된 객체를 제공할 수 없습니다. ### 리디렉션 오리진 서버에 있는 객체의 위치를 변경하는 경우 요청을 새 위치로 리디렉션하도록 웹 서버를 구성할 수 있습니다. 리디렉션을 구성한 뒤 처음으로 뷰어가 객체에 대한 요청을 제출할 때 CloudFront에서는 요청을 오리진에 전송하고 오리진에서는 리디렉션으로 응답합니다(예: `302 Moved Temporarily`). CloudFront에서는 이 리디렉션을 캐싱하고 최종 사용자에게 이를 반환합니다. CloudFront에서는 이 리디렉션을 따라가지 않습니다. 다음 위치 중 하나로 요청을 리디렉션하도록 웹 서버를 구성할 수 있습니다. + 오리진 서버에 있는 객체의 새 URL입니다. 최종 사용자가 새 URL에 대한 리디렉션을 따라갈 때 최종 사용자는 CloudFront를 우회하고 오리진으로 직행합니다. 따라서 오리진에 있는 객체의 새 URL로 요청을 리디렉션하지 않는 것이 좋습니다. + 객체에 대한 새 CloudFront URL입니다. 최종 사용자가 새 CloudFront URL을 포함한 요청을 제출할 때, CloudFront는 새 위치에서 객체를 가져오고 이를 엣지 로케이션에서 캐싱하여 최종 사용자에게 반환합니다. 이 객체에 대한 후속 요청은 엣지 로케이션에서 제공됩니다. 이를 통해 최종 사용자의 오리진에서의 객체 요청과 관련된 시간 지연과 로드 발생을 피할 수 있습니다. 그러나 객체에 대한 새로운 요청이 발생할 때마다 CloudFront에 대한 두 개의 요청에 대해 요금이 부과됩니다. ### `Transfer-Encoding` 헤더 CloudFront에서는 `chunked` 헤더에 대해 `Transfer-Encoding` 값만 지원합니다. 오리진에서 `Transfer-Encoding: chunked`를 반환하는 경우, CloudFront에서는 객체를 엣지 로케이션에서 수신한 객체로 클라이언트에 반환하고 후속 요청에 대해 조각난 형식의 객체를 캐싱합니다. 최종 사용자가 `Range GET` 요청을 하고 오리진이 `Transfer-Encoding: chunked`를 반환하는 경우, CloudFront에서는 요청한 범위 대신에 최종 사용자에 전체 객체를 반환합니다. 응답의 콘텐츠 길이를 사전에 결정할 수 없는 경우 chunked 인코딩을 사용하는 것이 좋습니다. 자세한 내용은 [TCP 연결 끊김](#ResponseCustomDroppedTCPConnections) 단원을 참조하세요. # 오리진 그룹에 대한 요청 및 응답 동작 오리진 그룹에 대한 요청은, 오리진 장애 조치가 있는 경우를 제외하면, 오리진 그룹으로 설정되지 않은 오리진에 대한 요청과 동일하게 작동합니다. 다른 모든 오리진에서와 마찬가지로, CloudFront가 요청을 수신하고 콘텐츠가 이미 엣지 로케이션에 캐싱되는 경우 콘텐츠는 캐시로부터 최종 사용자에게 제공됩니다. 캐시 누락이 있고 오리진이 오리진 그룹인 경우, 최종 사용자의 요청은 오리진 그룹의 기본 오리진으로 전달됩니다. 기본 오리진에 대한 요청 및 응답 동작은 오리진 그룹에 없는 오리진에 대한 경우와 동일합니다. 자세한 내용은 [Amazon S3 오리진에 대한 요청 및 응답 동작](RequestAndResponseBehaviorS3Origin.md) 및 [사용자 지정 오리진에 대한 요청 및 응답 동작](RequestAndResponseBehaviorCustomOrigin.md) 단원을 참조하십시오. 다음은 기본 오리진이 특정 HTTP 상태 코드를 반환할 때의 오리진 장애 조치에 대한 동작에 대한 설명입니다. + HTTP 2xx 상태 코드(성공): CloudFront가 파일을 캐싱하여 최종 사용자에게 반환합니다. + HTTP 3xx 상태 코드(리디렉션): CloudFront가 상태 코드를 최종 사용자에게 반환합니다. + HTTP 4xx 또는 5xx 상태 코드(클라이언트/서버 오류): 반환된 상태 코드가 장애 조치에 대해 구성된 경우, CloudFront가 오리진 그룹의 보조 오리진에 동일한 요청을 전송합니다. + HTTP 4xx 또는 5xx 상태 코드(클라이언트/서버 오류): 반환된 상태 코드가 장애 조치에 대하여 구성된 경우, CloudFront가 오류를 최종 사용자에게 반환합니다. CloudFront는 최종 사용자 요청의 HTTP 메서드가 `GET`, `HEAD` 또는 `OPTIONS`인 경우에만 보조 오리진으로 장애 조치합니다. 최종 사용자가 다른 HTTP 메서드(예: `POST`, `PUT` 등)를 보내면 CloudFront는 장애 조치를 수행하지 않습니다. CloudFront에서 요청을 보조 오리진에 전송하는 경우, 응답 동작은 오리진 그룹에 없는 CloudFront 오리진에 대한 동작과 동일합니다. 오리진 그룹에 대한 자세한 내용은 [CloudFront 오리진 장애 조치를 통한 고가용성 최적화](high_availability_origin_failover.md) 단원을 참조하십시오. # 사용자 지정 헤더를 오리진 요청에 추가 오리진으로 보내는 요청에 사용자 지정 헤더를 추가하도록 CloudFront를 구성할 수 있습니다. 사용자 지정 헤더를 사용하면 일반적인 뷰어 요청을 통해 얻을 수 없는 정보를 오리진에서 보내고 수집할 수 있습니다. 각 오리진에 대해 이러한 헤더를 사용자 지정할 수도 있습니다. CloudFront는 사용자 지정 오리진 및 Amazon S3 오리진에 대해 사용자 지정 헤더를 지원합니다. **Contents** + [사용 사례](#add-origin-custom-headers-use-cases) + [사용자 지정 헤더를 오리진 요청에 추가하도록 CloudFront 구성](#add-origin-custom-headers-configure) + [CloudFront에서 오리진 요청에 추가할 수 없는 사용자 지정 헤더](#add-origin-custom-headers-denylist) + [`Authorization` 헤더를 전달하도록 CloudFront 구성](#add-origin-custom-headers-forward-authorization) ## 사용 사례 다음 예와 같이 사용자 지정 헤더를 사용할 수 있습니다. **CloudFront에서 요청 식별** 오리진이 CloudFront에서 수신한 요청을 식별할 수 있습니다. 사용자가 CloudFront를 우회하는지 알고 싶은 경우나 2개 이상의 CDN을 사용하고 있는데 어떤 요청이 각 CDN에서 오는지에 대한 정보를 원하는 경우 유용합니다. Amazon S3 오리진을 사용하고 [Amazon S3 서버 액세스 로깅](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)을 활성화하는 경우, 로그에는 헤더 정보가 포함되지 않습니다. **어떤 요청이 특정 배포에서 오는지 확인** 동일한 오리진을 사용하도록 둘 이상의 CloudFront 배포를 구성하는 경우, 각 배포에 각각 다른 사용자 지정 헤더를 추가할 수 있습니다. 그러면 오리진의 로그를 사용하여 어떤 요청이 어떤 CloudFront 배포에서 왔는지 확인할 수 있습니다. **Cross-Origin 리소스 공유(CORS) 활성화** 일부 최종 사용자가 Cross-Origin 리소스 공유(CORS)를 지원하지 않는 경우, 오리진으로 보내는 요청에 `Origin` 헤더를 항상 추가하도록 CloudFront를 구성할 수 있습니다. 그러면 모든 요청에 대해 `Access-Control-Allow-Origin` 헤더를 반환하도록 오리진을 구성할 수 있습니다. 또한 [CORS 설정을 준수하도록 CloudFront를 구성](header-caching.md#header-caching-web-cors)해야 합니다. **콘텐츠에 대한 액세스 제어** 사용자 지정 헤더를 사용하여 콘텐츠에 대한 액세스를 제어할 수 있습니다. CloudFront에 의해 추가된 사용자 지정 헤더가 포함된 경우에만 요청에 응답하도록 오리진을 구성하여 사용자가 CloudFront를 우회하는 것과 오리진에서 직접 콘텐츠에 액세스하는 것을 방지할 수 있습니다. 자세한 내용은 [사용자 지정 오리진의 파일에 대한 액세스 제한](private-content-overview.md#forward-custom-headers-restrict-access) 섹션을 참조하세요. ## 사용자 지정 헤더를 오리진 요청에 추가하도록 CloudFront 구성 오리진으로 보내는 요청에 사용자 지정 헤더를 추가하도록 배포를 구성하려면 다음 방법 중 하나를 사용하여 오리진의 구성을 업데이트합니다. + **CloudFront 콘솔** – 배포를 생성 또는 업데이트할 경우, **사용자 지정 헤더 추가** 설정에 헤더 이름과 값을 지정합니다. 자세한 내용은 [사용자 지정 헤더 추가](DownloadDistValuesOrigin.md#DownloadDistValuesOriginCustomHeaders) 섹션을 참조하세요. + **CloudFront API** – 사용자 지정 헤더를 추가하려는 각 오리진에 대해 `Origin` 필드 내부 `CustomHeaders`에 헤더 이름과 값을 지정합니다. 자세한 내용은 **Amazon CloudFront API 참조의 [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) 또는 [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)를 참조하세요. 지정하는 헤더 이름과 값이 아직 최종 사용자 요청에 있지 않은 경우, CloudFront는 이를 오리진 요청에 추가합니다. 헤더가 있는 경우, CloudFront는 오리진에 요청을 전달하기 전에 헤더 값을 덮어씁니다. 오리진 사용자 지정 헤더에 적용되는 할당량에 대한 자세한 내용은 [헤더에 대한 할당량](cloudfront-limits.md#limits-custom-headers) 섹션을 참조하세요. ## CloudFront에서 오리진 요청에 추가할 수 없는 사용자 지정 헤더 오리진으로 보내는 요청에 다음 헤더 중 하나라도 추가하도록 CloudFront를 구성할 수 없습니다. + `Cache-Control` + `Connection` + `Content-Length` + `Cookie` + `Host` + `If-Match` + `If-Modified-Since` + `If-None-Match` + `If-Range` + `If-Unmodified-Since` + `Max-Forwards` + `Pragma` + `Proxy-Authenticate` + `Proxy-Authorization` + `Proxy-Connection` + `Range` + `Request-Range` + `TE` + `Trailer` + `Transfer-Encoding` + `Upgrade` + `Via` + `X-Amz-`로 시작되는 헤더 + `X-Edge-`로 시작되는 헤더 + `X-Real-Ip` ## `Authorization` 헤더를 전달하도록 CloudFront 구성 CloudFront에서 최종 사용자 요청을 오리진에 전달할 때 `Authorization` 헤더를 포함한 일부 최종 사용자 헤더는 기본적으로 제거됩니다. 오리진 요청의 `Authorization` 헤더가 오리진에 항상 수신되도록 하려면 다음 옵션을 선택할 수 있습니다. + 캐시 정책을 사용하여 캐시 키에 `Authorization` 헤더를 추가합니다. 캐시 키의 모든 헤더가 오리진 요청에 자동으로 포함됩니다. 자세한 내용은 [정책으로 캐시 키 제어](controlling-the-cache-key.md) 섹션을 참조하세요. + 모든 최종 사용자 헤더를 오리진으로 전달하는 오리진 요청 정책을 사용합니다. 오리진 요청 정책에서 `Authorization` 헤더를 개별적으로 전달할 수는 없지만 모든 최종 사용자 헤더를 전달하면 CloudFront에서 최종 사용자 요청에 `Authorization` 헤더를 포함합니다. CloudFront는 이 사용 사례를 위해 **Managed-AllViewer**라는 관리형 오리진 요청 정책을 제공합니다. 자세한 내용은 [관리형 오리진 요청 정책 사용](using-managed-origin-request-policies.md) 섹션을 참조하세요. # CloudFront에서 객체에 대한 부분적인 요청을 처리하는 방법(범위 GET) 대용량 객체의 경우 뷰어(웹 브라우저 또는 기타 클라이언트)는 여러 `GET` 요청을 하고 `Range` 요청 헤더를 사용하여 객체를 더 작은 부분으로 다운로드할 수 있습니다. `Range GET` 요청이라고도 하는 이러한 바이트 범위의 요청을 통해 부분 다운로드의 효율을 높이고 부분적으로 실패한 전송을 쉽게 복구할 수 있습니다. CloudFront에서 `Range GET` 요청을 받은 경우, 요청을 받은 엣지 로케이션에서 캐시를 확인합니다. 엣지 로케이션의 캐시에 이미 전체 객체 또는 객체의 요청된 부분이 포함되어 있는 경우, CloudFront에서는 캐시로부터 요청된 범위를 즉시 제공합니다. 캐시에 요청된 범위가 포함되어 있지 않은 경우, CloudFront에서는 요청을 원본에 전달합니다. (성능 최적화를 위해 CloudFront에서는 클라이언트가 `Range GET`에서 요청한 것보다 더 큰 범위를 요청할 수 있습니다.) 오리진에서 `Range GET` 요청을 지원하는지 여부에 따라 다음 상황이 달라집니다. + **오리진에서 `Range GET` 요청을 지원하는 경우** - 요청된 범위를 반환합니다. CloudFront에서는 요청된 범위를 제공하고 이를 이후 요청을 위해 캐싱합니다. (Amazon S3는 많은 HTTP 서버와 마찬가지로 `Range GET` 요청을 지원합니다.) + **오리진에서 `Range GET` 요청을 지원하지 않는 경우** - 전체 객체를 반환합니다. CloudFront에서는 전체 객체를 전송하고 향후 요청을 위해 캐싱하여 현재 요청을 처리합니다. CloudFront에서 엣지 캐시에 전체 객체를 캐싱한 후에는 요청된 범위를 제공하여 새 `Range GET` 요청에 응답합니다. 두 경우 모두 오리진에서 첫 번째 바이트가 도착하면 CloudFront에서는 요청된 범위 또는 객체를 최종 사용자에게 제공하기 시작합니다. **참고** 최종 사용자가 `Range GET` 요청을 하고 오리진이 `Transfer-Encoding: chunked`를 반환하는 경우, CloudFront에서는 요청한 범위 대신에 최종 사용자에 전체 객체를 반환합니다. CloudFront에서는 일반적으로 `Range` 헤더에 대한 RFC 사양을 준수합니다. 그러나 `Range` 헤더가 다음 요구 사항을 준수하지 않는 경우, CloudFront에서는 지정된 범위와 함께 상태 코드 `200`을 반환하는 대신 전체 객체와 함께 HTTP 상태 코드 `206`을 반환합니다. + 범위는 오름차순으로 나열되어야 합니다. 예를 들어, `100-200,300-400`은 유효하지만 `300-400,100-200`은 유효하지 않습니다. + 범위는 중복되어서는 안 됩니다. 예를 들어, `100-200,150-250`은 유효하지 않습니다. + 모든 범위 사양은 유효해야 합니다. 예를 들어, 범위의 일부로 음수 값을 지정할 수 없습니다. `Range` 요청 헤더에 대한 자세한 내용은 RFC 7233의 [요청 범위](https://httpwg.org/specs/rfc7233.html#range.requests) 또는 MDN 웹 문서의 [범위](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range)를 참조하십시오. ## 범위 요청을 사용하여 대형 객체 캐시 캐싱이 활성화되면 CloudFront는 50GB보다 큰 객체를 검색하거나 캐시하지 않습니다. 원본이 객체가 이보다 크다는 것을 나타내는 경우(`Content-Length` 응답 헤더에서), CloudFront는 원본에 대한 연결을 닫고 뷰어에게 오류를 반환합니다. (캐싱을 비활성화하면 CloudFront는 원본에서 이보다 큰 객체를 검색하여 뷰어에 전달할 수 있습니다. 그러나 CloudFront는 객체를 캐시하지 않습니다.) 그러나 범위 요청의 경우 CloudFront를 사용하여 [최대 캐시 가능 파일 크기](cloudfront-limits.md#limits-web-distributions)보다 큰 객체를 캐시할 수 있습니다. **Example 예제** 1. 예를 들어 100GB 객체가 있는 오리진을 가정해 보겠습니다. 캐싱이 활성화되면 CloudFront는 이렇게 큰 객체를 검색하거나 캐시하지 않습니다. 그러나 뷰어는 이 객체를 50GB보다 작은 각 부분으로 검색하기 위해 여러 범위 요청을 보낼 수 있습니다. 1. 뷰어는 첫 번째 부분을 검색하기 위해 헤더 `Range: bytes=0-21474836480`가 포함된 요청, 다음 부분을 검색하기 위해 헤더 `Range: bytes=21474836481-42949672960`가 포함된 다른 요청을 전송하는 등의 방식으로 20GB 부분의 객체를 요청할 수 있습니다. 1. 뷰어가 모든 부분을 받으면 이를 결합하여 원래 100GB 객체를 구성할 수 있습니다. 1. 이 경우 CloudFront는 객체의 20GB 부분을 캐시하고 캐시에서 동일한 부분에 대한 후속 요청에 응답할 수 있습니다. 압축된 객체에 대한 범위 요청의 경우 바이트 범위 요청은 객체의 원래 크기가 아닌 압축된 크기를 기반으로 합니다. 압축에 대한 자세한 내용은 [압축된 파일 제공](ServingCompressedFiles.md) 섹션을 참조하시기 바랍니다. # CloudFront에서 오리진의 HTTP 3xx 상태 코드를 처리하는 방법 CloudFront가 Amazon S3 버킷 또는 사용자 지정 오리진 서버에서 객체를 요청하는 경우 오리진에서 HTTP S3 상태 코드를 반환하는 경우가 있습니다. 이 메시지는 일반적으로 다음 중 하나를 나타냅니다. + 객체의 URL이 변경되었습니다(예: 상태 코드 301, 302, 307 또는 308). + 마지막으로 CloudFront가 요청한 이후 개체가 변경되지 않았습니다(상태 코드 304). CloudFront는 CloudFront 배포의 설정 및 응답의 헤더에 따라 3xx 응답을 캐싱합니다. CloudFront는 원본의 응답에 `Cache-Control` 헤더를 포함하는 경우에만 307 및 308 응답을 캐시합니다. 자세한 내용은 [콘텐츠가 캐시에 유지되는 기간(만료) 관리](Expiration.md) 섹션을 참조하세요. 오리진에서 리디렉션 상태 코드(예: 301 또는 307)를 반환하는 경우 CloudFront는 리디렉션을 따르지 않습니다. CloudFront는 최종 사용자에게 301 또는 307 응답을 전달하며, 최종 사용자는 새 요청을 전송하여 리디렉션을 따를 수 있습니다. # CloudFront에서 오리진의 HTTP 4xx 및 5xx 상태 코드를 처리하는 방법 CloudFront가 Amazon S3 버킷 또는 사용자 지정 오리진 서버에서 객체를 요청할 때, 오리진에서 오류가 발생했음을 나타내는 HTTP 4xx 또는 5xx 상태 코드를 반환하는 경우가 있습니다. CloudFront 동작은 다음에 따라 달라집니다. + 사용자 지정 오류 페이지를 구성했는지 여부 + CloudFront에서 오리진으로부터 오류 응답을 캐싱하려는 시간(오류 캐싱 최소 TTL)을 구성했는지 여부 + 상태 코드 + 5xx 상태 코드의 경우 요청된 객체가 현재 CloudFront 엣지 캐시에 있는지 여부 + 일부 4xx 상태 코드의 경우 오리진에서 `Cache-Control max-age` 또는 `Cache-Control s-maxage` 헤더를 반환하는지 여부 CloudFront에서는 `GET` 및 `HEAD` 요청에 대한 응답을 항상 캐싱합니다. 또한 `OPTIONS` 요청에 대한 응답을 캐싱하도록 CloudFront를 구성할 수도 있습니다. CloudFront에서는 다른 메서드를 사용하는 요청에 대한 응답을 캐싱하지 않습니다. 오리진이 응답하지 않는 경우 오리진에 대한 CloudFront 요청은 시간 초과됩니다. 이 상태는 오리진이 해당 오류로 응답하지 않았더라도 오리진의 HTTP 5xx 오류로 간주됩니다. 해당 시나리오에서 CloudFront는 캐싱된 콘텐츠를 계속 제공합니다. 자세한 내용은 [오리진 사용 불가](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomOriginUnavailable) 단원을 참조하세요. 로깅을 활성화한 경우 CloudFront에서는 HTTP 상태 코드에 관계없이 결과를 로그에 작성합니다. CloudFront에서 반환되는 오류 메시지에 관련된 기능 및 옵션에 대한 자세한 내용은 다음을 참조하십시오. + CloudFront 콘솔에서 사용자 지정 오류 페이지를 설정하는 방법에 대한 자세한 내용은 [사용자 지정 오류 페이지 및 오류 캐싱](DownloadDistValuesErrorPages.md) 단원을 참조하십시오. + CloudFront 콘솔의 오류 캐싱 최소 TTL에 관한 자세한 내용은 [오류 캐싱 최소 TTL(초)](DownloadDistValuesErrorPages.md#DownloadDistValuesErrorCachingMinTTL) 단원을 참조하십시오. + CloudFront에서 캐싱하는 HTTP 상태 코드의 목록은 [CloudFront가 캐싱하는 HTTP 4xx 및 5xx 상태 코드](#HTTPStatusCodes-cached-errors) 단원을 참조하십시오. **Topics** + [사용자 지정 오류 페이지를 구성했을 때 CloudFront에서 오류를 처리하는 방법](#HTTPStatusCodes-custom-error-pages) + [사용자 지정 오류 페이지를 구성하지 않은 경우 CloudFront에서 오류를 처리하는 방법](#HTTPStatusCodes-no-custom-error-pages) + [CloudFront가 캐싱하는 HTTP 4xx 및 5xx 상태 코드](#HTTPStatusCodes-cached-errors) ## 사용자 지정 오류 페이지를 구성했을 때 CloudFront에서 오류를 처리하는 방법 사용자 지정 오류 페이지를 구성한 경우 CloudFront의 동작은 요청된 객체가 엣지 캐시에 있는지 여부에 따라 달라집니다. ### 요청된 객체가 엣지 캐시에 없는 경우 CloudFront는 다음이 모두 참이면 오리진에서 요청한 객체를 계속 가져오려 합니다. + 최종 사용자가 객체를 요청하는 경우 + 객체가 엣지 캐시에 있지 않는 경우 + 오리진이 HTTP 4xx 또는 5xx 상태 코드를 반환하며 다음 중 하나가 true인 경우 + 오리진이 304 상태 코드(수정되지 않음) 또는 객체의 업데이트된 버전을 반환하는 대신에 HTTP 5xx 상태 코드를 반환하는 경우 + 오리진이 캐시 제어 헤더에 의해 제한되지 않으며 상태 코드 목록([CloudFront가 캐싱하는 HTTP 4xx 및 5xx 상태 코드](#HTTPStatusCodes-cached-errors))에 포함된 HTTP 4xx 상태 코드를 반환하는 경우 + 오리진이 `Cache-Control max-age` 헤더 또는 `Cache-Control s-maxage` 헤더와 함께 HTTP 4xx 상태 코드를 반환하며 상태 코드가 상태 코드 목록(Control [`Cache-Control` 헤더에 따라 CloudFront에서 캐싱하는 HTTP 4xx 상태 코드](#HTTPStatusCodes-cached-errors-with-cache-control))에 포함됩니다. **CloudFront에서는 다음을 수행합니다.** 1. 최종 사용자 요청을 받은 CloudFront 엣지 캐시에서 CloudFront는 배포 구성을 확인하여 오리진 서버에서 반환한 상태 코드에 해당하는 사용자 지정 오류 페이지의 경로를 가져옵니다. 1. CloudFront에서는 사용자 지정 오류 페이지의 경로와 일치하는 경로 패턴을 가진 배포의 첫 번째 캐시 동작을 확인합니다. 1. CloudFront 엣지 로케이션에서는 캐시 동작에 지정된 오리진에 사용자 지정 오류 페이지에 대한 요청을 전송합니다. 1. 오리진에서는 엣지 로케이션에 사용자 지정 오류 페이지를 반환합니다. 1. CloudFront가 요청한 최종 사용자에게 사용자 지정 오류 페이지를 반환하며, 다음의 최대값에 대해 사용자 지정 오류 페이지도 캐싱합니다. + 오류 캐싱 최소 TTL(기본값: 10초)에 의해 지정된 시간 + 첫 번째 요청이 오류를 생성할 때 오리진에서 반환된 `Cache-Control max-age` 헤더 또는 `Cache-Control s-maxage` 헤더에 의해 지정된 시간 1. 캐싱 시간(5단계에서 결정)이 경과한 후 CloudFront는 오리진에 다른 요청을 전달하여 요청된 객체를 다시 가져오려고 시도합니다. CloudFront는 오류 캐싱 최소 TTL에 의해 지정된 간격으로 계속 다시 시도합니다. **참고** 동일한 사용자 지정 오류 페이지에 대한 캐시 동작도 구성한 경우 CloudFront는 대신 캐시 동작 TTL을 사용합니다. 이 경우 CloudFront는 5단계와 6단계에서 다음을 수행합니다. CloudFront가 요청을 수행한 뷰어에 사용자 지정 오류 페이지를 반환하면 CloudFront는 캐시 동작 TTL(예: 기본 TTL을 5초로 설정)을 확인합니다. 그런 다음 CloudFront는 사용자 지정 오류 페이지를 해당 최대값까지 캐싱합니다. 5초가 지나면 CloudFront는 오리진에서 사용자 지정 오류 페이지를 다시 가져옵니다. CloudFront는 캐시 동작 TTL에 의해 지정된 간격으로 계속 재시도합니다. 자세한 내용은 캐시 동작 [TTL 설정](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL)을 참조하세요. ### 요청된 객체가 엣지 캐시에 있는 경우 CloudFront는 다음이 모두 참이면 현재 엣지 캐시에 있는 객체를 계속 제공하려 합니다. + 최종 사용자가 객체를 요청하는 경우 + 객체가 엣지 캐시에 있지만 만료된 경우 + 오리진이 304 상태 코드(수정되지 않음) 또는 객체의 업데이트된 버전을 반환하는 대신에 HTTP 5xx 상태 코드를 반환하는 경우 **CloudFront에서는 다음을 수행합니다.** 1. 오리진이 5xx 상태 코드를 반환할 경우 CloudFront에서는 객체가 만료되었더라도 이를 제공합니다. 오류 캐싱 최소 TTL 동안 CloudFront는 엣지 캐시에서 객체를 제공함으로써 최종 사용자 요청에 지속적으로 응답합니다. 오리진이 4xx 상태 코드를 반환할 경우 CloudFront는 최종 사용자에게 요청된 객체가 아니라 상태 코드를 반환합니다. 1. 오류 캐싱 최소 TTL이 경과한 후, CloudFront에서는 다른 요청을 오리진에 전달함으로써 요청된 객체를 다시 가져오려고 시도합니다. 객체가 자주 요청되지 않는 경우, CloudFront에서는 오리진 서버가 아직 5xx 응답을 반환하는 중이라도 이를 엣지 캐시에서 제거할 수 있습니다. 객체가 CloudFront 엣지 캐시에 보관되는 시간에 대한 자세한 내용은 [콘텐츠가 캐시에 유지되는 기간(만료) 관리](Expiration.md) 단원을 참조하십시오. ## 사용자 지정 오류 페이지를 구성하지 않은 경우 CloudFront에서 오류를 처리하는 방법 사용자 지정 오류 페이지를 구성하지 않은 경우 CloudFront 동작은 요청된 객체가 엣지 캐시에 있는지 여부에 따라 달라집니다. **Topics** + [요청된 객체가 엣지 캐시에 없는 경우](#HTTPStatusCodes-no-custom-error-pages-not-in-cache) + [요청된 객체가 엣지 캐시에 있는 경우](#HTTPStatusCodes-no-custom-error-pages-in-cache) ### 요청된 객체가 엣지 캐시에 없는 경우 CloudFront는 다음이 모두 참이면 오리진에서 요청한 객체를 계속 가져오려 합니다. + 최종 사용자가 객체를 요청하는 경우 + 객체가 엣지 캐시에 있지 않는 경우 + 오리진이 HTTP 4xx 또는 5xx 상태 코드를 반환하며 다음 중 하나가 true인 경우 + 오리진이 304 상태 코드(수정되지 않음) 또는 객체의 업데이트된 버전을 반환하는 대신에 HTTP 5xx 상태 코드를 반환하는 경우 + 오리진이 캐시 제어 헤더에 의해 제한되지 않으며 상태 코드 목록([CloudFront가 캐싱하는 HTTP 4xx 및 5xx 상태 코드](#HTTPStatusCodes-cached-errors))에 포함된 HTTP 4xx 상태 코드를 반환하는 경우 + 오리진이 `Cache-Control max-age` 헤더 또는 `Cache-Control s-maxage` 헤더와 함께 HTTP 4xx 상태 코드를 반환하며 상태 코드가 상태 코드 목록(Control [`Cache-Control` 헤더에 따라 CloudFront에서 캐싱하는 HTTP 4xx 상태 코드](#HTTPStatusCodes-cached-errors-with-cache-control))에 포함됩니다. CloudFront에서는 다음을 수행합니다. 1. CloudFront는 최종 사용자에게 4xx 또는 5xx 상태 코드를 반환하며, 다음의 최대값에 대해 요청을 수신하는 엣지 캐시에 상태 코드도 캐싱합니다. + 오류 캐싱 최소 TTL(기본값: 10초)에 의해 지정된 시간 + 첫 번째 요청이 오류를 생성할 때 오리진에서 반환된 `Cache-Control max-age` 헤더 또는 `Cache-Control s-maxage` 헤더에 의해 지정된 시간 1. 캐싱 시간(1단계에서 결정됨) 동안 CloudFront는 동일 객체에 대한 후속 최종 사용자 요청에 캐싱된 4xx 또는 5xx 상태 코드로 응답합니다. 1. 캐싱 시간(1단계에서 결정)이 경과한 후 CloudFront는 오리진에 다른 요청을 전달하여 요청된 객체를 다시 가져오려고 시도합니다. CloudFront는 오류 캐싱 최소 TTL에 의해 지정된 간격으로 계속 다시 시도합니다. ### 요청된 객체가 엣지 캐시에 있는 경우 CloudFront는 다음이 모두 참이면 현재 엣지 캐시에 있는 객체를 계속 제공하려 합니다. + 최종 사용자가 객체를 요청하는 경우 + 객체가 엣지 캐시에 있지만 만료된 경우 즉, *기한 경과* 객체입니다. + 오리진이 304 상태 코드(수정되지 않음) 또는 객체의 업데이트된 버전을 반환하는 대신에 HTTP 5xx 상태 코드를 반환하는 경우 CloudFront에서는 다음을 수행합니다. 1. 오리진이 5xx 오류 코드를 반환할 경우 CloudFront에서는 객체가 만료되었더라도 이를 제공합니다. 오류 캐싱 최소 TTL(기본값: 10초) 동안 CloudFront는 엣지 캐시에서 객체를 제공함으로써 최종 사용자 요청에 지속적으로 응답합니다. 오리진이 4xx 상태 코드를 반환할 경우 CloudFront는 최종 사용자에게 요청된 객체가 아니라 상태 코드를 반환합니다. 1. 오류 캐싱 최소 TTL이 경과한 후, CloudFront에서는 다른 요청을 오리진에 전달함으로써 요청된 객체를 다시 가져오려고 시도합니다. 객체가 자주 요청되지 않는 경우, CloudFront에서는 오리진 서버가 아직 5xx 응답을 반환하는 중이라도 이를 엣지 캐시에서 제거할 수 있습니다. 자세한 내용은 [콘텐츠가 캐시에 유지되는 기간(만료) 관리](Expiration.md) 섹션을 참조하세요. **작은 정보** `stale-if-error` 또는 `Stale-While-Revalidate` 지시문을 구성하는 경우 엣지 캐시에서 기한 경과한 객체를 사용할 수 있는 기간을 지정할 수 있습니다. 이렇게 하면 오리진을 사용할 수 없는 경우에도 뷰어에게 콘텐츠를 계속 제공할 수 있습니다. 자세한 내용은 [오래된(만료된) 콘텐츠 제공](Expiration.md#stale-content) 섹션을 참조하세요. CloudFront는 지정된 [최대 TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) 값까지 기한 경과 객체만 제공합니다. 이 기간이 지나면 엣지 캐시에서 객체를 사용할 수 없습니다. ## CloudFront가 캐싱하는 HTTP 4xx 및 5xx 상태 코드 CloudFront에서는 반환된 특정 상태 코드 및 오리진이 응답으로 특정 헤더를 반환하는지 여부에 따라 오리진에서 반환된 HTTP 4xx 및 5xx 상태 코드를 캐싱합니다. CloudFront는 오리진에서 반환한 다음 HTTP 4xx 및 5xx 상태 코드를 캐싱합니다. HTTP 상태 코드에 대해 사용자 지정 오류 페이지를 구성한 경우, CloudFront에서는 사용자 지정 오류 페이지를 캐싱합니다. **참고** [CachingDisabled](using-managed-cache-policies.md#managed-cache-policy-caching-disabled) 관리형 캐시 정책을 사용하는 경우 CloudFront는 이러한 상태 코드나 사용자 지정 오류 페이지를 캐싱하지 않습니다. | | | | --- |--- | | 404 | 찾을 수 없음 | | 414 | 요청-URI가 너무 큼 | | 500 | 내부 서버 오류 | | 501 | 구현되지 않음 | | 502 | 잘못된 게이트웨이 | | 503 | 서비스 사용 불가 | | 504 | 게이트웨이 시간 초과 | ### `Cache-Control` 헤더에 따라 CloudFront에서 캐싱하는 HTTP 4xx 상태 코드 CloudFront에서는 오리진이 `Cache-Control max-age` 또는 `Cache-Control s-maxage` 헤더를 반환할 경우 오리진에서 반환된 다음 HTTP 4xx 상태 코드만 캐싱합니다. 이러한 HTTP 상태 코드 중 하나에 대해 사용자 지정 오류 페이지를 구성한 경우, 오리진이 캐시 제어 헤더 중 하나를 반환하면 CloudFront는 사용자 지정 오류 페이지를 캐싱합니다. | | | | --- |--- | | 400 | 잘못된 요청 | | 403 | 금지됨 | | 405 | 허용되지 않은 메소드 | | 412¹ | 사전 조건 실패 | | 415¹ | 지원되지 않는 미디어 유형 | ¹CloudFront는 이러한 HTTP 상태 코드에 대한 사용자 지정 오류 페이지 생성을 지원하지 않습니다. # 사용자 지정 오류 응답 생성 CloudFront를 통해 제공하는 객체를 특정 이유로 인해 사용할 수 없는 경우, 일반적으로 웹 서버에서는 해당하는 HTTP 상태 코드를 CloudFront에 반환하여 이를 나타냅니다. 예를 들어 뷰어가 잘못된 URL을 요청한 경우 웹 서버에서는 HTTP 404(찾을 수 없음) 상태 코드를 CloudFront에 반환하고 CloudFront에서는 다시 뷰어에게 이 상태 코드를 반환합니다. 이 기본 오류 응답을 사용하는 대신 CloudFront가 뷰어에게 반환하는 사용자 지정 오류 응답을 생성할 수 있습니다. HTTP 상태 코드에 대해 사용자 지정 오류 페이지를 반환하도록 CloudFront를 구성했으나 사용자 지정 오류 페이지를 사용할 수 없는 경우, CloudFront에서는 사용자 지정 오류 페이지가 포함된 오리진에서 CloudFront로 보낸 상태 코드를 최종 사용자에게 반환합니다. 예를 들어, 사용자 지정 오리진에서 500 상태 코드를 반환하고 500 상태 코드에 대한 사용자 지정 오류 페이지를 Amazon S3 버킷에서 가져오도록 CloudFront를 구성했다고 가정합니다. 하지만 누군가 실수로 사용자 지정 오류 페이지를 Amazon S3 버킷에서 삭제했고, CloudFront에서는 HTTP 404 상태 코드(찾을 수 없음)를 객체를 요청한 최종 사용자에게 반환합니다. CloudFront에서 사용자 지정 오류 페이지를 최종 사용자에게 반환하는 경우, 사용자 지정 오류 페이지에 대해 표준 CloudFront 요금을 지불하며 요청된 객체에 대해서는 요금이 부과되지 않습니다. CloudFront 요금에 대한 자세한 내용은 [Amazon CloudFront 요금](https://aws.amazon.com/cloudfront/pricing/)을 참조하세요. **Topics** + [오류 응답 동작 구성](custom-error-pages-procedure.md) + [특정 HTTP 상태 코드에 대한 사용자 지정 오류 페이지 생성](creating-custom-error-pages.md) + [다른 위치에 객체 및 사용자 지정 오류 페이지 저장](custom-error-pages-different-locations.md) + [CloudFront에서 반환하는 응답 코드 변경](custom-error-pages-response-code.md) + [CloudFront에서 오류를 캐싱하는 기간 제어](custom-error-pages-expiration.md) # 오류 응답 동작 구성 오류가 발생할 경우 CloudFront가 응답하는 방식을 관리할 수 있는 몇 가지 옵션이 제공됩니다. 사용자 지정 오류 응답을 구성하려면 CloudFront 콘솔, CloudFront API 또는 을 사용할 수 있습니다CloudFormation 구성 업데이트에 선택한 방법과 관계없이 다음 팁과 권장 사항을 고려하세요. + CloudFront에서 액세스 가능한 위치에 사용자 지정 오류 페이지를 저장합니다. Amazon S3 버킷에 저장하는 것이 좋으며 [나머지 웹 사이트 또는 애플리케이션 콘텐츠와 같은 위치에 저장하지 않는 것](custom-error-pages-different-locations.md)이 좋습니다. 웹 사이트 또는 애플리케이션과 동일한 오리진에 사용자 지정 오류 페이지를 저장할 경우 오리진이 5xx 오류를 반환하기 시작하면 오리진 서버를 사용할 수 없기 때문에 CloudFront가 사용자 지정 오류 페이지를 가져올 수 없습니다. 자세한 내용은 [다른 위치에 객체 및 사용자 지정 오류 페이지 저장](custom-error-pages-different-locations.md) 섹션을 참조하세요. + CloudFront에 사용자 지정 오류 페이지를 가져올 권한이 있는지 확인합니다. 사용자 지정 오류 페이지가 Amazon S3에 저장되어 있는 경우 페이지에 공개적으로 액세스할 수 있거나 CloudFront [오리진 액세스 제어(OAC)](private-content-restricting-access-to-s3.md)를 구성해야 합니다. 사용자 지정 오류 페이지가 사용자 지정 오리진에 저장되어 있는 경우 페이지에 공개적으로 액세스할 수 있어야 합니다. + (선택 사항) 원하는 경우 사용자 지정 오류 페이지와 함께 `Cache-Control` 또는 `Expires` 헤더를 추가하도록 오리진을 구성합니다. [**오류 캐싱 최소 TTL(Error Caching Minimum TTL)**] 설정을 사용하여 CloudFront에서 사용자 지정 오류 페이지를 캐싱할 기간을 제어할 수도 있습니다. 자세한 내용은 [CloudFront에서 오류를 캐싱하는 기간 제어](custom-error-pages-expiration.md) 섹션을 참조하세요. ## 사용자 지정 오류 응답 구성 CloudFront 콘솔에서 사용자 지정 오류 응답을 구성하려면 CloudFront 배포가 있어야 합니다. 콘솔에서 사용자 지정 오류 응답에 대한 구성 설정은 기존 배포에만 사용할 수 있습니다. 배포를 생성하는 방법에 대한 자세한 내용은 [CloudFront 표준 배포 시작](GettingStarted.SimpleDistribution.md) 섹션을 참조하세요. ------ #### [ Console ] **사용자 지정 오류 응답을 구성하려면(콘솔)** 1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/cloudfront/v4/home#distributions](https://console.aws.amazon.com/cloudfront/v4/home#distributions)에 있는 **CloudFront** 콘솔에서 배포 페이지를 엽니다. 1. 배포 목록에서 업데이트할 배포를 선택합니다. 1. [**오류 페이지(Error Pages)**] 탭을 선택한 다음 [**사용자 지정 오류 응답 생성(Create Custom Error Response)**]을 선택합니다. 1. 관련 값들을 입력합니다. 자세한 내용은 [사용자 지정 오류 페이지 및 오류 캐싱](DownloadDistValuesErrorPages.md) 섹션을 참조하세요. 1. 원하는 값을 입력한 후 [**생성(Create)**]을 선택합니다. ------ #### [ CloudFront API or CloudFormation ] CloudFront API 또는 CloudFormation을(를) 사용하여 사용자 지정 오류 응답을 구성하려면 배포에서 `CustomErrorResponse` 유형을 사용합니다. 자세한 내용은 다음 자료를 참조하십시오. + *AWS CloudFormation 사용자 설명서*의 [AWS::CloudFront::Distribution CustomErrorResponse](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-customerrorresponse.html) + *Amazon CloudFront API 참조*의 [CustomErrorResponse](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CustomErrorResponse.html) ------ # 특정 HTTP 상태 코드에 대한 사용자 지정 오류 페이지 생성 기본 메시지 대신 나머지 웹 사이트와 동일한 형식을 사용하는 페이지와 같은 사용자 지정 오류 메시지를 표시하려는 경우, CloudFront가 최종 사용자에게 사용자 지정 오류 메시지가 포함된 HTML 파일 등의 객체를 반환하게 하면 됩니다. 반환하려는 파일과 이 파일을 반환해야 하는 오류를 지정하려면 CloudFront 배포를 업데이트하여 해당 값을 지정합니다. 자세한 내용은 [오류 응답 동작 구성](custom-error-pages-procedure.md) 섹션을 참조하세요. 예를 들어 다음은 사용자 지정 오류 페이지입니다. ![\[사용자 지정 AWS 404 페이지 예시 스크린샷.\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/images/custom-error-page-aws-404-example.png) 지원되는 HTTP 상태 코드 각각에 서로 다른 객체를 지정하거나 지원되는 상태 코드 전체에 동일한 객체를 사용할 수 있습니다. 일부 상태 코드에 사용자 지정 오류 페이지를 지정하고 다른 상태 코드에는 사용자 지정 오류 페이지를 지정하지 않도록 선택할 수 있습니다. CloudFront를 통해 제공하는 객체는 다양한 이유로 사용 불가능할 수 있습니다. 이러한 이유는 넓게 보면 다음 두 가지 범주로 나뉩니다. + *클라이언트 오류*: 요청에 문제가 있음을 나타냅니다. 지정된 이름의 객체를 사용할 수 없거나, 사용자에게 Amazon S3 버킷의 객체를 가져오기 위해 필요한 권한이 없는 경우를 예로 들 수 있습니다. 클라이언트 오류가 발생하면 오리진에서는 4xx 범위의 HTTP 상태 코드를 CloudFront에 반환합니다. + *서버 오류*: 오리진 서버에 문제가 있음을 나타냅니다. HTTP 서버가 사용 중이거나 사용 불가능한 상태인 경우를 예로 들 수 있습니다. 서버 오류가 발생하면 오리진 서버에서 5xx 범위의 HTTP 상태 코드를 CloudFront에 반환합니다. 또는 특정 기간 동안 CloudFront에서 오리진 서버로부터 응답을 가져오지 않고 504 상태 코드(게이트웨이 시간 초과)를 적용합니다. CloudFront에서 사용자 지정 오류 페이지를 반환할 수 있는 HTTP 상태 코드에는 다음이 포함됩니다. + 400, 403, 404, 405, 414, 416 + 500, 501, 502, 503, 504 **참고** CloudFront에서 요청이 안전하지 않을 수 있음을 감지하면 CloudFront는 사용자 지정 오류 페이지 대신 400(잘못된 요청) 오류를 반환합니다. HTTP 상태 코드 416(요청된 범위를 충족할 수 없음)에 대한 사용자 지정 오류 페이지를 만들 수 있으며 오리진에서 CloudFront로 상태 코드 416을 반환할 경우 CloudFront에서 최종 사용자로 반환하는 HTTP 상태 코드를 변경할 수 있습니다. 자세한 내용은 [CloudFront에서 반환하는 응답 코드 변경](custom-error-pages-response-code.md) 섹션을 참조하세요. 그러나 CloudFront에서는 상태 코드 416 응답을 캐싱하지 않습니다. 따라서 상태 코드 416에 대해 [**오류 캐싱 최소 TTL(Error Caching Minimum TTL)**]의 값을 지정하더라도 CloudFront에 이 값이 사용되지 않습니다. 경우에 따라서는 HTTP 503 상태 코드에 대한 사용자 지정 오류 페이지를 반환하도록 CloudFront를 구성하더라도 이 페이지가 반환되지 않습니다. CloudFront 오류 코드가 `Capacity Exceeded` 또는 `Limit Exceeded`인 경우 CloudFront는 사용자 지정 오류 페이지를 사용하지 않고 최종 사용자에게 503 상태 코드를 반환합니다. 사용자 지정 오류 페이지를 생성한 경우 CloudFront는 다음 응답 코드에 대해 `Connection: close` 또는 `Connection: keep-alive`를 반환합니다. CloudFront는 400, 405, 414, 416, 500, 501 상태 코드에 대해 `Connection: close`를 반환합니다. CloudFront는 403, 404, 502, 503, 504 상태 코드에 대해 `Connection: keep-alive`를 반환합니다. CloudFront에서 오리진에서 보낸 오류 응답을 처리하는 방법에 대한 자세한 설명을 보려면 [CloudFront에서 오리진의 HTTP 4xx 및 5xx 상태 코드를 처리하는 방법](HTTPStatusCodes.md) 단원을 참조하세요. # 다른 위치에 객체 및 사용자 지정 오류 페이지 저장 객체와 사용자 지정 오류 페이지를 서로 다른 위치에 저장하려는 경우, 배포에는 다음을 충족하는 캐시 동작이 포함되어야 합니다. + **경로 패턴**의 값이 사용자 지정 오류 메시지와 일치합니다. `/4xx-errors`라는 이름의 디렉터리에 있는 Amazon S3 버킷에 4xx 오류에 대한 사용자 지정 오류 페이지를 저장한 경우를 예로 들어 보겠습니다. 배포에는 사용자 지정 오류 페이지에 대한 요청을 해당 위치로 라우팅하는 경로 패턴(예: `/4xx-errors/*`)의 캐시 동작이 포함되어야 합니다. + **Origin**(오리진)의 값은 사용자 지정 오류 페이지를 포함한 오리진에 대한 **Origin ID**(오리진 ID)의 값을 지정합니다. 자세한 내용은 [캐시 동작 설정](DownloadDistValuesCacheBehavior.md) 섹션을 참조하세요. # CloudFront에서 반환하는 응답 코드 변경 오리진에서 받은 것과 다른 HTTP 상태 코드를 최종 사용자에게 반환하도록 CloudFront를 구성할 수 있습니다. 예를 들어 오리진에서 CloudFront에 500 상태 코드를 반환하는 경우, CloudFront에서 사용자 지정 오류 페이지와 200 상태 코드(OK)를 최종 사용자에게 반환하려 할 수 있습니다. CloudFront에서 오리진에서 최종 사용자에게 반환한 것과 다른 상태 코드를 CloudFront로 반환하려는 이유는 다음과 같이 다양합니다. + 일부 인터넷 디바이스(예: 일부 방화벽 및 기업 프록시)에서는 HTTP 4xx 및 5xx 상태 코드를 가로채서 응답이 최종 사용자에게 반환되는 것을 막습니다. 이 시나리오에서 `200`을 대체하면 응답을 가로채지 않습니다. + 여러 가지 클라이언트 오류 또는 서버 오류 중에 구별할 필요가 없는 경우, CloudFront에서 전체 4xx 또는 5xx 상태 코드에 대해 반환하는 값으로 `400` 또는 `500`을 지정할 수 있습니다. + 고객이 웹 사이트가 다운된 것을 모르도록 `200` 상태 코드(OK)와 정적 웹 사이트를 반환하려 할 수 있습니다. [CloudFront 표준 로그](AccessLogs.md)를 활성화하고 응답에서 HTTP 상태 코드를 변경하도록 CloudFront를 구성하는 경우 로그의 `sc-status` 열 값에 지정한 상태 코드가 포함됩니다. 그러나 `x-edge-result-type` 열의 값은 영향을 받지 않습니다. 여기에는 오리진 응답의 결과 유형이 포함됩니다. 예를 들어 오리진이 `200`(찾을 수 없음)을 CloudFront로 반환할 때 최종 사용자에게 `404`의 상태 코드를 반환하도록 CloudFront를 구성한다고 가정합니다. 오리진이 요청에 `404` 상태 코드로 응답하는 경우 로그의 `sc-status` 열 값은 `200`이 되지만 `x-edge-result-type` 열의 값은 `Error`가 됩니다. 다음 HTTP 상태 코드와 사용자 지정 오류 페이지를 반환하도록 CloudFront를 구성할 수 있습니다. + 200 + 400, 403, 404, 405, 414, 416 + 500, 501, 502, 503, 504 # CloudFront에서 오류를 캐싱하는 기간 제어 CloudFront는 오류 응답을 기본 기간인 10초 동안 캐싱합니다. 그런 다음 CloudFront는 객체에 대한 다음 요청을 오리진에 제출하여 오류를 일으킨 문제가 해결되었고 요청된 객체를 사용할 수 있는지 확인합니다. CloudFront에서 캐싱하는 4xx 및 5xx 상태 코드 각각에 대해 오류 캐싱 기간**(오류 캐싱 최소 TTL(Error Caching Minimum TTL))**을 지정할 수 있습니다. (자세한 내용은 [CloudFront가 캐싱하는 HTTP 4xx 및 5xx 상태 코드](HTTPStatusCodes.md#HTTPStatusCodes-cached-errors) 섹션을 참조하세요.) 기간을 지정할 때는 다음 사항에 유의하십시오. + 짧은 오류 캐싱 기간을 지정하는 경우, CloudFront에서는 더 긴 기간을 지정하는 경우에 비해 오리진에 더 많은 요청을 전달합니다. 5xx 오류의 경우, 이는 원래 오리진에서 오류를 반환하게 만든 문제를 악화시킬 수 있습니다. + 오리진에서 객체에 대한 오류를 반환할 경우, CloudFront에서는 오류 캐싱 기간이 경과할 때까지 객체에 대한 요청에 오류 응답이나 사용자 지정 오류 페이지로 응답합니다. 오류 캐싱 기간을 길게 지정한 경우, CloudFront에서는 객체가 다시 사용 가능한 상태가 된 후에도 장시간 오류 응답이나 사용자 지정 오류 페이지로 요청에 계속해서 응답할 수 있습니다. **참고** HTTP 상태 코드 416(요청된 범위를 충족할 수 없음)에 대한 사용자 지정 오류 페이지를 만들 수 있으며 오리진에서 CloudFront로 상태 코드 416을 반환할 경우 CloudFront에서 최종 사용자로 반환하는 HTTP 상태 코드를 변경할 수 있습니다. (자세한 내용은 [CloudFront에서 반환하는 응답 코드 변경](custom-error-pages-response-code.md) 섹션을 참조하세요.) 그러나 CloudFront에서는 상태 코드 416 응답을 캐싱하지 않습니다. 따라서 상태 코드 416에 대해 [**오류 캐싱 최소 TTL(Error Caching Minimum TTL)**]의 값을 지정하더라도 CloudFront에 이 값이 사용되지 않습니다. CloudFront에서 개별 객체에 대한 오류를 캐싱하는 시간을 제어하려는 경우, 다음과 같이 관련 헤더를 해당 객체에 대한 오류 응답에 추가하도록 오리진 서버를 구성할 수 있습니다. 오리진에서 `Cache-Control: max-age` 또는 `Cache-Control: s-maxage` 명령이나 `Expires` 헤더를 추가하는 경우: CloudFront에서는 헤더의 값과 **오류 캐싱 최소 TTL(Error Caching Minimum TTL)**의 값 중 더 큰 값 동안 오류 응답을 캐싱합니다. **참고** `Cache-Control: max-age` 값과 `Cache-Control: s-maxage` 값은 오류 페이지를 가져오는 캐시 동작에 대해 설정된 **최대 TTL** 값보다 클 수 없습니다. 오리진이 오류 코드 404, 410, 414 또는 501에 대한 `Cache-Control: no-store`, `Cache-Control: no-cache` 또는 `Cache-Control: private` 지시문을 추가하는 경우 CloudFront는 오류 응답을 캐싱하지 않습니다. 다른 모든 오류 코드의 경우 CloudFront는 `no-store`, `no-cache` 및 `private` 지시문을 무시하고 **오류 캐싱 최소 TTL** 값에 대한 오류 응답을 캐싱합니다. 오리진에서 다른 `Cache-Control` 명령을 추가하거나 헤더를 추가하지 않는 경우: CloudFront에서는 **오류 캐싱 최소 TTL(Error Caching Minimum TTL)**의 값 동안 오류 응답을 캐싱합니다. 객체에 대한 4xx 또는 5xx 상태 코드의 만료 시간이 원하는 시간보다 더 긴 경우 객체를 다시 사용할 수 있게 될 때 요청된 객체의 URL을 사용하여 캐싱된 오류 코드를 무효화할 수 있습니다. 오리진에서 여러 객체에 대한 오류 응답을 반환하려는 경우, 각 객체를 개별적으로 무효화해야 할 수 있습니다. 객체 무효화에 대한 자세한 내용은 [파일을 무효화하여 콘텐츠 제거](Invalidation.md) 단원을 참조하십시오. S3 버킷 오리진에 대해 캐싱을 사용 설정하고 CloudFront 배포에서 최소 TTL을 0초로 캐싱하는 오류를 구성한 경우에도 S3 오리진 오류에 대해 최소 TTL을 1초로 캐싱하는 오류는 계속 표시됩니다. 이렇게 하여 CloudFront는 DDoS 공격으로부터 오리진을 보호합니다. 다른 유형의 오리진에는 적용되지 않습니다.