봄봄 AWS 비용 다이어트 이야기

 

봄봄의 상황

현재 봄봄은 300명이 넘는 회원이 쓰고 있는 서비스다.
“우테코 끝나면 이거 그냥 접는 거 아니야?”라는 질문을 여러 번 들었는데,
처음 기획할 때부터 우리 팀의 목표는 분명했다.

“실험용 토이 프로젝트 말고, 진짜 계속 운영하는 서비스 한 번 만들어보자.”

 

처음 합을 맞출 때도 그 얘기를 했고,
우테코가 거의 끝나갈 즈음에 내가 다시 한 번 팀원들에게 물어봤다.

“진짜야? 우테코 끝나도 이거 계속 한다?”

 

그리고 모두가 “당연하지” 쪽에 손을 들어줬다.

그런데 한가지 문제가 있다.

 

바로 우리 서비스는 아직 수익이 없다는 점이다.
수익 모델에 대한 아이디어는 몇 가지 가지고 있지만, 거기까지 가려면 아직 시간이 꽤 걸린다.

그 전까지는, 말 그대로 버티는 힘이 중요하다.

 

버티려면 결국 고정비용을 줄여야 한다.
매달 나가는 돈이 적어야, 서비스는 오래 살아남을 수 있다.
(카드값이 가벼워야 마음도 가볍다…)

 

사실상 봄봄의 고정비 대부분은 AWS 서버 비용이다.
도메인, S3 같은 것도 있지만, 진짜 돈을 쓰는 곳은 EC2, RDS 같은 인프라 쪽이다.

(아 물론 도메인 비용은 내년부터 5만원이다 ㅜㅜ)

도메인 더 싼걸로 할껄

 

팀원들과 논의한 결과, 봄봄의 서버 운영 예산은

한 달에 2만 원 초반대,
7명이기에 14만 ~ 17만 원 수준으로 잡았다.

 

단순히 이 예산 안에만 맞추는 게 아니라,
나중에 서비스가 더 커졌을 때도 유지 가능한 구조를 만들고 싶었다.
그래서 “지금 줄일 수 있는 건 최대한 줄여 놓자”는 방향으로 정리했다.

 

1. 서버비 줄이기

앞서 말했지만 AWS 서버 비용이 대부분이라 이 부분을 최대한 줄여야했다.  

 

그 중에 첫 번재 방법은 인스턴스 스펙 낮추고 Gravition으로 옮기기다.

 

 

1. 인스턴스 스펙 낮추기 / Graviton으로 옮기기

현재 대부분의 서버가 t4g.nano, t4g.micro처럼 최소 사양으로 운영되고 있다.

처음부터 Graviton(ARM 기반) 인스턴스를 선택한 것도 같은 이유다.
동일한 성능 대비 비용이 훨씬 저렴하기 때문에, 별도의 구조 변경 없이도 고정비를 크게 줄일 수 있는 선택지였다.

간단히 말해, ARM으로 전환하고 스펙을 낮추는 것만으로도 매달 나가는 서버비를 확실히 줄일 수 있었다는 것이다.

 

인스턴스	vCPU	메모리	아키텍처	시간당 요금(USD)	월 요금(약 730h)
t2.micro	1	1GB	x86	$0.0128/h	$9.34/월
t3.micro	2	1GB	x86	$0.0104/h	$7.59/월
t4g.micro	2	1GB	ARM(Graviton)	$0.0084/h	$6.13/월

 

 

왜 굳이 x86을 고집하지 않기로 했을까?

EC2 인스턴스를 고를 때 예전에는 아무 생각 없이 t2, t3 같은 x86 계열부터 보는 게 자연스러웠다.

“서버 = 인텔(x86)”이라는 인식이 워낙 강했기 때문이다.

하지만 봄봄 인프라를 설계하면서는, 굳이 x86을 계속 써야 할 이유가 없다고 판단했다.

오히려 ARM(Graviton)을 쓰는 쪽이 더 합리적이었다.

 

그 이유는 아래와 같다.

1) ARM은 더 이상 ‘실험용’이 아니다

