매달 AWS 비용 청구서를 보다가  트래픽은 지난달과 크게 다르지 않은데 청구액이 왜 늘어났는지 의문이 든 적 있었나요? 콘솔을 들여다봐도 어디서 비용이 새고 있는지 감이 잘 잡히지 않을 수 있는데요.

AWS 비용을 통제하려면 과금 구조를 파악해야 합니다! 컴퓨팅, 스토리지, 데이터 전송에서 과금이 발생합니다. 이 셋의 누수 패턴을 잡는 것만으로도 평균 30~40%의 비용을 줄일 수 있습니다.

이 글은 AWS를 운영 중인 CTO·DevOps·인프라 담당자를 위한 정리입니다. 세 영역 어디에서 비용이 새고, 어떻게 막을 수 있는지를 구체적으로 살펴보겠습니다.

컴퓨팅: '안 쓰는 시간'까지 과금되고 있습니다

EC2와 Lambda, RDS 같은 컴퓨팅 리소스는 사용량 기반으로 과금됩니다. 쓴 만큼 지불하는 구조라서 합리적으로 보이지만, 정작 많은 기업이 '쓰지 않는 시간'까지 비용을 내고 있습니다.

퇴근 이후 아무도 접속하지 않는 개발 서버가 24시간 돌아가는 경우나 트래픽이 절반으로 줄어도 인스턴스 대수는 그대로일 때 비용이 새고 있습니다. 

아래 사항을 점검해 보세요.

• 개발·스테이징 서버가 야간이나 주말에도 계속 실행되고 있지 않은가
• 실제 CPU 사용률이 20%도 안 되는데 과하게 큰 인스턴스 타입을 쓰고 있지 않은가
• Auto Scaling이 빠져 있거나, 최소 대수가 과하게 잡혀 있지 않은가
• 예약 인스턴스(RI)나 Savings Plans 없이 온디맨드로만 운영하고 있지 않은가

이중 우리 회사에 해당하는 사항은 몇 개인가요? 경우에 따라 여기에서만 30% 이상의 비용을 낭비하고 있는 기업이 적지 않다고 하네요.

사용량 기반 과금제는 '얼마나 똑똑하게 쓰느냐'에 따라 비용 절감액이 달라집니다. 시간과 규모를 트래픽에 맞춰 사용법을 개선해 보세요!
Auto Scaling으로 수요에 따라 자동 증감시키고, 장기 사용 구간은 Savings Plans로 최대 72%까지 할인받을 수 있습니다. 야간에 비가동 리소스를 끄는 스케줄링만 적용해도 적지 않은 절감 효과가 나옵니다.

[참고] EC2 요금 체계를 온디맨드·RI·Savings Plans별로 비교하고 싶다면?
👉 <AWS EC2 요금은 어떻게 되나요?> 글을 살펴보세요! 

스토리지: 어제 만든 데이터가 오늘의 청구서를 늘립니다

S3와 EBS, EFS 같은 스토리지 비용은 한 번 발생하면 계속 비용으로 나갑니다. 컴퓨팅처럼 '끄면 줄어드는' 구조가 아니기 때문이죠. 데이터를 저장하는 순간부터, 그 데이터를 누군가 쓰든 말든 매달 같은 금액이 빠져나갑니다.

인스턴스를 종료하면서 EBS 볼륨은 그대로 남고, 백업으로 만든 스냅샷이 수년치 쌓이고, 종료 통보 없이 잊힌 테스트 RDS 인스턴스가 살아 있습니다. 로그·백업이 차곡차곡 들어가는 S3 버킷에는 1년 전 디버깅 자료가 그대로 보관됩니다. 자산화하기 위해 자료를 보관하지만, 쓰지 않는 데이터는 비용을 갉아먹을 뿐입니다.

이 문제는 '시스템이 자동으로 정리'하게 만들면 해결할 수 있습니다.
S3에 라이프사이클 정책을 설정하면 자주 쓰는 데이터는 Standard에, 가끔 쓰는 데이터는 Infrequent Access에, 거의 안 쓰는 데이터는 Glacier로 자동 이동시킬 수 있습니다. 한 번 정책을 걸어두면 매달 최대 70%까지 스토리지 비용이 줄어드는 사례가 많습니다.

EBS는 gp2에서 gp3로 전환만으로 약 20% 저렴해집니다. 사용하지 않는 스냅샷은 AWS Backup으로 정리하고, 미사용 리소스는 Trusted Advisor와 Cost Explorer로 분기마다 가시화합니다.

