AWS 서버 비용구조, 비용최적화가 어려운 이유

by 멘토사피엔스

Jun 4. 2025

“우리 AWS 요금, 왜 이렇게 나올까?”

아마 많은 팀이 이런 경험을 해봤을 겁니다.

서버는 몇 대 안 되는데, 매달 청구되는 금액은 예상보다 훨씬 많고, 누구에게 물어봐도 “왜 이렇게 나왔는지” 명확히 설명해주는 사람이 없습니다.

AWS는 쓴 만큼만 내면 된다고 홍보하지만, 실제로는 ‘왜 이렇게 쓴 건지’ 파악하기도 어렵고,

‘어디서 줄여야 할지’ 결정하기도 어렵습니다.

AWS 비용 구조의 본질 이해

Pay-as-you-go: 사용한 만큼 과금하는 구조

“AWS는 비싼게 맞습니다”

AWS는 Pay-as-you-go, 즉 쓴 만큼 낸다는 원칙으로 돌아갑니다.

처음엔 정말 매력적이죠. 서버를 켜기만 하면 되고 원하는 기능들을 편리하게 잘 만들어두었습니다. 온프레미스로 운영할 때보다 훨씬 쉽고 안정적으로 운영 가능합니다.

그러나 그만큼 가격은 온프레미스 대비 훨씬 비쌉니다. 단순히 서버를 구매하는 관점에서만 비교하면 1년 유지 비용으로 온프레미스에서 사용할 서버를 구매할 수 있습니다. 아래 예시를 보겠습니다.

AWS 온디맨드 1년 사용 비용 (서버만)

예시 인스턴스: m5.xlarge (4 vCPU, 16GB RAM)

시간당 비용 (서울 리전): $0.214

월 비용 (24시간 × 30일 기준): 0.214 × 24 × 30 = $154.08 ≈ 약 21만 원

1년간 총비용: 21만 원 × 12개월 = 약 252만 원

온프레미스 서버 구매 가격

비슷한 사양의 타워형 서버 (예: Dell PowerEdge T150, Xeon 4코어급 + 16GB RAM + SSD 1TB): 약 150~200만 원 선

1년이 안되는 기간의 서버 사용료는 온프레미스 서버 구매비용을 이미 상회합니다.

물론 유지보수에 들어가는 리소스, 하드웨어 유지보수에 들어가는 이 비교는 전기료, 인건비, 장애 대응, 공간 비용 등 부가비용을 제외한 것이고, 그럼에도 불구하고 장기 사용 시 온프레미스가 훨씬 저렴한 구조라는 점은 명확합니다.

온디맨드의 유연함은 결국 ‘과금의 덫’이 됩니다. 온디맨드(On-Demand)는 AWS의 기본 과금 방식입니다.

이름 그대로, 언제든 원하는 만큼 쓰고, 원하는 만큼 내는 방식이죠. 초기에 실험하고 빠르게 프로토타입을 만드는 데는 탁월합니다.

하지만 서비스를 오픈하고 나면 ‘늘 켜둬야 하는’ 리소스들이 생깁니다.

예를 들어, EC2에 웹서버를 띄웠다면 24시간 돌아가야 하겠죠. RDS로 DB를 쓰고 있다면? 트래픽이 없어도 계속 켜져 있어야 합니다. Lambda는 사용량 기반이지만, 호출 빈도가 높아지면 요금도 빠르게 늘어납니다.

결국, 유연함이 비용적으로 비효율로 바뀌는 지점이 옵니다.

EC2, RDS, Lambda의 과금 차이와 숨은 비용들

EC2는 가장 전통적인 컴퓨팅 서비스로, 가상 서버를 띄우는 개념입니다. EC2는 초 단위로 과금되지만 최소 과금은 1분부터 시작되고, 운영체제 종류나 인스턴스 타입에 따라 요금이 크게 달라집니다.