예전 ARM은 라즈베리파이, 스마트폰 같은 저전력 디바이스 느낌에 가까웠다.
“운영 서버에 쓰기엔 아직 부족하지 않을까?” 하는 이미지가 강했다.

하지만 이제는 상황이 완전히 다르다.

• AWS가 Graviton2, Graviton3, Graviton4까지 계속 밀어주고 있고
• 공식 벤치마크에서도 “같은 돈이면 더 좋은 성능, 같은 성능이면 더 싼 비용”이라는 메시지를 강하게 이야기한다.
• 실제로 EC2 요금표만 봐도, 같은 급에서는 x86보다 Graviton(t4g 계열)이 더 싸다.

즉, ARM은 더 이상 특이한 선택”이 아니라,안 쓰면 오히려 손해일 수 있는 기본 옵션에 가깝다.

 

2) 우리가 사용하는 스택은 ARM에서 전혀 문제 없다

봄봄의 백엔드는 전형적인 웹 서비스 스택이다.

• Java
• Spring Boot
• Docker 컨테이너
• MySQL등 오픈소스들

이 조합은 이미 수많은 회사에서 Graviton 위에서 정상적으로 운영되고 있고,
도커 이미지도 arm64 빌드만 추가해주면 된다.

특별한 네이티브 x86 바이너리를 쓰는 것도 아니라서,
“x86이라서만 되는 무언가”가 우리 서비스에는 없다.

그래서 “굳이 x86을 써야 한다”는 기술적인 이유가 거의 없다.

3) 가격만 놓고 보면 x86을 선택하기가 더 어렵다

단순히 요금만 놓고 보면 선택은 더 명확해진다.

• 같은 vCPU/메모리 기준으로
  t2/t3(x86) < t4g(ARM) 순서로 나란히 놓고 보면
  대부분 t4g가 더 싸다.
• 심지어 우리가 쓰는 구간처럼, nano / micro / medium 같이 작은 스펙에서는
  t4g가 사실상 최저가 라인에 가깝다.

즉, 현재 봄봄처럼 “어떻게든 고정비를 줄여야 하는” 상황에서
굳이 더 비싼 x86을 선택하는 건, 이유 없는 사치에 가깝다.

정리

그래서 인스턴스를 고를 때 우리는 이렇게 스스로에게 물었다.

“지금 이 서비스는 정말 x86을 써야만 하는 이유가 있나?”

그리고 내린 결론은 단순했다.

• 기술적으로도 ARM이 충분히 안정적이고
• 가격은 ARM이 더 싸고
• 우리가 사용하는 스택은 ARM에서 아무 문제 없고
• 개발 환경도 이미 ARM이 일상인 시대다.

그래서 봄봄은 굳이 x86을 고집하지 않고, 처음부터 Graviton(t4g) 인스턴스를 기본 선택지로 가져가는 쪽을 택했다.
이 선택 하나만으로도, 똑같이 서버를 돌리면서 매달 나가는 돈을 꽤 크게 줄일 수 있었다.

그렇다면 인스턴스 타입은 왜 t 시리즈(버스터형)로 했을까? 

그전에 인스턴스 타입에 대해 간단하게 알아보자

 

EC2를 아주 단순하게 말하면

“클라우드 위에 빌려 쓰는 컴퓨터”

인데, AWS가 여러 용도에 맞게 미리 스펙을 나눠둔 PC 세트를 만들어 둔 거라고 보면 된다.

• 어떤 건 싸고 가볍게 쓰는 용도 (T)
• 어떤 건 균형 잡힌 기본형 (M)
• 어떤 건 CPU 빡세게 돌리는 용도 (C)
• 어떤 건 메모리(RAM) 엄청 많이 쓰는 용도 (R)

이렇게 4개만 먼저 머릿속에 넣어두면 훨씬 편해진다.

 

T 시리즈 - 가끔만 힘 쓰는 가성비형

ex) t4g.nano, t4g.micro ...

 

평소엔 조용히 돌아가는 경차지만 필요할 때 잠깐 터보 버튼 눌러서 쎄게 달리는 느낌이라고 생각하면 편하다.

 

