CloudFront 배포에서 사용자 지정 객체 캐싱을 설정합니다. 그런데 배포에서 오리진의 캐시 설정이 사용되는 이유가 무엇인가요?

간략한 설명

객체 캐싱을 사용자 지정하는 경우 기본 TTL, 최소 TTL 및 최대 TTL을 구성합니다. CloudFront는 오리진이 캐싱 헤더를 반환하는지 여부에 따라 다음과 같은 세 가지 파라미터를 사용합니다.

• 오리진이 캐싱 헤더를 반환하지 않으면 배포는 기본 TTL을 사용합니다.
• 오리진이 최소 TTL보다 작은 캐싱 헤더를 반환하면 배포는 최소 TTL을 사용합니다.
• 오리진이 최대 TTL보다 큰 캐싱 헤더를 반환하면 배포는 최대 TTL을 사용합니다.

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

캐시 동작에 대해 설정한 사용자 지정 값에 따라 CloudFront 배포가 캐싱하지 않는 경우 오리진을 확인합니다. 오리진에 충돌하는 캐싱 헤더가 없는지 확인합니다.

해결 방법

오리진 캐싱 헤더가 배포의 사용자 지정 객체 캐싱과 충돌하는지 여부를 확인하려면 나타난 문제에 따라 다음 지침을 수행합니다.

최소 TTL 및 기본 TTL이 0으로 설정되어 있지만, CloudFront에서 적중하는 경우

요청 URI가 최소 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"인 경우 요청은 엣지 로케이션의 캐시에서 처리된 것입니다.

Cache-Control, Expires 및 Age 헤더에 대한 나머지 응답을 검토합니다. Cache-Control 및 Expires 헤더는 동작에 관한 캐싱 헤더로, 중계(CloudFront) 캐시 또는 프라이빗(브라우저) 캐시에 요청을 저장하는 방법을 알려 줍니다. Age 헤더는 응답의 캐싱 기간을 보여 줍니다.

Cache-Control의 max-age 값이 Age의 값보다 크면 캐싱된 응답은 새로운 응답으로 간주되며, 엣지 로케이션에서 처리됩니다. Expires 날짜가 아직 미래의 시점인 경우에도 캐싱된 응답은 새로운 응답으로 간주됩니다. 캐시 동작 경로에 최소 TTL 및 기본 TTL이 0으로 설정되어 있더라도 마찬가지입니다.

최대 TTL과 기본 TTL이 0보다 크지만, CloudFront에서 누락되는 경우

요청 URI가 최대 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 헤더를 검토합니다. Cache-Control의 값이 'no-store'인 경우 헤더는 CloudFront에 응답을 캐싱하지 않도록 지시합니다. Cache-Control의 값이 'no-cache'인 경우 헤더는 CloudFront에 캐싱된 응답을 반환하기 전에 오리진에서 확인하도록 지시합니다. 이러한 지시는 CloudFront의 최대 TTL 및 기본 TTL 설정을 대체합니다.

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

CloudFront에서 오류 응답을 캐싱하는 경우

기본적으로 CloudFront는 오리진의 오류 응답을 클라이언트로 전달합니다. 또한 CloudFront는 오리진의 오류 응답을 기본적으로 10초간 캐싱합니다.

오리진의 오류 응답에 Cache-Control 헤더가 포함된 경우 CloudFront는 기본 5분이 아니라, 관련 TTL에 따라 오류를 캐싱합니다. CloudFront는 특별히 사용자 지정 오류 응답에 지정하지 않는 한, 자체 오류 응답을 캐시하지 않습니다.

오리진의 오류 응답인지, CloudFront의 오류 응답인지 확인하려면 Server 헤더를 확인합니다. 오류가 캐싱된 응답인지 확인하려면 Age 헤더를 확인합니다. 캐싱된 응답은 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 배포에서 무효화를 실행하여 변경 사항을 적용합니다.

---

관련 정보

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