AWS 요금이 예상보다 많이 나오는 이유 : 분명히 많이 쓴 것도 없는데…

AWS를 처음 쓰면 이런 생각을 할 수 있습니다. “쓴 만큼만 나온다는데, 우리가 뭐 엄청 쓴 것도 없는데 왜 이렇게 나와?” 실제로 비용이 튀는 팀은 트래픽이 폭증한 경우도 있지만, 그보다 흔한 건 조용히 새는 비용입니다. 켜둔 채 잊은 리소스, 쌓이는 로그와 스냅샷, 생각보다 비싼 데이터 전송 같은 것들요.

그래서 AWS 요금이 예상보다 많이 나오는 이유를 잡으려면 “서버가 몇 대냐”보다 “돈이 어디로 새는지”부터 보는 편이 좋습니다. 

 

 

 

 

미사용 리소스가 제일 흔합니다: 안 쓰는데 계속 과금

AWS 비용이 늘어나는 가장 현실적인 이유는 ‘안 쓰는 걸 안 끄는 것’입니다. 테스트용 EC2, 임시로 만든 EBS, 사용 안 하는 로드밸런서, 예전 환경에서 남은 스냅샷 같은 것들이 조용히 남습니다. 바쁠수록 잘 생기고, 누구 책임인지 흐려질수록 더 오래 남습니다. 여기서 비용이 꾸준히 누적됩니다.

체크 포인트

• 쓰지 않는 EC2 / Auto Scaling 그룹이 남아 있지 않은지
• 분리된 EBS 볼륨(Detached)과 오래된 스냅샷이 쌓이지 않았는지
• Elastic IP(특정 조건에서)나 사용 안 하는 리소스가 방치되지 않았는지

안 쓰는 리소스가 가장 비쌉니다.

 

 

데이터 전송(특히 Outbound) 비용이 의외로 큽니다

AWS는 “컴퓨팅”만 비용이 드는 게 아닙니다. 밖으로 나가는 데이터 전송(egress)이 커지면 청구서가 확 달라질 수 있습니다. 이미지/동영상/파일 다운로드가 많거나, 같은 데이터를 반복 전송하는 구조면 더 그렇습니다. CDN 없이 S3나 EC2에서 직접 내보내는 패턴도 비용이 커질 수 있습니다.

체크 포인트

• 정적 파일(이미지/JS/CSS)을 CloudFront 같은 CDN으로 분리했는지
• 원본 이미지를 그대로 내려보내고 있진 않은지(리사이즈/압축)
• API 응답이 불필요하게 큰지(JSON 과다, 중복 데이터)

트래픽은 “양”보다 “반복과 낭비”에서 튑니다.

 

 

NAT Gateway는 ‘편한 만큼’ 비용 감각이 무뎌지기 쉽습니다

VPC 구성에서 NAT Gateway는 자주 쓰이지만, 비용이 커질 수 있는 구간입니다. 프라이빗 서브넷의 인스턴스가 외부로 나갈 때 NAT를 타면, 사용량이 늘수록 과금이 붙습니다. 특히 업데이트/패키지 다운로드/컨테이너 이미지 pull 같은 작업이 잦으면 체감이 더 커집니다.

체크 포인트

• NAT를 통해 나가는 트래픽이 과도한지(예: 이미지 pull, 로그 전송, 업데이트)
• VPC Endpoint(S3/DynamoDB 등)로 우회 가능한 구간이 있는지
• 환경(dev/qa)에도 NAT가 불필요하게 상시 켜져 있지 않은지

“나가는 길”이 돈이 될 때가 많습니다.

 

 

로그가 쌓이면 저장+분석 비용이 같이 옵니다

CloudWatch Logs, ALB 액세스 로그, 애플리케이션 로그를 “일단 다 남기자”로 시작하면 비용이 늘기 쉽습니다. 로그는 저장 비용뿐 아니라, 수집/검색/분석 과정에서 비용이 붙는 경우가 있습니다. 특히 디버그 로그를 운영 환경에 오래 켜두면, 양이 급격히 늘어납니다.

체크 포인트

• 로그 보관 기간이 과도하게 길지 않은지(Retention 설정)
• DEBUG 레벨 로그가 운영에 상시 켜져 있지 않은지
• ALB/CloudFront 로그를 무조건 전부 보관하고 있진 않은지

기록은 필요하지만, 기간 정책이 없으면 요금이 자랍니다.

 

 

S3/스냅샷/백업은 “정리 안 하면” 끝이 없습니다