평소에 CPU 사용량이 낮을 때 아주 싸게 쓸 수 있고 짧은 순간 트래픽이 확몰료도, 잠깐은 높은 CPU 성능으로 버스트가 가능하다.  

만약 무제한 모드라면 CPU를 계속 일정 기준치 이상으로 쓴다면 그만큼 비용을 내야한다. 

 

그래서 사이드 프로젝트나, 개인 서비스,  소규모 서비스, 하루 종일 빡세게 돌리진 않는데 가끔 잠깐 바빠지는 서비스에 어울린다.  

 

M 시리즈 - 범용 인스턴스

 ex) m6g.large, m7g.medium

 

회사에서 주는 기본 사무용 PC 느낌이다.

 

CPU와 메모리가 적당히 균형 잡혀있다. 

T처럼 버스트 크레딧 이런 거 없기에 CPU를 80%, 90%를 써도 추가 요금이 붙지 않는다.  

 

그렇다면 언제 쓰면 좋을까?

- 본 서비스용 API, 웹 서버

- 소규모/중간 정도 DB 서버 

 

3. C 시리즈 – “근육 많은 운동선수형” (컴퓨팅 최적화)

예: c7g.large, c7g.xlarge …

 

“생각하는 시간 말고, 연산은 내가 다 때려박는다” 타입

 

특징으로는 같은 가격이라면 CPU 코어 수가 더 많고, 메모리는 M 시리즈보다 상대적으로 적은 편이다.

게다가 계산/연산이 많은 작업에 최적화되어 있다.

 

이건 언제쓰면 좋을까? 

• 배치 작업, 로그/데이터 처리
• 통계 집계, 랭킹 계산, 추천 알고리즘 등 CPU를 많이 쓰는 코드
• 트래픽이 많고, 요청당 계산이 많은 API 서버

---

4. R 시리즈 – “메모리 빵빵한 서버” (메모리 최적화)

예: r6g.large, r7g.large …

 

비유하자면 램 64GB, 128GB 달린 고급 사무용 PC이라고 생각하면 좋다.

엑셀, IDE, 크롬 탭 50개 켜도 멀쩡한 컴퓨터 느낌??

 

특징으로는 같은 세대 기준으로 CPU 개수는 M과 비슷하지만 대신 메모리가 훨씬 더 많다.

하지만 메모리 많이 주는 만큼 가격도 M보다 비싸다.

 

언제쓰면 좋을까?

• DB 서버(MySQL, PostgreSQL 등)
  • InnoDB 버퍼 풀 크게 잡아서 디스크 I/O 줄이고 싶을 때
• Redis / Memcached 같은 캐시 서버
• 검색/분석 서버
  • (Elasticsearch, OpenSearch 등 인덱스를 메모리에 많이 올려두고 싶은 경우)

 

이를 바탕으로 생각해보았을 때 

세 가지 이유 때문에 t시리즈를 선택했다. 

 

1. 필요한 최소 사양이 T 시리즈에만 있었다

우리가 실제로 쓰고 싶었던 낮은 등급(nano, micro, small) 은 T 시리즈에만 존재했다.
반대로 M, C, R 같은 다른 패밀리는 대부분 medium 또는 large부터 시작한다.

하지만 이제 막 서비스를 시작한 입장에서,
애초에 트래픽이 거의 없기 때문에 medium, large 급을 쓸 이유가 없다.
지금 시점에서 그런 스펙을 선택하는 것은 완전히 오버 스펙이다.

그래서 “일단 가장 작은 단위로 시작하자”는 관점에서,
선택지는 자연스럽게 T 시리즈로 좁혀졌다.

 

2. 비용

두 번째 이유는 비용이다.

T 시리즈는 CPU 버스트(짧은 시간 높은 CPU 사용)만 자주 일어나지 않는다면,
같은 세대의 다른 인스턴스 타입에 비해 더 저렴하게 사용할 수 있다.

 

지금처럼 트래픽이 크지 않고,
CPU를 계속 50~80% 이상 사용하는 구조가 아니라면,
굳이 M이나 C처럼 “항상 일정 성능이 보장되는 인스턴스”를 쓸 필요가 없다.

 

