AWS 요금 폭탄 방어 실전 후기: 서버가 내려갈 뻔한 경험에서 배운 필수 설정

개발자라면 누구나 한 번쯤 AWS 요금 폭탄에 대한 악몽을 꿉니다. 저도 그 악몽을 현실로 겪은 1인입니다. 새벽 3시, 출시를 앞둔 서비스를 점검하러 AWS 콘솔에 들어갔다가, 예상치 못한 숫자를 보고 심장이 멈추는 듯했습니다. 이 글은 AWS 요금 폭탄을 방어하다가 서버가 실제로 내려갈 뻔한 제 경험을 담은 생생한 후기입니다. 여러분은 제가 겪은 시행착오를 반복하지 않도록, 꼭 알아야 할 핵심 방어 전략과 함정들을 정리해 드리겠습니다. 이 글에 나오는 구체적인 요금과 설정값은 제가 사건을 겪던 시점의 AWS 요금 체계를 기준으로 한 것이며, 현재는 달라졌을 수 있습니다.

1. 왜 하필 새벽에 AWS 요금 폭탄이 터졌는가

평소와 다름없이 EC2 인스턴스 하나와 RDS를 사용하고 있었습니다. 월 고정비가 20만 원 정도였으니, 특별히 의심할 이유가 없었죠. 그런데 어느 날 갑자기 ‘현재까지 발생 비용 $1,234.56’이라는 문자가 도착했습니다. 처음엔 해킹을 의심했습니다. 하지만 AWS 콘솔을 열어보니, 제가 직접 설정해 둔 서비스들에서 비용이 발생하고 있었습니다.

문제는 시스템이 예상치 못한 트래픽을 처리하다가 오토스케일링을 통해 EC2 인스턴스를 30개 이상으로 늘려버린 것이었습니다. 개발 서버에서 테스트 삼아 걸어둔 로드밸런서가, 특정 시간대에 API 요청이 몰리자 자동으로 인스턴스를 증설한 것입니다. 이 과정에서 발생한 데이터 전송비와 스토리지 비용이 어마어마하게 청구된 것이었습니다. 특히 외부 크롤러의 요청이 평소의 수십 배로 늘어난 것도 인스턴스 증설을 부추긴 원인이었습니다.

2. AWS 요금 폭탄 방어하려다 서버가 중단되는 상황이 벌어졌다

비용 폭탄을 발견한 직후, 저는 가장 먼저 ‘오토스케일링 그룹의 최대 용량을 줄여버리는’ 조치를 취했습니다. 그런데 문제는 여기서 발생했습니다. 최소 용량과 최대 용량 관계를 제대로 확인하지 않은 채 급하게 축소 정책을 적용하자, 로드밸런서에서 인스턴스 연결이 강제로 끊기면서 서비스가 완전히 중단된 것입니다. 즉, 요금을 아끼려다가 서비스를 통째로 내려버린 셈이었습니다.

게다가 이 과정에서 기존 EC2 인스턴스에 연결되어 있던 Elastic IP(탄력적 IP)가 인스턴스에서 분리되면서 유휴 Elastic IP 요금이 부과되었고, 종료된 인스턴스의 스냅샷이 남아 있으면서 또 다른 비용이 발생했습니다. 이처럼 요금 방어를 위해 서두르다가, 오히려 더 큰 장애와 추가 비용을 유발하는 악순환이 반복됐습니다. 저는 이 경험을 통해 ‘무작정 인스턴스를 줄이는 것’이 최선의 방어가 아니라는 사실을 뼈저리게 깨달았습니다.

2-1. 내가 겪은 AWS 과금 항목의 실제 주범들

이 사건을 분석하면서, 제가 요금 폭탄을 만든 진짜 원인이 EC2 시간당 요금이 아니라 ‘데이터 전송(Data Transfer)’과 ‘스토리지(Storage)’에 있었음을 알게 되었습니다. 일반적인 EC2 시간당 요금은 생각보다 저렴하지만, 서버 간 통신비나 인터넷으로 나가는 트래픽 비용은 예상을 완전히 벗어납니다. 아래 표는 제가 경험한 사건 당시의 요금 기준입니다.

과금 항목	실제 사연	폭탄의 심각성
EC2 (t3.medium)	사건 당시 시간당 약 $0.0416, 24시간 가동	낮음 (월 4만 원 내외)
데이터 전송 (Out)	GB당 약 $0.09, 서버 10대가 동시다발적으로 약 2TB 전송	매우 높음 (약 180만 원 청구)
스냅샷 (EBS)	인스턴스 종료 후에도 100GB 규모의 스냅샷이 남아 있었음	중간 (GB당 약 $0.05)
탄력적 IP (Elastic IP)	연결하지 않고 방치할 경우 시간당 과금	낮음 (방치 시 과금)