주의해야 할 점은, 인스턴스를 정지시키더라도 연결된 EBS(스토리지)는 계속 과금된다는 것입니다. 또한, 고정 IP를 할당해두고 인스턴스에 연결하지 않으면 IP 유지 비용이 따로 발생합니다. 심지어 같은 VPC 내에서 EC2 인스턴스끼리 통신하더라도, 서로 다른 가용영역(AZ)에 있다면 AZ 간 트래픽 요금이 붙습니다.

다음으로 RDS는 관리형 데이터베이스 서비스입니다. RDS는 DB 인스턴스 자체 사용료는 물론, 여기에 연결된 스토리지(EBS), 자동 백업 스냅샷, 읽기 복제본, 고성능 IOPS 옵션 등 다양한 항목에서 추가 요금이 발생합니다.

많은 사용자가 간과하는 부분은 자동 백업입니다. RDS는 기본적으로 일정 기간 동안 백업을 유지하는데, 이 기간을 넘는 백업은 추가 과금되며, 필요 이상으로 백업을 오래 보관하면 스토리지 비용이 많이 늘어날 수 있습니다. 또한 고가용성을 위해 Multi-AZ를 설정하면 복제본까지 요금이 따로 청구되기 때문에 실질적으로는 두 배의 요금을 낼 수 있습니다.

Lambda는 완전히 다른 방식의 과금 구조를 가집니다. 서버를 직접 운영하지 않는 서버리스 방식으로, 함수가 호출될 때마다 실행 시간과 메모리 사용량을 기준으로 요금이 부과됩니다. 겉보기에는 매우 효율적으로 느껴지지만, 여기도 숨은 비용이 있습니다.

예를 들어 Lambda를 VPC 안에서 실행하게 되면 ENI(Elastic Network Interface)가 자동으로 생성되며, 외부 인터넷과 통신할 때 NAT Gateway를 경유해야 해 추가 요금이 발생합니다. 게다가 함수 실행 결과나 로그가 자동으로 CloudWatch에 쌓이면서 이 로그 저장 비용도 무시할 수 없습니다. 호출 빈도가 많을 경우, 단위 비용은 작더라도 누적 금액이 상당해질 수 있습니다.

세 서비스 모두 각기 다른 과금 원칙을 가지고 있고, 단순히 “인스턴스를 켰다”거나 “함수를 호출했다”는 행위 외에도 여러 추가 요소가 비용으로 연결됩니다.

왜 AWS 비용 최적화는 어렵다고 느껴지는가

워크로드 예측의 어려움: 스케일 변화와 트래픽 불확실성

클라우드의 최대 장점은 탄력성입니다. 필요할 때만 리소스를 쓰고, 필요 없을 때는 줄이면 된다는 구조는 분명 합리적으로 보입니다. 그러나 현실은 다릅니다.

트래픽은 늘 예측대로 움직이지 않습니다. 오늘 평온했던 서비스도, 내일 특정 이벤트나 외부 이슈로 인해 갑자기 트래픽이 3배 이상 폭증할 수 있습니다. 이럴 때를 대비해 미리 인프라를 준비해두자니 비용 낭비가 걱정되고, 그렇다고 너무 최소 단위로만 구성하자니 장애 대응이 불안합니다.

또한, 서비스의 성장세나 마케팅 일정, 혹은 사용자 패턴에 따라 스케일의 변화폭이 주기적으로 크게 달라지기도 합니다. 예를 들어, 매달 1일에 집중되는 정산 트래픽, 특정 시즌의 이벤트 세일, 또는 뉴스나 SNS 바이럴에 따른 예기치 못한 폭주 등은 모두 트래픽 예측을 어렵게 만듭니다.

결국 이런 불확실성 속에서 “RI(Reserved Instance)나 SP(Savings Plans)를 구매해도 되는가?“라는 고민은 현실적인 리스크가 됩니다. 만약 잘못된 예측으로 고정 약정을 맺었다가 트래픽이 줄어들게 되면, 사용하지도 않는 리소스에 대해 계속 요금을 지불해야 할 수도 있기 때문입니다.