성능도 중요하지만 지금 그만큼의 성능도 필요없다. 

 

3. 실제 CPU 사용량이 T 시리즈에 딱 맞는다

마지막으로, 실제 CPU 사용량 데이터가 T 시리즈 선택을 뒷받침한다.

CloudWatch 그래프를 보면,
대부분의 시간 동안 인스턴스의 CPU 사용률이 5% 미만이다.

• 평소에는 거의 놀고 있고
• 가끔 트래픽이 생기더라도 잠깐 버스트로 커버 가능한 수준이다.

즉, 현재와 가까운 미래의 트래픽을 고려했을 때
항상 높은 성능을 유지하는 인스턴스보다,
평소에는 가볍게 돌다가 필요할 때만 잠깐 힘을 쓰는 버스트형인 T 시리즈가 더 잘 맞는다고 판단했다.

 

 

 

이를 통해 월 약 $3.21 절감 → 연 $38.5 절감을 할 수 있다.  

---

2.  Saving plans 구매하기

AWS에서 EC2를 쓰면 기본은 온디맨드(On-Demand) 요금제다.
딱 쓴 만큼만 과금되고, 약정도 없다. 대신 가장 비싸다.

AWS는 여기에 “장기 고객”을 위한 할인을 하나 더 얹어준다.
그게 바로 Savings Plans다.

이걸 아주 단순하게 말하면:

“앞으로 1년(또는 3년) 동안,
매시간 최소 얼마어치는 꼭 쓸게요”
라고 약속하는 대신
온디맨드보다 싸게 쓰게 해주는 제도다.

여기서 중요한 포인트는 두 가지다.

1. 기간 약정: 1년 또는 3년
2. 금액 약정: “시간당 얼마만큼은 무조건 쓴다”라는 사용량 약속

예를 들어 “시간당 0.02 USD어치는 항상 쓸게요” 라고 1년 약정을 하면,

해당 금액까지는 할인된 요금(Savings Plans 요금)이 적용되고,
그걸 넘어가는 사용량은 기존 온디맨드 요율로 계산된다.

 

2. Reserved Instances랑 뭐가 다를까?

비슷한 개념으로 Reserved Instances(RI)도 있다.
둘 다 “장기 약정 + 할인”이라는 점은 같지만, 성격이 조금 다르다.

아주 대충 정리하면

• Reserved Instances
  • 특정 인스턴스 타입, 리전, OS 등에 꽤 딱 맞게 묶인다.
  • “서울 리전의 t3.medium Linux, 1년” 이런 식.
• Savings Plans
  • 좀 더 유연하게 쓸 수 있다.
  • 특히 Compute Savings Plans 는 Fargate, Lambda까지 적용 가능.

가격도 직접 비교해보았을 때 Savings Plans랑 같거나 거의 비슷한 수준이라서 유연성이 높은 Savings Plans을 사용하기로 했다.

3. Savings Plans의 종류

Savings Plans는 크게 두 종류가 있다.

1. Compute Savings Plans
   • 가장 유연하다.
   • EC2 인스턴스 타입이 바뀌어도, 리전이 바뀌어도, Lambda/Fargate를 써도 할인 적용.
   • 그만큼 할인율은 조금 낮다. (2025년 12월 기준으로 약 30%정도 된다)

1. EC2 Instance Savings Plans
   • 특정 인스턴스 패밀리(예: t4g, m6g) + 리전에 묶인다.
   • 예) ap-northeast-2(서울) 리전의 t4g 패밀리
   • 대신 Compute Savings Plans보다 할인율이 더 높다. (2025년 12월 기준으로 약 40%정도 된다)

 

우리 서비스는 1년안에  ec2 인스턴스 타입이 바뀔 확률이 낮고 리전은 추가하면 추가했지 절대 바뀌지 않고 Lambda/Fargate도 사용량이 많지 않을 것이라 판단해 할인율이 더 높은 EC2 Instance Savings Plans을 구매했다.

 

