CloudFront S3 이미지 무효화와 적절한 프론트 캐시 정책 조사

테스트 시나리오를 통한 기존 이미지 캐시 동작 확인

이미지 네트워크 요청 시 응답 헤더 확인 -->

캐시 관련 헤더를 확인해 본 결과

etag:"example"

last-modified: Thu, 27 Feb 2025 06:26:56 GMT

x-cache: Hit from cloudfront

via: 1.1 example.cloudfront.net (CloudFront)

x-amz-cf-id: example

x-amz-cf-pop: ICN57-P5

서울 리전 (ICN)엣지 로케이션 사용

 

CloudFront의 캐시 정책을 따르고 있으며, Cache-Control 헤더 부재를 통해 브라우저의 캐시 정책은 명확하지 않고 브라우저 기본값에 의존하고 있는걸로 확인되었다.

기본적으로 CloudFront의 캐시 설정 우선순위가 더 높으며, CloudFront 요청 시 브라우저의 캐시 정책이 아닌 CloudFront의 캐시 정책을 따른다.

 

 

 

버전에 따른 무효화가 아닌 같은 경로, 이미지 이름에서 이미지만 변경되어야 하여, 캐시를 비워야 할 때 TTL 만료를 기다릴 수 없는 상황에서 어떤식으로 동작하는지 테스트를 위해 현재 캐시 정책을 확인했다.

우선 캐시 정책 이름은 Managed-CachingOptimized이며,

• 최소 TTL: 1일
• 최대 TTL: 1년
• 기본 TTL: 1일
  인 것으로 확인되었다. TTL은 수정이 가능한 것으로 보인다.
  
  

LOBBY에서 사용되는 배너 이미지를 같은 이름, 다른 이미지로 덮어씌우고 테스트해본 결과 이미지가 변경되지 않았으며, X-Cache에는 Hit from CloudFront 값이 있었다. 이미지는 달라졌지만 캐싱이 되고있는 상태였다.

next.config.js

 

config파일에 캐싱 관련 설정이 되어있었지만 기본적으로 CloudFront의 우선순위가 더 높아 CloudFront의 캐싱 정책을 따라 위 설정은 무시되었다.

이후 Etag 또는 마지막 수정시간을 기반으로 무효화를 진행하지 않아도 이미지를 변경하면 새 이미지를 s3에서 가져와 응답으로 내려주는게 맞는데 왜 캐싱이 되고있는지 확인하기 위해 CloudFront의 캐싱 정책을 조사해봤다.

 

CloudFront의 캐싱 동작:

1. CloudFront는 TTL(Time To Live)를 기반으로 캐시를 관리한다.
2. 같은 경로의 파일이 S3에서 변경되어도, TTL이 만료되기 전까지는 기존 캐시를 사용한다.

 

따라서 이미지가 변경되었어도 무효화를 진행하기 전까지는 기존 캐시를 사용하고 있었다.

 

이후

cloudFront에서 직접 무효화를 진행해준 뒤 확인해 본 결과 Miss from CloudFront 응답헤더와 함께 변경된 이미지가 내려오는 것을 확인했다.

결론적으로, 같은 경로/이름의 파일을 S3에서 변경했을 때, CloudFront에서 즉시 반영하려면 무조건 무효화 처리가 필요한 것으로 확인됐다.