사용자 지정 객체 캐싱을 설정할 때 CloudFront 배포에서 오리진의 캐시 설정을 사용하는 이유는 무엇입니까?

간략한 설명

객체 캐싱을 사용자 지정할 때 기본 TTL(기본 Time to Live), 최소 TTL 및 최대 TTL을 구성합니다.

CloudFront는 다음과 같은 동작을 사용합니다.

• 오리진에서 캐싱 헤더를 반환하지 않는 경우 CloudFront 배포는 기본 TTL을 사용합니다.
• 오리진에서 최소 TTL보다 낮은 캐싱 헤더를 반환하는 경우 배포는 최소 TTL을 사용합니다.
• 오리진에서 최대 TTL보다 큰 캐싱 헤더를 반환하는 경우 배포는 최대 TTL을 사용합니다.

참고: CloudFront가 최소 TTL 또는 최대 TTL을 기준으로 응답을 캐싱하는 경우에도 클라이언트에 대한 응답에는 오리진의 캐싱 헤더가 포함됩니다. 브라우저 또는 프록시와 같은 모든 프라이빗 캐시는 오리진의 캐싱 헤더를 사용할 수 있습니다.

배포가 기본 TTL 값을 기준으로 캐싱하지 않는 경우 오리진의 캐싱 헤더가 충돌하지 않는지 확인하십시오.

해결 방법

충돌하는 캐싱 헤더 식별

오리진의 캐싱 헤더가 배포의 사용자 지정 객체 캐싱과 충돌하는지 확인하십시오.

최소 TTL 및 기본 TTL은 0으로 설정되어 있지만 CloudFront에서 캐싱된 결과가 여전히 남아 있음

CloudFront의 응답을 확인하여 X-Cache의 값이 Hit from cloudfront인지 또는 RefreshHit from cloudfront인지 확인하십시오.

< HTTP/1.1 200 OK
< Content-Type: text/html
< Content-Length: 437
< Connection: keep-alive
< Date: Sat, 03 Feb 2018 19:26:45 GMT
< Last-Modified: Sat, 03 Feb 2018 19:25:24 GMT
< ETag: "example12345abcdefghijklmno54321"
< Cache-Control: max-age=300, Public
< Accept-Ranges: bytes
< Server: AmazonS3
< Age: 14
< X-Cache: Hit from cloudfront

X-Cache가 Hit from cloudfront 또는 RefreshHit from cloudfront인 경우 요청은 엣지 로케이션의 캐시에서 발생한 것입니다. 새로 고침 적중 시 CloudFront는 오리진에서 만료된 객체가 수정되지 않았는지 다시 검증한 후 객체의 기한이 경과하면 새로 고칩니다.

응답에서 Cache-Control, Expires 및 Age 값을 확인합니다. Cache-Control의 max-age 값이 Age 값보다 큰 경우 캐시된 응답은 CloudFront 캐시에서 발생한 것입니다. Expires 날짜가 아직 미래인 경우 캐시된 응답도 기한이 경과한 것이 아닙니다. 이는 캐시 동작 경로의 최소 TTL과 기본 TTL이 0으로 설정된 경우에도 예상되는 동작입니다.

참고: 위 예제에서 최대 TTL은 0보다 큽니다. 모든 TTL 값을 0으로 설정하면 캐싱이 해제됩니다.

최대 TTL과 기본 TTL이 0보다 크지만 CloudFront에서 누락된 항목이 있음

CloudFront의 응답을 확인하여 X-Cache 값이 Miss from cloudfront인지 확인하십시오.

< HTTP/1.1 200 OK
< Content-Type: text/html
< Content-Length: 437
< Connection: keep-alive
< Date: Sat, 03 Feb 2018 19:26:45 GMT
< Last-Modified: Sat, 03 Feb 2018 19:25:24 GMT
< ETag: "example12345abcdefghijklmno54321"
< Cache-Control: no-cache, no-store
< Accept-Ranges: bytes
< Server: AmazonS3
< X-Cache: Miss from cloudfront

X-Cache가 Miss from cloudfront인 경우 요청은 캐시가 아닌 오리진에서 발생한 것입니다.

Cache-Control 값이 no-store이면 헤더는 CloudFront에 응답을 캐싱하지 않도록 지시합니다. Cache-Control이 no-cache인 경우 헤더는 CloudFront에 캐시된 응답을 반환하기 전에 오리진에서 확인하도록 지시합니다. Cache-Control이 private인 경우 CloudFront는 브라우저의 로컬 캐시와 같은 프라이빗 캐시에만 응답을 저장해야 합니다.

이러한 동작은 최대 TTL 및 기본 TTL 설정을 재정의합니다.

참고: 캐시에서 오지 않은 응답에는 Age 헤더가 없습니다.

위 예제에서 최소 TTL은 0으로 설정되었습니다. 최소 TTL이 0보다 크면 응답에 no-cache, no-store 또는 private 지시문이 있더라도 CloudFront는 객체를 캐싱합니다. 자세한 내용은 CloudFront에서 객체를 캐싱하는 시간 지정을 참조하십시오.

CloudFront는 오류 응답을 캐싱함

CloudFront는 오리진에서 클라이언트로 오류 응답을 전달하고 오리진의 오류 응답을 기본적으로 10초 동안 캐싱합니다.

오리진의 오류 응답에 Cache-Control 헤더가 포함된 경우 CloudFront는 기본값인 10초가 아닌 관련 TTL을 사용하여 오류를 캐싱합니다.

오류 응답이 오리진에서 온 것인지 CloudFront에서 온 것인지 확인하려면 Server 값을 확인하십시오. 오류가 캐시된 응답인지 확인하려면 응답에 Age 헤더가 포함되어 있는지 확인하십시오.

다음 예는 캐시된 응답인 Amazon Simple Storage Service(Amazon S3) 오리진에서 발생한 오류입니다.

< HTTP/1.1 403 Forbidden
< Content-Type: application/xml
< Transfer-Encoding: chunked
< Connection: keep-alive
< Date: Sat, 03 Feb 2018 21:07:51 GMT
< Server: AmazonS3
< Age: 12
< X-Cache: Error from cloudfront

다음 예는 캐시된 응답이 아닌 CloudFront의 오류입니다.

< HTTP/1.1 403 Forbidden
< Server: CloudFront
< Date: Sat, 03 Feb 2018 21:14:53 GMT
< Content-Type: text/xml
< Content-Length: 146
< Connection: keep-alive
< X-Cache: Error from cloudfront

오리진 업데이트

배포의 사용자 지정 객체 캐싱을 재정의하는 캐싱 헤더를 식별한 후 오리진을 업데이트하십시오.

다음 단계를 완료하십시오.

1. 웹 서버 구성에서 헤더의 위치를 식별합니다.
2. 헤더가 적용된 줄을 제거합니다.
3. 서버를 다시 시작합니다.
4. 오리진을 테스트하여 캐싱 헤더가 더 이상 응답에 반환되지 않는지 확인합니다.
5. 전체 CloudFront 배포에서 무효화를 실행하여 변경 사항을 적용합니다.

관련 정보

요청 헤더에 따라 콘텐츠 캐싱

콘텐츠가 캐시에 유지되는 기간(만료) 관리