4. 어떻게 할인되는 건가요?

Savings Plans를 구매하면, AWS는 매 시간마다 이런 식으로 계산한다.

1. 이 계정에 걸린 Savings Plans 약정 금액을 확인한다.
   예: “시간당 0.02 USD 약정”
2. 현재 이 계정에서 실제로 사용 중인 리소스 비용을 확인한다.
   예: “이번 시간 EC2 비용이 0.018 USD 나왔네?”
3. 약정 금액(0.02 USD) 안에서 커버 가능한 usage에 대해서
   할인 요금(Savings Plans 요율)을 적용한다.
4. 만약 실제 사용량이 약정을 넘으면(예: 0.03 USD 썼다),
   약정 금액까지는 할인 요금,
   그 이상은 기존 온디맨드 요율로 과금된다.

즉,

• 약정 금액 이하로 쓰면 → 전부 할인
• 약정 금액 이상으로 쓰면 → 약정 구간까지만 할인, 나머지는 온디맨드

그래서 약정을 걸 때,
너무 높게 잡으면 손해고,
너무 낮게 잡으면 “할인을 더 받을 수 있었는데”가 된다.

 

5. Savings Plans를 사기 전까지

세이빙 플랜을 사기 전, 봄봄의 EC2 사용 상황은 대략 이랬다.

 

봄봄에서 사용하는 인스턴스는 아래와 같다.

• t4g.micro 3대 (prod1, prod2, email)
• t4g.nano 3대 (lb 2대 + nat gatway 1대)
• t4g.medium 1대 (monitoring)
• t2.micro 1대 (dev) - 프리티어

이렇게 총 8대의 EC2 인스턴스를 24시간 돌리고 있었다.

이 상태에서 전부 온디맨드 요금으로만 계산하면 한 단 기준으로 EC2 비용만 대략 8~9만 원 정도가 나온다.  

즉, 그냥 아무 생각 없이 온디맨드로만 1년을 버틴다라고 가정하면  1년 동안 EC2만 100만 원 가까이 나가는 구조였다. 

 

우리는 Cost Explorer로 지난 몇 달간의 사용량을 쭉 보면서 트래픽이 갑자기 10배 튈 것 같지는 않고, 지금 구성도 이미 "최소한으로 쳐낸 인프라"에 가깝고 1년 동안은 최소 이 정도 인스턴스는 무조건 돌릴 수 밖에 없다는 걸 확인했다. 

 

그래서 "무조건 쓸 수 밖에 없는 최소 구간"만큼은 온디맨드로 돈을 태우지 말고, EC2 Savings Plans 1년 약정으로 묶어버리기로 했다. 

어차피 앞으로 확장 계획도 있기에 적어도 이것보다는 많이 쓸 것 같았고 같은 t4g에서 언제든 다른 타입으로 바꿀 수 있기에 걱정이 없었다.

6. 왜 지금 이 타이밍에 약정을 걸었나

Savings Plans는 “돌이키기 힘든 결정”이라,
초기에는 나도 꽤 고민을 많이 했다.

• 혹시 몇 달 뒤에 서비스를 접게 되면 어떡하지?
• 인스턴스 타입을 전면 교체해야 할 상황이 오면 어떡하지?
• 트래픽 패턴이 완전 바뀌어 버리면 어떡하지?

그래서 우리는 다음 기준을 세웠다.

1. 팀원 전원이 “앞으로 1년은 최소한 운영해보자”에 동의할 것
2. 현재 인프라 구성이 “최소치에 가깝다”고 판단될 것
3. 약정 금액은 앞으로도 고려해서 80% 정도 수준으로 잡을 것

이 기준을 만족한 시점에서,
우리는 “이제는 약정을 걸어도 되겠다”고 보고
EC2 Savings Plans 1년을 구매했다.

 

총합 53.5$ 

 

이를 통해 한 달에 약 21.4$ 절감 -> 연 256.8$을 절감 할 수 있다.

 

---

3. NAT Gateway 비용 줄이기

곧 출시

 

4. ALB 대신 직접 로드밸런서 구성하기

 

곧 출시