[참고] 스냅샷과 백업을 수동으로 관리하고 계신가요? 자동화 설정 방법을 정리해 뒀습니다.
👉 AWS Data Lifecycle Manager(DLM)로 백업 자동화하기

데이터 전송: AWS 안에서만 끝나고 있습니까

세 영역 가운데 가장 늦게 발견되는 비용인 데이터 전송. 청구서에 'Data Transfer'로 단일 라인이 잡히지만, 그 안에서 어떤 데이터가 어디로 흘렀는지 추적하기가 까다롭습니다. 다시 말하면, 새고 있는데 어디서 새는지 안 보이는 영역입니다.

AWS 안으로 들어오는 데이터는 대부분 무료, 밖으로 나가는 데이터는 유료인데요. 같은 AWS 안이라도 리전이나 가용영역(AZ)이 다르면 요금이 붙습니다. 창고에 짐을 쌓을 때는 비용이 들지 않지만, 외부로 배송할 때마다 무게당 요금이 붙는 택배 구조로 비유해 설명해 드리겠습니다.

문제는 우리 회사 데이터를 매달 어디로 얼마나 '배송'하고 있는지 추적조차 하지 않는 기업이 많다는 점입니다.

아웃바운드 트래픽이 늘어나는 지점은 대체로 아키텍처 결정과 맞닿아 있습니다. CloudFront(CDN)를 거치지 않고 S3에서 사용자에게 직접 전송하는 구조, 리전 간 데이터 복제가 필요 이상으로 잡혀 있는 설정, 멀티 AZ 구성에서 AZ 간 트래픽이 과도하게 오가는 토폴로지, API 응답에 불필요하게 큰 페이로드가 실리는 패턴까지. 비용 문제로 보기보단 설계 문제로 봐야할 것입니다.

해결 방향도 같습니다. 데이터를 최대한 AWS 안에서, 그리고 사용자와 가까운 곳에서 처리하도록 아키텍처를 다시 잡는 것입니다.

CloudFront를 앞단에 두면 캐싱된 콘텐츠가 원본까지 가지 않아 전송 비용을 최대 60%까지 줄일 수 있습니다. VPC 엔드포인트를 활용하면 S3나 DynamoDB 트래픽이 인터넷 구간을 타지 않습니다. 로그도 가능한 한 같은 리전 안에서 처리하도록 설계를 손봅니다.

서버 비용에만 집중하기 쉽지만, 실제로는 이 보이지 않는 택배비가 전체 청구서의 20% 이상을 차지하는 경우가 흔합니다.

[참고] 클라우드 비용 진단을 외부 파트너와 함께 진행한 사례가 궁금하신가요?
👉 파이브클라우드 클라우드 비용 컨설팅 사례를 함께 보시면 도움이 됩니다.

지금 점검할 3가지

1. 사용량 기반 리소스가 적정 크기로 운영되고 있나요?

CPU·메모리 사용률을 한 주만 모니터링해 봐도 인스턴스 사이징이 과한지 부족한지 답이 나옵니다. Auto Scaling 적용 여부와 Savings Plans 커버리지를 함께 점검합니다.

2. 방치된 스토리지와 스냅샷이 매달 얼마를 소모하고 있나요?

Cost Explorer에서 스토리지 항목을 분리해 보면 인지하지 못한 EBS 스냅샷, 미사용 볼륨, 오래된 S3 데이터가 드러납니다. 라이프사이클 정책 설정 여부부터 확인합니다.

3. 아웃바운드 트래픽이 CDN과 VPC 엔드포인트로 최적화되어 있나요?

청구서의 'Data Transfer' 항목 비중을 한 번 확인하시기 바랍니다. 전체의 15%를 넘는다면 CloudFront 도입이나 엔드포인트 설계를 검토할 시점입니다.

AWS 비용을 잡는 일은 기술 작업이라기보다 운영 결정에 가깝습니다. 컴퓨팅에서 '쓰지 않는 시간'을 줄이고, 스토리지에서 '시스템이 자동으로 정리하게' 하고, 데이터 전송에서 '아키텍처를 사용자 가까이로 옮기는 일.' 이 세 가지를 실행한다면 새는 비용을 줄여나갈 수 있습니다.

다만 셋을 동시에 손보는 시도는 권장하지 않습니다. 청구서에서 비중이 가장 큰 영역부터 차근 차근 정리하는 편이 더 빠릅니다. 하나를 정리하고 나면, 다음 영역에서 새고 있는 비용도 같은 관점으로 드러나기 때문이죠.