이 표에서 보듯, EC2 인스턴스 자체보다 데이터 전송비가 압도적으로 비쌌습니다. 서버가 30개로 증설되면서 각 서버가 외부 API 호출 및 로그 전송을 반복했고, 결국 집계된 데이터 전송량이 수 테라바이트에 달한 것이 가장 큰 문제였습니다.

3. 단계별 AWS 요금 폭탄 방어 전략 (그리고 실패담)

이 사건 이후 저는 모든 설정을 뜯어고쳤습니다. 단순히 비용만 줄이는 것이 아니라, 서비스 안정성을 해치지 않으면서 비용을 방어하는 방법을 찾는 데 집중했습니다. 아래는 제가 적용한 단계별 전략입니다.

3-1. 예산 알림 및 비용 탐색기 필수 설정

가장 먼저 AWS Budgets 기능을 활용해 월별/일별 예산을 설정했습니다. 이전에는 100달러 초과 시에만 알림을 받았는데, 이제는 10달러, 30달러, 50달러, 70달러, 90달러, 100달러 총 6단계로 나누어 이메일과 문자 알림을 받도록 설정했습니다. 알림이 너무 자주 오는 것을 방지하려면 CloudWatch 경보와 달리 ‘기간 내 누적 금액’ 기준으로 임계값을 정하는 것이 편합니다. 저는 처음에 알림이 너무 많이 와서 메일함이 마비되기도 했습니다.

그다음으로 AWS Cost Explorer를 통해 일일 비용 추이를 보는 습관을 들였습니다. 이 도구 덕분에 어떤 서비스가 갑자기 비용이 튀는지 즉시 파악할 수 있었습니다. 그러나 여기서도 문제가 있었으니, 비용 탐색기 데이터가 실제 과금보다 늦게 반영된다는 점입니다. 제 경우에는 1시간 이상 지연되는 경우도 있었고, 일부 통합 지표는 더 늦게 반영될 수 있습니다. 그래서 실시간 감지는 불가능하고, ‘사후 추적’ 용도로 사용하는 것이 맞습니다. 여기에 더해 AWS Cost Anomaly Detection을 설정하면 평소 패턴에서 벗어난 비용 증가를 별도 알림으로 받을 수 있어 도움이 됩니다.

3-2. 오토스케일링 최대 용량 제한과 스케일링 정책 수정

오토스케일링 그룹의 최대 인스턴스 수를 4개로 제한했습니다. 이전에는 최대 30개까지 늘어날 수 있는 위험한 설정이었습니다. 그리고 CPU 사용률 기반이 아닌 ‘요청 수(Request Count)’ 기반으로 스케일링 정책을 변경했습니다. 이 덕분에 갑작스러운 트래픽에도 인스턴스가 폭발적으로 늘어나는 것을 방지할 수 있었습니다. 다만 요청 수가 많아도 인스턴스당 처리량이 일정하지 않을 수 있으므로, CloudWatch의 ‘TargetResponseTime’ 지표와 함께 보는 것을 추천합니다.

하지만 이 과정에서 중요한 점을 배웠습니다. 스케일링 정책을 수정할 때는 반드시 ‘최소 인스턴스 수’와 ‘최대 인스턴스 수’의 밸런스를 맞춰야 한다는 것. 그렇지 않으면 제 경우처럼 서비스가 중단되는 치명적인 결과를 초래할 수 있습니다. 조정 후에는 항상 로드 테스트를 30분간 진행하고, 인스턴스가 정상적으로 증설/축소되는지 모니터링합니다. 저는 이 과정에서 스케일링 정책 변경보다 ‘최소/최대 용량을 먼저 검토하는 습관’이 더 중요하다는 것을 배웠습니다.

3-3. 스토리지 및 스냅샷 정리 (예상치 못한 비용 절감)

더 이상 사용하지 않는 스냅샷과 EBS 볼륨을 정리했습니다. 문제는 이전에 종료한 인스턴스의 스냅샷이 AWS Backup/Lifecycle Manager 설정 때문에 자동으로 남아 있어서, 매월 약 $30~$50의 비용이 고정적으로 발생하고 있었다는 점입니다. 제가 이 사실을 발견한 것은 서버가 내려간 후 재부팅을 준비하면서 스토리지 용량이 가득 찬 상태를 확인했을 때였습니다.