이처럼, AWS의 비용 최적화 전략은 단순히 리소스 단가를 낮추는 문제가 아닙니다. 앞으로의 사용량을 얼마나 정확히 예측할 수 있는가라는, 예측 역량과 운영 리스크 관리의 문제입니다. 바로 이 점이 많은 팀이 AWS 비용 최적화를 어렵게 느끼는 근본적인 이유 중 하나입니다.

리소스 남용 vs 낭비 방지: 개발자와 인프라팀의 관점 차이

AWS 비용 최적화를 실제로 추진해보면, 기술적인 문제보다 조직 내 관점 차이가 더 큰 장애물로 다가오는 경우가 많습니다. 특히 인프라팀과 개발팀 간의 리소스를 바라보는 시각은 때때로 완전히 다릅니다.

개발자는 본질적으로 ‘서비스 안정성과 속도’를 중시합니다. 기능을 개발하고 테스트하며, 장애 없이 서비스가 동작하도록 만드는 것이 주요 목표입니다. 이 관점에서 보면, EC2 인스턴스는 여유 있게 잡아두는 것이 좋고, RDS도 여유 있는 스펙으로 시작하는 것이 안전합니다. 갑작스런 장애나 성능 저하가 생겼을 때 원인을 리소스 부족으로 의심하기보다, “애초에 넉넉히 잡았더라면…” 하는 후회가 더 치명적이기 때문입니다.

반면 인프라팀은 비용 최적화와 자원 효율성을 목표 과제로 제시받습니다. 쓰지도 않는 대형 인스턴스가 수개월째 구동되고 있거나, 하루 몇 번 쓰는 QA 환경이 24시간 내내 떠 있는 상황은 명백한 낭비로 보입니다.

인프라팀 입장에서는 사용률이 낮은 자원은 꺼야 하고, 고정 비용은 줄여야 하며, 자동화로 유휴 자원을 정리해야 한다는 시급한 과제가 됩니다.

AWS는 ‘필요할 때만 쓰고 필요 없을 땐 꺼라’는 구조를 전제로 설계되었지만, 실제 조직 내에서는

“항상 켜 두는 것이 안전하다”는 관점과 “가능하면 꺼야 한다”는 원칙이 충돌하게 되는 것입니다.

이 지점은 결국 회사가 어떤 방향성을 추구하느냐와 맞물려 있습니다. 사용자의 안정성과 비용 최적화 사이에서 매 의사결정 시점마다 합리적인 판단을 할 수 있어야 합니다.

멀티 계정, 태그 누락, 불투명한 책임 구조

AWS를 일정 규모 이상 사용하는 조직이라면 대부분 멀티 계정 구조를 도입하고 있습니다. 보안 분리, 권한 통제, 프로젝트별 자산 관리의 이유로 계정을 분리하는 것은 모범적인 아키텍처입니다. 하지만 비용 관점에서는 이 구조가 예상보다 큰 복잡성을 초래합니다.

첫 번째 문제는 비용 가시성의 단절입니다. 계정이 많아질수록 총 비용은 Consolidated Billing으로 통합되지만, 어떤 서비스가 어디서 왜 사용되는지는 한눈에 파악하기 어려워집니다.

예를 들어 특정 테스트 계정에서 남아 있는 오래된 EC2 인스턴스나, 잊힌 S3 버킷 하나가 수개월간 비용을 발생시켜도, 이를 식별하고 조치하기까지 시간이 오래 걸립니다.

두 번째는 태그 누락입니다.

AWS에서는 비용을 서비스, 프로젝트, 팀, 환경(dev/prod) 단위로 나누려면 리소스마다 태그를 잘 붙여야 합니다. 하지만 실무에서는 이 태깅이 누락되거나 일관되지 않게 적용되는 일이 흔합니다.

개발자가 급하게 띄운 테스트 서버, IaC 코드 누락, 또는 수동 설정 중 실수로 태그가 빠지는 경우입니다. 태그가 빠지면, 비용은 발생하는데 ‘누가 썼는지’ 알 수 없게 됩니다. 이는 곧 책임소재의 불분명으로 이어지고, 관리자는 “비용은 보이는데 추적이 안 되는” 상황에 처하게 됩니다