같은 서버라도 구매 방식에 따라 가격이 달라진다. 기준은 하나 — "얼마나 오래, 얼마나 확실하게 쓰는가."
온디맨드는 약정 없이 쓴 만큼(가장 유연, 단가는 가장 비쌈), RI·Savings Plans는 1~3년 약정으로 크게 할인, 스팟은 남는 용량을 가장 싸게 쓰되 회수될 수 있다.
RI와 Savings Plans의 차이는 무엇을 약정하느냐 — RI는 인스턴스 속성, Savings Plans는 시간당 사용 금액. 그래서 Savings Plans가 더 유연하다.
프리 티어는 신규 사용자를 위한 무료 한도(12개월 / 상시 무료 / 체험판). 한도를 넘으면 정상 과금된다.
약정 할인(RI·SP)과 볼륨 할인은 다른 것. 볼륨 할인은 약정 없이 사용량이 늘면 자동으로 단가가 내려가는 구조다.
이번 주는 돈 이야기다. 클라우드의 가장 큰 매력 중 하나가 "쓴 만큼만 낸다"인데, 사실 같은 자원도 어떤 방식으로 구매하느냐에 따라 가격이 크게 달라진다. 오늘은 EC2를 중심으로 한 컴퓨팅 요금 모델 — 온디맨드, 예약 인스턴스(RI), Savings Plans, 스팟 — 과 신규 사용자를 위한 프리 티어, 그리고 쓸수록 단가가 내려가는 볼륨 할인을 정리한다.
핵심 질문은 하나다: "이 워크로드는 얼마나 오래, 얼마나 예측 가능하게 돌아가는가?" 그 답에 따라 가장 싼 구매 방식이 결정된다.
처음 보면 이상하다. 똑같은 서버를 빌려 쓰는데 왜 사는 방법이 네다섯 가지나 되고 가격이 몇 배씩 차이가 날까. 이유를 알면 외우지 않아도 된다.
클라우드 이전에는 선택지가 사실상 하나, 서버를 사는 것뿐이었다. 회사는 "앞으로 3년간 얼마나 필요할까"를 미리 추측해 장비를 주문했고, 크게 잡으면 놀고 있는 서버에 돈이 묶였고 작게 잡으면 성수기에 서비스가 멈췄다.
클라우드는 이 문제를 "빌려 쓰기"로 풀었다. 그런데 빌려주는 쪽에도 사정이 있다. AWS는 데이터센터를 미리 지어 두고 서버를 채워 놓아야 하므로, "3년간 꾸준히 쓰겠다"고 약속해 주는 고객은 계획을 세우기 쉬운 귀한 고객이고 그만큼 싸게 줄 여지가 생긴다. 반대로 아무도 안 쓰고 남아도는 서버는 그냥 두면 수익이 0이니 헐값에라도 넘기는 게 이득이다.
요금 모델의 정체가 여기서 드러난다. 이건 기술 분류가 아니라 거래 조건의 분류이고, 우리가 항공권을 살 때와 같은 구조다.
항공권
AWS 요금 모델
거래 조건
당일 창구에서 사는 정가 티켓
온디맨드
언제든 살 수 있고 언제든 취소, 대신 제일 비쌈
미리 끊는 왕복 할인 티켓
예약 인스턴스(RI)
날짜·노선을 확정하는 대가로 할인
특정 항공사 연간 이용권
Savings Plans
"1년에 이만큼 타겠다"만 약속, 노선은 자유
출발 직전 남은 좌석
스팟 인스턴스
가장 싸지만 자리가 없어질 수 있음
전세기 통째로 빌리기
전용 호스트
물리 장비를 통째로 독점
이 표에서 읽어야 할 원리는 하나다. "내가 유연성을 포기할수록 값이 싸진다." 온디맨드는 유연성을 100% 쥐고 있어서 비싸고, 약정은 기간을 내주는 대신 할인을 받고, 스팟은 "언제 끊겨도 좋다"는 위험까지 감수하는 대가로 가장 싸다. 시험에서 어떤 모델을 골라야 할지 막히면 "이 워크로드는 무엇을 포기할 수 있는가"를 물어보면 답이 나온다.
온디맨드는 가장 기본적인 요금 모델이다. 장기 약정이나 선결제 없이, 실행한 시간(또는 초) 단위로만 비용을 낸다. 언제든 시작하고 언제든 끄면 그만이다. 대신 단가는 가장 비싸다.
언제 좋을까. 트래픽을 예측하기 어렵거나, 단기 프로젝트, 처음 개발·테스트하는 단계처럼 얼마나 쓸지 모를 때 적합하다. "일단 써보고 패턴을 파악한 뒤" 다른 모델로 최적화하는 출발점이기도 하다.
"약정 없이", "유연하게", "예측 불가능한 워크로드", "단기 사용"이 보이면 온디맨드다. 비용 최적화의 출발점이지 종착점은 아니다.
가장 가까운 비유는 택시다. 어디로 갈지 미리 정하지 않아도 되고, 타고 싶을 때 타고 내리고 싶을 때 내린다. 미터기는 탄 만큼만 올라간다. 대신 매일 같은 길을 오간다면 택시비는 정기권보다 훨씬 비싸다.
그래서 온디맨드는 트래픽 규모를 아무도 모르는 신규 서비스, 몇 주짜리 단기 프로젝트, 밤에는 꺼두는 개발·테스트 환경, 그리고 평소 약정분 위에 갑자기 몰릴 때만 얹는 여유분에서 값을 한다. 특히 꺼둔 시간에는 요금이 발생하지 않는다는 점이 개발 환경에서 크게 작용한다.
⚠️ 함정: "온디맨드는 비싸니까 나쁜 선택"이라고 외우면 안 된다. 문항에 "약정을 원하지 않는다", "요구사항이 아직 불확실하다"가 들어 있으면 정답은 온디맨드이고, 이때 RI나 Savings Plans를 고르면 오답이다. 싼 게 곧 정답은 아니고 조건을 만족하는 것 중 싼 것이 정답이다.
예약 인스턴스 = 특정 구간 정기권. "이 구간을 1년간 타겠다"고 약속하고 싸게 산다. 그 구간을 타면 이득이지만, 이사를 가서 다른 노선을 타게 되면 무용지물이 된다.
Savings Plans = 1년치를 미리 채워둔 교통카드. "1년간 매달 이만큼은 쓰겠다"만 약속하고, 어느 노선을 타든 그 약정 금액 안에서 할인이 적용된다.
그래서 "약정은 하고 싶은데 나중에 구성이 바뀔 것 같다"는 뉘앙스가 보이면 Savings Plans 쪽으로 기운다.
한 가지 더 알아 둘 축이 선결제 방식이다. 약정할 때 돈을 언제 내느냐에 따라 셋으로 나뉜다.
선결제 방식
내용
할인 정도
전액 선결제(All Upfront)
약정 기간분을 한 번에 결제
가장 크게 할인
부분 선결제(Partial Upfront)
일부를 미리 내고 나머지는 매월
중간
선결제 없음(No Upfront)
매월 나눠서 결제
가장 적게 할인
원리는 간단하다. 돈을 먼저 낼수록 더 깎아준다. 이건 우리가 일상에서 연납 할인을 받는 것과 똑같은 논리다.
⚠️ 함정: 약정 할인은 돈을 아끼는 대신 유연성을 잃는 거래다. 1년 약정을 걸고 6개월 만에 서비스를 접으면 안 쓴 기간의 약정이 그대로 부담으로 남는다. 그래서 실무 순서는 항상 "온디맨드로 패턴 확인 → 확실히 상시로 도는 만큼만 약정"이고, 시험에서도 "이제 막 시작하는 워크로드에 3년 약정"은 오답 신호다.
사내 업무 시스템을 AWS로 옮긴 한 제조업체가 첫 달 청구서를 보고 놀랐다. 원인은 두 가지였다. 개발·테스트 서버를 밤과 주말에도 켜둔 것, 그리고 1년 내내 도는 것이 확실한 기간 업무 서버까지 전부 온디맨드로 돌린 것이었다. 이 회사는 개발 서버를 업무 시간 외에 자동으로 끄고, 24시간 도는 몫만큼만 약정으로 옮겼다. 새 기능을 만든 것도 서버를 줄인 것도 아니고 똑같은 자원을 다른 방식으로 산 것만으로 청구서가 눈에 띄게 줄었다. 비용 최적화의 첫 단계는 대개 이렇게 시시하다.
스팟 인스턴스는 AWS의 여유 컴퓨팅 용량을 경매처럼 헐값(온디맨드 대비 최대 약 90% 할인)에 빌려 쓰는 방식이다. 대신 AWS가 그 용량이 필요해지면 짧은 통보 후 인스턴스를 회수할 수 있다.
그래서 스팟은 중단돼도 괜찮은(fault-tolerant) 작업에만 어울린다. 배치 처리, 대규모 데이터 분석, 렌더링, CI 빌드처럼 중간에 멈췄다 다시 시작해도 되는 워크로드가 대표적이다. 결제 서버처럼 절대 끊기면 안 되는 상시 서비스에는 부적합하다.
[가격과 안정성의 트레이드오프]
온디맨드 : 비쌈, 언제나 보장
RI/SP : 약정, 보장 + 큰 할인
스팟 : 최저가, 회수될 수 있음(중단 허용 작업 전용)
"가장 저렴", "여유 용량", "중단돼도 괜찮은 배치/분석 작업"이 보이면 스팟이다. "중단되면 안 되는 상시 서비스"라면 스팟은 오답이다.
스팟을 가장 잘 설명하는 비유는 출발 직전 남은 항공권이다. 비어 있는 좌석은 이륙하는 순간 가치가 0이 되므로 헐값에라도 채우는 편이 낫다. 대신 그런 표에는 "정가 승객이 나타나면 자리를 내줄 수도 있다"는 조건이 붙는다. AWS의 여유 용량도 똑같아서, 정가로 쓰겠다는 수요가 생기면 회수해 간다. 그래서 스팟은 "멈춰도 다시 하면 그만인 일"에만 어울린다.
스팟에 어울리는 일
스팟에 어울리지 않는 일
밤새 돌리는 대용량 데이터 분석
결제·로그인 같은 상시 서비스
영상·이미지 렌더링 작업
세션 정보를 서버에 들고 있는 웹 서버
코드 빌드·테스트(CI) 작업
데이터베이스 본체
다시 실행하면 되는 배치 처리
중단 시 데이터가 유실되는 작업
함정: "가장 저렴한 방법을 고르시오"라는 문장만 보고 반사적으로 스팟을 고르면 틀린다. 문항에 "중단되면 안 된다", "상시 가용해야 한다", "미션 크리티컬"이 붙어 있으면 스팟은 즉시 오답이다. 반대로 "중단 허용", "재시작 가능", "배치 처리"가 있으면 거의 확정적으로 스팟이다.
여기까지가 "언제 얼마나 쓰느냐"에 따른 구분이었다면, 한 축이 더 있다. 하드웨어를 누구와 함께 쓰느냐다.
기본적으로 클라우드는 물리 서버 한 대 위에 여러 고객의 가상 서버가 함께 올라간다(격리는 보장된다). 그런데 소프트웨어 라이선스가 물리 코어 수 기준이라 어떤 물리 서버에서 도는지 특정해야 하거나, 규제상 하드웨어를 다른 조직과 공유할 수 없는 경우가 있다. 이때 쓰는 것이 전용 호스트(Dedicated Host)와 전용 인스턴스(Dedicated Instance)다.
구분
내용
전용 호스트
물리 서버 한 대를 통째로 배정받아 그 위를 직접 통제. 소켓·코어 단위 라이선스 대응에 쓴다
전용 인스턴스
하드웨어는 우리 계정 전용이지만, 물리 서버 자체를 들여다보고 배치하지는 않음
함정: "기존에 쓰던 소프트웨어 라이선스를 그대로 가져와야 한다(BYOL)", "물리 서버 단위로 라이선스를 계산해야 한다"는 단서가 나오면 정답은 전용 호스트다. 보안 때문이 아니라 라이선스 때문에 등장하는 선택지라는 점이 포인트다.
AWS 프리 티어는 신규 사용자가 비용 부담 없이 서비스를 체험하도록 제공하는 무료 한도다. 세 종류가 있다.
12개월 무료: 가입 후 12개월간 일정량 무료(예: EC2 t2.micro 월 750시간, S3 일정 용량).
상시 무료(Always Free): 기간 제한 없이 일정량 무료(예: Lambda 월 100만 요청, DynamoDB 일정 용량).
체험판(Trials): 특정 서비스를 짧은 기간 동안 무료로 사용.
"신규 사용자", "일정 한도까지 무료로 체험"이 보이면 프리 티어다. 한도를 넘으면 정상 과금되므로, 학습 중에도 사용량을 확인하는 습관이 중요하다.
프리 티어는 마트 시식 코너와 비슷하다. 맛만 보라고 주는 것이지 장을 대신해 주는 게 아니다. 그래서 실제로 공부하다 보면 걸리는 지점이 있다. 무료 대상은 특정 인스턴스 유형과 조건에 한정되어 더 큰 사양을 고르면 그 순간부터 과금이고, 한도는 월 단위로 계산되므로 서버를 두 대 켜면 그만큼 빨리 소진된다. 무엇보다 공부가 끝난 뒤 끄는 것을 잊은 리소스, 특히 붙여 놓은 디스크나 고정 IP처럼 눈에 잘 안 띄는 것들이 조용히 요금을 만든다.
그래서 학습을 시작할 때 가장 먼저 할 일은 예산 알림을 걸어두는 것이다. 일정 금액을 넘으면 메일이 오도록 해두면 "다음 달 카드값을 보고 알게 되는" 사고를 피할 수 있다(예산 도구는 다음 글에서 다룬다).
함정: 프리 티어는 할인 모델이 아니다. "운영 중인 서비스의 비용을 줄이려면?"이라는 문항에 프리 티어를 고르면 오답이다. 프리 티어는 신규 사용자의 체험·학습을 위한 무료 한도이고, 비용 절감 수단은 약정(RI·Savings Plans)이나 스팟, 사용하지 않는 자원 정리 쪽이다.
중단돼도 괜찮은가?
└ 예 ───────────────────────────► 스팟
└ 아니오 → 1년 이상 확실히 도는가?
└ 아니오 ──────────────────► 온디맨드
└ 예 → 유형·리전이 바뀔 수 있는가?
└ 예 ────────────────► Savings Plans
└ 아니오 ────────────► 예약 인스턴스(RI)
(물리 서버 단위 라이선스가 걸려 있다면 → 전용 호스트)
현실에서는 이 중 하나만 쓰지 않는다. 상시로 도는 만큼은 약정으로 깔고, 그때그때 늘어나는 몫은 온디맨드로 받고, 밤에 돌리는 분석은 스팟으로 처리하는 식으로 섞는다. 시험이 하나만 고르라고 하는 것은 단순화일 뿐이다.
예측이 불가능하면 온디맨드로 시작하고, 패턴이 잡혀 안정적이면 RI/Savings Plans로 약정 할인을 받고, 중단돼도 되는 작업은 스팟으로 최저가를 노린다. 프리 티어로 부담 없이 배우고, 사용량이 크면 볼륨 할인이 자동으로 단가를 낮춘다.