SW BBANG K

S3 버킷에 파일을 덮어썼는데 CloudFront는 여전히 구버전을 서빙하고 있다. 배포 직후 사용자 신고가 들어오고, 콘솔을 열어보면 S3에는 분명 새 파일이 올라가 있다. 이 상황에서 필요한 것이 CloudFront 캐시 무효화(Invalidation) 다 — 엣지 로케이션에 남아있는 캐시 객체를 강제로 만료시켜 다음 요청 시 오리진에서 최신 버전을 가져오게 만드는 메커니즘이다. TL;DR — CloudFront 캐시 무효화 핵심 요약 상황 권장 방법 비용 특정 파일 1~수십 개 교체 경로 지정 Invalidation 월 1,000 경로 무료, 초과 시 유료 전체 캐시 일괄 초기화 /* 와일드카드 Invalidation 1개 경로로 카운트되나 모든 객체 무효화 배포 파이프라인 자동화 CLI / SDK Invalidation 호출 동일 과금 구조 근본적 캐시 충돌 방지 파일명 버전닝(캐시 버스팅) 무료 — Invalidation 불필요 정가 및 무료 한도는 변경될 수 있으므로 AWS CloudFront 공식 요금 페이지 에서 확인하라. CloudFront 캐시가 동작하는 방식 — 왜 S3를 바꿔도 즉시 반영되지 않는가 CloudFront는 전 세계 엣지 로케이션에 콘텐츠 사본을 저장한다. 사용자 요청이 들어오면 엣지가 먼저 로컬 캐시를 확인하고, 캐시 히트면 오리진(S3)에 전혀 접근하지 않고 응답한다. 캐시 항목은 TTL(Time To Live)이 만료되거나 명시적으로 무효화될 때까지 유지된다. S3에 파일을 덮어써도 엣지 캐시의 TTL이 남아있는 한 CloudFront는 오리진을 다시 조회하지 않는다. TTL은 오리진의 Cache-Control 헤더 또는 CloudFront 배포 설정의 'Default TTL'로 결정된다. 기본값이 24시간이면 최대 하루 동안 구버전이 서빙될 ...

EC2 인스턴스에 볼륨을 붙이려는데 콘솔에 gp2와 gp3가 나란히 보인다. 둘 다 '범용 SSD'라는 설명은 같은데, 실제 운영 환경에서 어떤 차이가 있는지 모르면 나중에 IOPS 부족으로 병목이 생기거나 불필요한 비용이 발생한다. EBS gp3는 스토리지 용량과 무관하게 IOPS를 독립적으로 조정할 수 있는 볼륨 타입으로, 대부분의 워크로드에서 gp2보다 비용 효율적이다. TL;DR — gp2 vs gp3 핵심 비교 항목 gp2 gp3 IOPS 결정 방식 용량에 연동 (3 IOPS/GB) 용량과 독립적으로 설정 기본 IOPS 용량 기반 자동 산정 3,000 IOPS (기본 포함) 최대 IOPS 16,000 16,000 최대 처리량 250 MiB/s 1,000 MiB/s 버스트 메커니즘 크레딧 버킷 방식 없음 (기본 성능이 일정) 비용 구조 GB당 단일 요금 GB + IOPS + 처리량 분리 과금 신규 워크로드 권장 — ✓ 가격과 한도는 변동될 수 있으므로 항상 AWS 공식 EBS 요금 페이지 에서 최신 정보를 확인하라. gp2와 gp3의 작동 방식 이해 gp2는 IOPS가 볼륨 크기에 묶여 있다. 1 GiB당 3 IOPS가 자동으로 할당되며, 최소 100 IOPS에서 최대 16,000 IOPS까지 선형으로 증가한다. 즉, 16,000 IOPS가 필요하면 최소 5,334 GiB 볼륨을 프로비저닝해야 한다. 실제로 그만큼의 스토리지가 필요 없더라도 IOPS를 위해 용량을 낭비하는 구조다. 버스트 메커니즘도 있다. 1 TiB 미만 볼륨은 크레딧 버킷을 소진하면서 최대 3,000 IOPS까지 일시적으로 올라가지만, 크레딧이 바닥나면 기본 IOPS로 떨어진다. 예측 불가능한 성능 저하의 원인이 된다. gp3는 이 연동 구조를 끊었다. 용량과 무관하게 기본 3,00...