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

프로젝트 진행 중 S3 버킷에서 관리되는 서버 이미지는 CloudFront를 통해 요청, 응답받았다.

만약 하나의 이미지 파일에만 문제가 생겼을 경우 전체 이미지 버전을 업데이트하고 무효화시키기에는 부담이 조금 있어, 테스트 해본 결과 무효화를  진행하지 않을경우 Etag, 마지막 수정시간이 변경되어도 계속해서 캐싱을 하고있는것을 확인했다. 이 부분을 해결하기 위해 CloudFront의 캐시 정책을 조사하고 다른 방안이 있을지 살펴보았다.  

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

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

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

etag: W/"26xxxxxxx"

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

x-cache: Hit from cloudfront

via: 1.1 44xxxxxxxxxa.cloudfront.net (CloudFront)

x-amz-cf-id: tJNxxxxxxxxx

x-amz-cf-pop: xxxxxxxx

서울 리전 (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 캐시 설정

 

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

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

CloudFront의 캐싱 동작:

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

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

 

이후

cloudfront 캐시 무효화

 

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

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