S3는 단가가 낮아 보이지만, 버전 관리(versioning), 오래된 객체, 백업 파일이 쌓이면 총량이 커집니다. RDS 스냅샷, EBS 스냅샷, 백업 보관도 비슷합니다. 특히 “예전에 남긴 스냅샷”이 계속 쌓이는 경우가 흔합니다. 한 번에 확 튀기보다 서서히 늘어나서 더 늦게 알아차립니다.

체크 포인트

• S3 Lifecycle 정책이 있는지(IA/Glacier로 이동, 자동 삭제)
• 스냅샷/백업 보관 기간이 현실적인지(기준이 문서로 있는지)
• 버전 관리로 인해 같은 파일이 여러 버전으로 쌓이지 않는지

저장은 조용히 늘고, 청구서는 뒤늦게 보입니다.

 

 

오토스케일이 ‘자동으로’ 비용을 늘리는 경우도 있습니다

Auto Scaling은 편하지만, 정책이 거칠면 비용도 같이 커집니다. CPU가 조금만 올라가도 과하게 늘어나거나, 줄어드는 조건(scale-in)이 보수적으로 잡혀 서버가 잘 안 줄어드는 경우가 있습니다. 트래픽 스파이크가 잠깐 왔는데 인스턴스가 늘어난 채로 오래 유지되면 청구서가 올라갑니다.

체크 포인트

• 최소/최대 인스턴스 수가 과하게 잡혀 있지 않은지
• 스케일 인 조건(줄이는 조건)이 너무 느슨하지 않은지
• 스파이크 이후에 정상으로 돌아오는지(그래프 확인)

자동화는 편하지만, 설정이 비용을 결정합니다.

 

 

RDS는 “편하게 쓰는 대신” 비용이 급격히 커질 수 있습니다

RDS 비용은 인스턴스 스펙만이 전부가 아닙니다. 스토리지 증가, I/O 패턴, 백업 보관, 멀티 AZ, 리드 레플리카 등 조합에 따라 체감이 달라집니다. 그리고 DB 성능 문제가 구조적으로 해결되지 않으면 “스펙 업”으로 덮기 쉬운데, 그 순간부터 비용이 고정으로 커집니다.

체크 포인트

• 느린 쿼리/인덱스 문제를 스펙으로만 덮고 있지 않은지
• 리드 트래픽을 캐시/리드 레플리카로 분산할 여지가 있는지
• 백업/스냅샷 보관 정책이 명확한지

DB는 커지기 시작하면 줄이기 어렵습니다.

 

 

ELB(로드밸런서)와 서비스 구성도 누적되면 비용이 됩니다

ALB/NLB는 운영상 필수인 경우가 많지만, 환경이 늘어나고 서비스가 쪼개지면서 로드밸런서가 계속 생길 수 있습니다. dev/qa/live 환경에 각각 두고, 서비스별로 또 두고… 어느 순간 ‘이거 다 필요했나?’가 됩니다. 기능을 분리하는 건 좋지만, 비용 감각이 없으면 구조가 청구서로 돌아옵니다.

체크 포인트

• 환경별로 불필요한 LB가 남아 있지 않은지
• 작은 서비스가 과하게 분리되어 운영 비용이 늘지 않았는지
• 트래픽이 거의 없는 리소스가 상시 운영되고 있지 않은지

구조는 좋아지는데, 비용이 같이 오르는 패턴도 있습니다.

 

 

비용이 커지는 진짜 이유: “누가 관리하나”가 비어 있습니다

AWS 비용은 기술 문제이기도 하지만 운영 문제이기도 합니다. 개발은 담당자가 있는데, 비용 최적화는 담당자가 없는 팀이 많습니다. 그러면 리소스는 늘고, 정리는 미뤄지고, 청구서는 매달 올라갑니다. 그래서 실무에서는 아주 단순한 규칙이 오히려 효과가 큽니다. 태그(팀/프로젝트/담당자) 강제, 예산 알림, 월 1회 정리 루틴 같은 것들요.

바로 적용 가능한 습관

• 리소스 태그(Owner/Project/Env)를 필수로 두기
• 예산 알림(Budgets)과 비용 이상 탐지(Cost Anomaly Detection) 켜두기
• 월 1회 “정리 데이”로 미사용 리소스 점검하기
• 로그/백업 보관 기간을 문서로 고정하기

관리하지 않으면 비용은 습관대로 늘어납니다.

 

 

---

 

AWS 요금이 예상보다 많이 나오는 이유는 대개 한 가지가 아니라, 미사용 리소스 방치, 데이터 전송, NAT, 로그/스토리지 누적, 오토스케일 정책, RDS 구조, 로드밸런서 확장 같은 요소가 겹친 결과입니다. 청구서를 줄이려면 “서버가 몇 대냐”보다 “어디에서 조용히 새는지”부터 보는 편이 좋습니다.