CloudFront: 손해 보는 곳

Source: Dev.to

CloudFront는 일반적으로 성능, 신뢰성, 원본 부하 감소와 같은 좋은 의도로 아키텍처에 추가됩니다. 그런데 몇 달 후에 AWS 청구서 상단에 나타나는데, 왜 그런지 아무도 모릅니다.

불편한 진실은 CloudFront가 하나의 큰 실수 때문에 비싸게 되는 경우는 드뭅니다. 오히려 규모에 따라 작은 비효율성을 증폭시켜 비용이 증가합니다.

다음은 CloudFront가 조용히 비용을 소모하는 지점들이며, 먼저 확인해야 할 사항입니다.

1. 캐싱은 체크박스가 아니다

대부분의 CloudFront 비용 문제는 존재하지만 설계되지 않은 캐싱에서 시작됩니다.

• 서로 다른 유형의 콘텐츠는 매우 다르게 동작하지만, 종종 같은 캐시 정책으로 제공됩니다.
  불변(static) 정적 자산, 자주 변경되는 HTML, 그리고 API 응답은 각각 다른 처리가 필요합니다.
• 고유한 이름을 가진 파일(특히 해시된 자산)은 적극적으로 캐시해야 합니다. 빌드마다 파일 이름이 바뀐다면, 해당 파일 자체는 사실상 불변입니다. 몇 분마다 재검증하는 것은 순수한 낭비입니다.
• index.html 같은 콘텐츠는 변경되지만, 캐싱을 완전히 비활성화하는 것은 드물게 올바른 해결책입니다. 짧은 TTL이면 신선도와 비용 사이의 균형을 맞추기에 충분합니다.
• CloudFront 캐싱이 적절해지면 브라우저 캐싱이 다음 승리가 됩니다. S3 객체에 올바른 Cache‑Control 헤더를 설정하면 반복 요청을 줄이고 인프라를 건드리지 않고도 비용을 조용히 절감할 수 있습니다.

2. CloudFront가 유일한 진입점이 아니라면 비용을 과다하게 지불하고 있습니다

When content is downloaded directly from S3 instead of passing through CloudFront, you lose both money and security.

• This usually happens when an application accidentally exposes raw S3 URLs or when old links still point to the bucket. From a user perspective everything still works, but behind the scenes S3 is serving traffic that CloudFront should be handling.
• Financial impact:
  • No caching and compression → higher S3 data‑transfer costs.
  • Security risk: a publicly accessible bucket is a misconfiguration.
• In production, S3 should only serve content through CloudFront, enforced by Origin Access Control (OAC). When OAC is configured, CloudFront becomes the only trusted entry point; everything else gets blocked.

3. 압축이 켜져 있지 않으면 — 아니면 공기값을 내고 있는 겁니다

• 일부 클라이언트와 서드파티 도구는 압축을 명시적으로 비활성화하는 헤더를 보냅니다. 원본 서버가 해당 헤더를 존중하면 응답이 압축되지 않은 상태로 전달되어 페이로드 크기와 데이터 전송 비용이 증가합니다.
• CloudFront는 압축을 안전하게 처리할 수 있지만, 자동 압축이 활성화된 경우에만 가능합니다. 이 하나의 설정이 합리적인 청구서와 혼란스러운 청구서 사이를 가르는 차이가 될 수 있습니다.

4. 좀비 배포는 여전히 실제 비용을 발생시킵니다

CloudFront 배포는 다음과 같이 쌓이는 경향이 있습니다:

• 개념 증명(Proof‑of‑concept), 임시 도메인, 레거시 프로젝트 — 거의 삭제되지 않습니다.
• 아무도 의도적으로 사용하지 않더라도 봇이 종종 사용합니다.

배포와 트래픽 메트릭을 빠르게 검토하면 몇 달 전이라도 비활성화했어야 할 “유령” 리소스를 자주 발견할 수 있습니다. 먼저 비활성화하고, 나중에 삭제합니다. 트래픽을 받는 미사용 인프라는 순수한 낭비입니다.

5. Global CDN for a Local Product = Wasted Budget

기본적으로 CloudFront는 전 세계 엣지 로케이션에서 콘텐츠를 제공합니다.

• 사용자가 주로 한 지역에 있다면, 적절한 price class 로 배포 범위를 제한하면 실제 사용자에게 영향을 주지 않으면서 데이터 전송 비용을 절감할 수 있습니다.
• 많은 팀이 초기 설정 후 이 설정을 다시 검토하지 않습니다.

글로벌 도달 범위는 강력하지만, 불필요한 도달은 비용이 많이 듭니다.

6. Security Rules Also Show Up on the Bill

AWS WAF는 CloudFront를 보호하지만 every request마다 규칙을 평가합니다.

• 시간이 지나면서 규칙 세트가 늘어납니다.
  • 관리형 규칙은 “혹시 몰라서” 활성화됩니다.
  • 로깅은 모든 항목에 대해 켜져 있습니다.
  • 초기에 차단되어야 할 요청도 시스템을 통과합니다.

정기적인 WAF 검토를 통해 불필요한 처리를 줄이고 동시에 CloudFront 비용을 낮출 수 있습니다. 여기서는 보안과 비용 최적화가 서로 대립되지 않습니다.

7. 추가되는 킬로바이트는 트래픽에 비례한다

완벽한 캐싱이 있더라도 CloudFront는 전송된 데이터에 비용을 청구합니다.

• 특히 초기 페이지 로드 시 클라이언트가 실제로 받는 내용을 검토하세요.
• 많은 애플리케이션이 프론트엔드에서 더 이상 사용하지 않는 설정 데이터, 메타데이터, API 필드를 반환합니다.

추가되는 킬로바이트는 트래픽 양에 비례해 곱해집니다. 압축이 도움이 되지만 불필요한 데이터를 무료로 만들지는 못합니다. 페이로드 크기를 줄이면 성능이 향상되고 CloudFront 비용이 낮아지며 오리진 부하도 감소합니다 — 인프라를 건드리지 않고도 가능합니다.

8. 모니터링하지 않으면 최적화할 수 없습니다

CloudFront는 하룻밤 사이에 비용이 급증하지 않습니다. 비용은 보통 조용히 상승합니다.

• 비용 이상 알림과 정기적인 사용 대시보드를 설정합니다.
• Cache Hit Ratio, Data Transfer, Requests, WAF evaluations와 같은 지표를 추적합니다.
• AWS Cost Explorer 또는 타사 도구를 사용해 급증을 조기에 감지합니다.

위 항목들을 지속적으로 모니터링하고 반복 개선함으로써, CloudFront를 숨은 비용 누수가 아닌 비용 효율적인 아키텍처 구성 요소로 유지할 수 있습니다.

Monitoring and Cost Control

이상 탐지, 월간 비용 보고서, 배포 수준 모니터링을 통해 CloudFront를 예상치 못한 비용이 아닌 관리 가능한 시스템으로 전환할 수 있습니다. 가시성이 없으면 좋은 아키텍처조차 점차 약화됩니다.

최종 생각

CloudFront는 당신의 돈을 낭비하지 않습니다. 비효율에 대해 정확하게 청구합니다.

놓친 캐시 기회 하나, 추가 헤더 하나, 잊힌 배포 하나마다 트래픽에 의해 곱해집니다. CloudFront를 일회성 설정이 아니라 살아있는 시스템으로 다루면 비용이 저렴하고 예측 가능하게 유지됩니다.