Amazon CloudFront

전 세계 사용자가 한 리전의 원본 서버나 버킷에 직접 붙으면 멀리 있는 사용자는 항상 지연을 겪고, 인기 파일 하나가 원본 부하를 키웁니다. 캐시와 보안 처리를 원본 앞에서 하지 않으면 잘 팔릴수록 느려지는 상황이 생깁니다.

초기 웹 서비스는 원본 서버 한 대가 모든 요청을 직접 처리했습니다. 사용자가 적을 때는 괜찮았지만, 글로벌 사용자가 늘면서 문제가 드러났습니다. 서울 리전 S3 버킷에 있는 이미지를 브라질 사용자가 요청하면 물리적 거리만큼 지연이 생기고, 같은 파일을 수천 명이 동시에 요청하면 원본 서버에 부하가 집중됩니다. 트래픽이 급증하는 이벤트나 출시 시점에는 대역폭 비용이 예상을 크게 넘기기도 했습니다. 원본 앞에 Nginx 캐시 서버를 직접 두는 팀도 있었지만, 여러 리전에 캐시를 분산 배치하고 만료 정책을 관리하고 SSL 인증서를 갱신하는 운영 부담이 컸습니다. 이런 압력 때문에, 전 세계 엣지에서 캐시와 전송 최적화를 관리형으로 제공하는 CDN 계층이 필요해졌고 CloudFront가 그 역할을 맡습니다.

CloudFront는 원본(S3, ELB, EC2 등) 앞에 서서 엣지 로케이션에 콘텐츠를 캐시합니다. 요청이 들어오면 가장 가까운 엣지가 받고, 캐시에 유효한 응답이 있으면 원본에 가지 않고 바로 돌려줍니다(캐시 히트). 없으면 원본에서 가져와 응답하면서 엣지에 저장합니다(캐시 미스). 캐시 히트 여부를 결정하는 두 가지 핵심이 있습니다. 첫째는 TTL(Time To Live)로, 엣지에 저장된 응답의 유효 기간입니다. TTL이 지나면 다음 요청 시 원본에 다시 확인합니다. 둘째는 캐시 키(Cache Key)로, URL 경로뿐 아니라 쿼리 스트링, 헤더, 쿠키 중 어떤 조합을 같은 응답으로 볼지 정합니다. 캐시 키에 불필요한 값이 포함되면 같은 콘텐츠인데도 캐시 미스가 나서 효율이 떨어집니다. Shield와 WAF를 붙여 원본 보호를 강화하거나, Lambda@Edge로 엣지에서 응답 헤더를 수정하거나 리디렉션 로직을 실행할 수도 있습니다.

CloudFront와 Route 53은 둘 다 사용자 진입점에서 보이지만 역할이 다릅니다. Route 53은 어디로 보낼지 DNS로 결정하고, CloudFront는 실제 응답을 더 빠르고 안전하게 전달합니다. 도메인을 어떤 서비스로 연결할지 정하는 문제가 핵심이면 Route 53을 보고, 정적 자산과 응답을 엣지에서 가속하는 문제가 핵심이면 CloudFront를 보면 됩니다.

S3에 정적 사이트를 올리고 CloudFront를 앞에 두면, 전 세계 사용자가 가장 가까운 엣지에서 파일을 받습니다. 원본 S3로 가는 요청이 줄어 대역폭 비용도 낮아집니다. 이미지, JS, CSS처럼 자주 바뀌지 않는 자산에 특히 효과가 큽니다. API 응답에도 쓸 수 있습니다. 사용자별로 달라지지 않는 응답이라면 TTL을 짧게 잡아 엣지에서 캐시하고, 동적 요청은 캐시를 건너뛰고 원본으로 바로 보내되 AWS 백본 네트워크를 통해 지연을 줄입니다. 다만 배포 후 캐시 무효화가 필요한 상황은 주의해야 합니다. 파일을 업데이트해도 TTL이 남아 있으면 엣지에서 이전 버전을 계속 내려보내고, 수동 무효화는 전파에 수 분이 걸립니다. 파일명에 해시를 붙이는 방식으로 우회하는 게 일반적입니다.