그래서 저는 스냅샷 7일 보관 정책(Lifecycle Manager)을 설정해 자동으로 오래된 스냅샷을 삭제하도록 만들었습니다. 이 간단한 설정 하나로 월 비용이 확연히 줄었고, 비용 방어에 있어 ‘불필요한 데이터 정리’가 얼마나 중요한지 깨닫게 되었습니다. 스냅샷 정리를 진행하기 전에 한 번은 복원 테스트를 해보는 것이 안전합니다. 삭제된 스냅샷은 복구가 어렵기 때문입니다.

3-4. 리전과 서비스 구조 변경으로 데이터 전송비 차단

사실 데이터 전송비를 줄이는 가장 확실한 방법은 리전 간 통신을 없애고, 같은 리전 안에서 통신하거나 CloudFront와 같은 CDN을 사용하는 것입니다. 저는 서울 리전과 도쿄 리전에 걸쳐 서버를 분산 배치하고 있었는데, 이 때문에 리전 간 데이터 전송비가 발생했습니다. 이를 모두 서울 리전으로 통합하고, 정적 파일은 S3 + CloudFront로 이전했습니다. CloudFront를 S3 버킷과 연결할 때는 OAC(Origin Access Control) 설정을 통해 버킷을 직접 공개하지 않는 것이 좋습니다.

방어 방법	장점	단점/주의사항	효과
서버 리전 단일화	리전 간 통신비 제거	재해 복구(DR) 측면에서 취약	제 경우 월 $300 이상 절감
CloudFront 도입	엣지 캐싱으로 트래픽 비용 절감	잦은 캐시 무효화 시 추가 비용 발생 가능	제 경우 트래픽 요금 약 30~50% 절감
스냅샷 수명주기 설정	자동으로 오래된 백업 삭제	삭제 날짜 설정 실수 시 복구 불가	제 경우 월 $50 고정비 제거

4. 서버 복구 후 AWS 요금 폭탄 최종 분석 (결산)

서버가 내려간 후 복구하는 데 약 3시간이 걸렸고, 스트레스는 이루 말할 수 없었습니다. 하지만 이 경험을 바탕으로 철저한 방어 체계를 구축하니, 다음 달 청구서는 평소의 40% 수준으로 감소했습니다. 제가 최종적으로 한 일은 다음과 같습니다.

4-1. AWS 요금 폭탄 최종 체크리스트 공유

• ✅ 핵심 서비스에 예산 알림(Budget) 6단계 이상 설정
• ✅ 오토스케일링 최대 인스턴스 수 4개, 최소 2개로 유지
• ✅ 사용하지 않는 탄력적 IP, 스냅샷, EBS 볼륨 주간 정기 점검
• ✅ CloudFront 도입하여 외부 트래픽 비용 차단
• ✅ 루트 계정 MFA + IAM 사용자 분리하여 보안 사고 예방

여기서 중요한 것은 가장 저렴한 방법으로 방어하는 것이 아니라, 서비스 안정성과 비용 효율을 동시에 잡는 것입니다. 만약 제가 안전장치 없이 최대 용량을 과도하게 줄였다면, 트래픽이 다시 몰렸을 때 서비스는 또 한 번 다운될 뻔했습니다. 그래서 저는 최대 용량을 4개, 최소 용량을 2개로 유지하면서, 네트워크 사용률이 70%를 넘어가면 배포를 잠시 중단하는 ‘안전장치’를 코드로 구현했습니다. 이렇게 하면 요금 폭탄의 원인이 되는 급격한 스케일링을 기술적으로 차단하면서도, 평소 트래픽에는 충분히 대응할 수 있습니다.

5. 결론: 요금 폭탄은 예방이 아니라 관리다

오늘 제가 겪은 AWS 요금 폭탄 사건은 단순한 해프닝이 아니라, 클라우드 인프라를 운영하는 모든 개발자에게 반드시 필요한 교훈을 남겼습니다. 요금 폭탄을 100% 예방하는 것은 불가능하지만, 알림 설정과 스토리지 정리, 그리고 인스턴스 규모 조정의 원칙만 명확히 지킨다면 폭탄이 터지더라도 최소한의 피해로 막을 수 있습니다.

지금 이 글을 읽고 계신다면, 당장 AWS 콘솔에 접속해서 예산 알림을 10달러 단위로 촘촘히 설정하고, 오토스케일링 그룹의 설정값을 한 번 더 확인하시기를 권장합니다. 제가 겪은 것처럼 서버가 통째로 내려가는 최악의 사태를 막기 위한 첫걸음입니다. 클라우드 비용은 ‘방어’가 아니라 ‘일상적인 관리’의 영역입니다. 미리 시스템을 점검하고, 자동화된 방어 체계를 구축하는 것이 진정한 비용 최적화의 시작입니다.