CloudFront 비용을 줄여보려고 트래픽 높은 엔드포인트를 분석했다. 이미지와 동영상 파일이 많았는데, 동영상 일부가 캐시되지 않고 있었다.
CloudFront 캐시 적중률(Cache Hit Ratio)을 확인했더니, S3에서 직접 서빙하는 동영상 파일들이 캐시되지 않았다.
구조:
Amplify (SSR) → CloudFront → 사용자
S3 (정적 파일) → CloudFront → 사용자
Amplify로 배포한 프론트엔드는 정상적으로 캐시됐는데, S3에 올린 동영상/이미지만 문제였다.
Site-to-Site VPN은 단순한 터널이 아니다. IKE/IPsec 협상, Initiator/Responder 역할, 터널 이중화까지 고려할 게 많다. 특히 AWS는 항상 Responder로 동작한다는 점을 모르면 연결 자체가 안 된다.
AWS Site-to-Site VPN을 개발망에 구성하면서 알게 된 핵심 개념과 구성 시 체크해야 할 항목들을 정리했다.
AWS Site-to-Site VPN은 1개의 VPN Connection = 2개의 터널을 기본 제공한다.
클라우드 비용 관리는 결국 Observability 문제다. 시스템 장애를 모니터링하듯, 비용 이상도 실시간으로 감지하고 원인을 추적할 수 있어야 한다.
기존에는 월 단위 수동 리뷰에 의존하고 있었다. MTTR(Mean Time To Resolve)이 아니라 MTTD(Mean Time To Detect)부터 문제였다. 이상 비용이 발생해도 한 달 뒤에야 알 수 있었다. Lambda로 일 단위 리포트를 자동화하고, Claude Agent로 이상 탐지와 원인 분석까지 자동화한 과정을 공유한다.
기존 프로세스는 이랬다:
CDN 비용은 대부분 전송량(Data Transfer Out)이 결정한다. 요청 수가 아니라 한 번에 얼마나 큰 데이터를 보내느냐가 핵심이다.
주간 비용 리포트에서 CloudFront가 전주 대비 28% 올라 있었다. 신규 배포 이후였고, 요청 수는 11% 늘었는데 전송량은 50% 늘었다. 요청당 전송 크기가 비정상적으로 커진 것이다. 원인을 추적해보니 프론트엔드 이미지 처리 방식에 문제가 있었다.
매주 자동으로 생성되는 AWS 비용 리포트를 확인하다가 이상 수치를 발견했다.
외부 레지스트리에 의존하는 것은 리스크다. 내가 통제할 수 없는 곳에서 이미지가 사라지면, 우리 배포가 멈춘다.
Docker Hub의 이미지가 삭제되어 배포가 실패한 적이 있다. 그때서야 ECR Pull Through Cache 설정이 잘못되어 있다는 걸 알았다. 제대로 설정하고 나니 외부 레지스트리 의존성을 완전히 끊을 수 있었다.
배포 파이프라인이 갑자기 실패했다. 에러 메시지를 보니 베이스 이미지를 못 찾는다고 했다.
클라우드 비용 최적화의 핵심은 워크로드 특성을 이해하는 것이다. CPU 바운드와 I/O 바운드는 최적화 전략이 완전히 다르다.
Glue 비용이 매월 100% 이상 증가하고 있었다. 단순히 리소스를 줄이면 성능이 떨어질 것 같았지만, 워크로드 분석 결과 I/O 바운드 특성을 발견했다. DPU를 1/5로 줄이고도 성능 저하 없이 비용을 80% 절감한 과정을 공유한다.
비용 리포트를 보다가 Glue 비용이 급격히 증가하는 것을 발견했다. 원인을 추적해보니 ETL 실행 주기가 1일에서 1시간 단위로 변경된 것이 메인 원인이었다.
EC2 인스턴스의 CPU 크레딧은 많이 알려져 있다. T 인스턴스가 baseline 이상으로 버스트할 때 크레딧을 소모하고, 크레딧이 바닥나면 쓰로틀링된다. 그런데 네트워크에도 크레딧 시스템이 있다는 건 덜 알려져 있다.
더 중요한 건, CPU 크레딧은 Unlimited 모드로 쓰로틀링을 피할 수 있지만, 네트워크 크레딧에는 Unlimited가 없다.
| 항목 | CPU 크레딧 | 네트워크 크레딧 |
|---|---|---|
| 적용 대상 | T 인스턴스만 (T2, T3, T4g) | “up to X Gbps” 표기된 대부분의 인스턴스 |
| Unlimited 모드 | 있음 (추가 비용으로 쓰로틀링 방지) | 없음 |
| 크레딧 바닥나면 | baseline으로 제한 | baseline으로 제한 |
| 해결책 | Unlimited 켜기 | 인스턴스 업그레이드 |
EC2 콘솔에서 인스턴스 타입을 보면 네트워크 성능이 이렇게 표시된다:
보안은 공짜가 아니다. 하지만 환경별로 필요한 보안 수준은 다르다. Dev 환경에 Prod 수준의 보안 모니터링을 적용하면 비용만 낭비된다.
AWS Inspector 비용 리포트를 보다가 이상한 점을 발견했다. Dev 환경이 Prod보다 거의 20배 비용이 나오고 있었다. 원인을 추적하다 보니 ECR Enhanced Scanning의 동작 방식을 제대로 이해하게 되었다.
월간 비용 리포트에서 Inspector 비용이 눈에 띄었다.
자동 복구가 조용히 성공하면, 근본 원인은 조용히 남는다.
ECS에는 Circuit Breaker라는 배포 안전장치가 있다. 배포가 실패하면 자동으로 이전 버전으로 롤백한다. 문제는 이 롤백이 조용하다는 것이다. 배포한 사람도, 운영하는 사람도 실패 사실을 모른 채 넘어갈 수 있다. Lambda 없이, AWS 네이티브 서비스만으로 배포 실패 알림을 Slack에 보내는 과정을 공유한다.
처음에는 Datadog 모니터로 해결하려 했다. 하지만 ECS 배포 실패를 감지하기에는 부적합했다.
비용 모니터링은 단순한 비용 관리 도구가 아니다. 때로는 성능 모니터링이나 에러 알림보다 먼저 문제를 잡아준다. 시스템은 정상인데 비용만 비정상인 상황, 그게 바로 서드파티 솔루션에서 발생한 문제였다.
주간 AWS 비용 리포트에서 S3 DataTransfer-Out이 $0에서 하루 $44로 뛰었다. 서비스에는 아무 이상이 없었고, 에러 로그도 없었다. 원인은 도입한 로그 수집 솔루션의 버그였다. 하루 7GB의 데이터를 349GB나 반복 전송하고 있었다.
자동화된 주간 비용 리포트에서 S3 DataTransfer-Out 항목이 눈에 띄었다. 기존에는 거의 $0이던 항목이 갑자기 하루 $40 이상 찍히고 있었다.