AWS EC2 인스턴스 타입 고르기: 실전 가이드 (t/m/c/r/g·Graviton·Spot)

결론부터 말하면, 대부분의 워크로드는 t 계열이나 m 계열로 시작해서 필요할 때 c·r·g로 옮기면 됩니다. AWS EC2에는 수백 가지 인스턴스 타입이 있지만, 실무에서 매일 만지는 건 몇 개 패밀리뿐입니다. 처음부터 완벽한 타입을 고르려고 애쓸 필요 없어요. 작게 시작하고, CloudWatch 지표를 보고, 병목이 생기는 방향으로 옮기는 게 정석입니다. 나라면 신규 서비스는 예외 없이 t4g(Graviton)로 띄우고 한 달 지켜본 뒤 결정합니다.

몇 년 치 청구서를 직접 결제해 본 입장에서 말하자면, EC2 비용 사고는 타입을 몰라서가 아니라 “한 번 잡아놓고 잊어서” 생깁니다. 아래에서 패밀리 구분, 워크로드별 선택, 그리고 실제로 돈을 아끼는 세 가지 지렛대(Savings Plans·Spot·Graviton)를 순서대로 정리하겠습니다.

인스턴스 패밀리는 뭐가 다른가? (t·m·c·r·i·g)

인스턴스 타입 이름은 m7g.large 같은 식입니다. 앞 문자가 패밀리(용도), 숫자가 세대, g는 Graviton(arm), 뒤가 크기입니다. 문자만 읽을 줄 알면 절반은 끝납니다.

패밀리	성격	vCPU:메모리	대표 용도
t	버스터블(범용)	1:2~1:4	웹서버, API, 개발/테스트, 트래픽 튀는 소규모 서비스
m	균형형 범용	1:4	상시 부하 웹앱, 중간 규모 백엔드, 앱 서버
c	컴퓨트 최적화	1:2	배치 연산, 게임 서버, 인코딩, 고트래픽 API
r	메모리 최적화	1:8	인메모리 캐시, 대용량 DB, 분석, Redis/Elasticsearch
x	초대용량 메모리	1:16+	SAP HANA, 대형 인메모리 DB
i	스토리지(NVMe) 최적화	—	로컬 디스크 IO가 큰 DB, 로그 처리
g / p	GPU	—	ML 학습·추론, 영상 트랜스코딩

핵심은 vCPU:메모리 비율입니다. c는 CPU가 상대적으로 넉넉하고, r은 메모리가 넉넉합니다. 애플리케이션이 먼저 소진하는 자원 쪽으로 붙은 패밀리를 고르는 게 낭비를 줄이는 첫 단추입니다. 클라우드 플랫폼 자체를 고르는 큰 그림은 AWS·GCP·Azure 클라우드 호스팅 비교 글에서 이미 다뤘으니, 여기서는 AWS 안에서의 인스턴스 선택에 집중하겠습니다.

버스터블(t)과 고정 성능(m)의 차이는?

t 계열이 헷갈리는 이유는 “버스터블”이라는 개념 때문입니다. t 인스턴스는 평소 vCPU의 일부(baseline, 예: 20~40%)만 쓰고 남는 성능을 CPU 크레딧으로 적립합니다. 트래픽이 몰리면 크레딧을 태워 100%까지 순간적으로 올라가죠.

문제는 크레딧이 바닥날 때입니다. Unlimited 모드가 아니면 baseline으로 제한돼서, 겉보기엔 CPU가 40%인데 서비스가 느려지는 기묘한 상황이 벌어집니다. 그래서 판단 기준은 단순합니다.

• CPU 사용률이 톱니처럼 튄다 → t 계열이 이득
• CPU가 항상 60% 이상으로 꾸준하다 → m 계열이 이득 (t를 Unlimited로 굴리면 오히려 비쌈)

개발 환경, 사내 도구, 방문자가 몰렸다 빠지는 블로그·랜딩페이지는 t가 정답입니다. 반대로 상시 부하가 걸리는 결제·주문 API를 t로 버티려는 건 흔한 실수예요.

내 워크로드엔 뭘 골라야 하나?

패턴별로 정리하면 이렇습니다. 나라면 아래 표를 시작점으로 잡고 2주 지표를 본 뒤 조정합니다.

워크로드	1순위	이유
신규 웹서비스 / API	t4g	싸고 버스터블, 부족하면 갈아타면 됨
상시 부하 백엔드	m7g	균형 잡힌 범용, 예측 가능한 성능
배치·인코딩·게임서버	c7g	CPU 집약, 코어당 성능 우선
캐시·검색·대용량 DB	r7g	메모리 넉넉, OOM 방지
CI 러너 / 렌더링	c (Spot)	중단 허용, 대량 병렬
ML 추론	g (Spot/스케줄)	GPU 필요하지만 상시는 낭비
로그/시계열 DB	i	로컬 NVMe IO 성능

세대는 항상 최신을 쓰세요. m6보다 m7이, t3보다 t4g가 대체로 같은 값에 빠릅니다. 오래된 런치 템플릿을 그대로 두는 게 눈에 안 띄는 낭비의 1번입니다. 개발 팀을 새로 꾸리는 단계라면 이런 클라우드 기초를 팀 전체가 아는지도 중요한데, 관련해서 코딩 부트캠프 투자 대비 효과 글에서 실무 역량 이야기를 정리해 뒀습니다.

Graviton(arm)으로 바꾸면 진짜 싸지나?

네. 이건 요즘 EC2 비용 최적화의 가장 확실한 한 방입니다. Graviton은 AWS가 만든 arm 기반 프로세서로, 이름 뒤에 g가 붙습니다(t4g·m7g·c7g·r7g). 같은 급의 x86 대비 가격 대비 성능이 20% 안팎 좋다고 보면 됩니다. 그냥 타입만 바꿔도 청구서가 내려가는, 드문 공짜 점심이에요.

걸림돌은 딱 하나, 아키텍처 호환성입니다. 대부분의 인터프리터/런타임(Node·Python·Go·Java·Ruby)과 공식 도커 이미지는 이미 arm64를 지원합니다. 확인할 건 이 정도입니다.

• 컨테이너 이미지가 linux/arm64 멀티아치를 빌드하는가
• 네이티브 확장(C 확장 파이썬 패키지 등)이 arm 휠을 제공하는가
• 상용 모니터링·보안 에이전트가 arm을 지원하는가

이 세 가지만 통과하면 대부분 그대로 넘어갑니다. AI 코딩 도구로 Dockerfile 멀티아치 빌드나 마이그레이션 스크립트를 짜면 시간이 확 줄어드는데, 어떤 도구가 실무에 쓸 만한지는 Cursor·Copilot AI 코딩 도구 비교에서 정리해 뒀습니다.

비용 얼마나 아끼나? (Savings Plans·Spot·On-Demand)

인스턴스 타입만큼 중요한 게 구매 방식입니다. 같은 c7g라도 어떻게 사느냐에 따라 가격이 3~4배 차이 납니다.

구매 방식	할인	유연성	리스크	적합 워크로드
On-Demand	없음(기준가)	최고	없음	단기·불규칙·테스트
Compute Savings Plans	큼 (1·3년 약정)	높음(패밀리·리전 변경 OK)	약정 미달 시 손해	상시 켜두는 베이스라인
EC2 Instance Savings Plans	더 큼	낮음(패밀리 고정)	유연성 낮음	완전히 고정된 코어
Spot	최대 70~90%	낮음	2분 후 회수 가능	중단 허용 배치·워커

실무 전략은 레이어링입니다. 항상 떠 있는 베이스라인 용량은 Savings Plans로 커밋해 할인받고, 변동 트래픽은 On-Demand로, 중단돼도 괜찮은 부분은 Spot으로 채웁니다. 오토스케일링 그룹의 Mixed Instances Policy를 쓰면 On-Demand와 Spot 비율을 정책으로 섞을 수 있어요. 처음엔 Cost Explorer의 Savings Plans 추천값을 보고 보수적으로(예: 70% 커버리지) 커밋하는 걸 권합니다.

원화 관점에서 하나 더. 서울 리전을 쓰더라도 청구는 달러 기준이라 환율이 곧 비용입니다. 클라우드 비용은 하나의 ‘달러 표시 고정비’로 보고 관리하는 게 맞습니다. 참고로 소규모 사이트라면 EC2를 직접 굴리기 전에 관리형 호스팅으로 충분한 경우도 많은데, 그 판단 기준은 웹사이트 빌더 비교에서 정리해 뒀습니다.

흔한 실수는? (실패 사례)

실제로 많이 밟는 지뢰를 하나의 상황으로 묶어 보겠습니다.

사례: 서울에서 스타트업이 청구서에 놀란 날. 한 팀이 프로덕션을 m5.2xlarge 온디맨드 4대로 올렸습니다. 트래픽은 낮 시간대에만 몰리는데 밤새 4대가 그대로 돌았고, CPU 평균은 15%였습니다. 게다가 CI 러너까지 같은 온디맨드 인스턴스로 상시 켜뒀죠. 문제를 정리하면:

1. 과다 프로비저닝 — CPU 15%면 두 단계는 내릴 수 있었습니다. Compute Optimizer가 이미 m7g.large를 추천하고 있었죠.
2. Spot 미사용 — CI 러너는 중단돼도 재시작하면 그만인데 온디맨드로 굴려 돈을 태웠습니다.
3. 구세대·x86 고집 — m5(x86)를 m7g(Graviton)로만 바꿔도 20% 가까이 절감됐습니다.
4. 약정 없음 — 1년 내내 켜둘 베이스라인인데 Savings Plans를 안 걸었습니다.

이 네 가지만 고치니 월 비용이 절반 아래로 내려갔습니다. 특별한 마법이 아니라, 최신 세대 + Graviton + 적정 크기 + 베이스라인 약정 + 변동분 Spot이라는 기본기를 지켰을 뿐입니다. 인프라를 원격으로 운영하는 팀이라면 이런 비용 리뷰를 정기 루틴에 넣어야 하는데, 분산 팀 운영의 리듬은 원격근무 잡 가이드에서 정리한 원칙과 통합니다.

매달 챙겨봐야 할 것

인스턴스 타입은 한 번 정하고 끝이 아니라 정기적으로 재검토하는 대상입니다. 나라면 매달 이 다섯 가지를 봅니다.

• Compute Optimizer 추천 — 과다/과소 프로비저닝 인스턴스 목록
• Savings Plans 커버리지·활용률 — 약정이 놀고 있진 않은지
• Spot 중단율 — 특정 타입 회수가 잦으면 후보 타입을 넓히기
• 세대 갱신 — 신세대가 나오면 벤치 후 교체 검토
• 리전 배치 — 지연 무관 워크로드가 비싼 리전에 남아있지 않은지

클라우드 인프라 비용은 결국 주식처럼 ‘포지션 관리’에 가깝습니다. 성장주에 장기 투자하듯 베이스라인은 약정으로 잠그고, 단기 변동은 Spot으로 유연하게 받는 식이죠. 이런 자원 배분 사고방식은 AI 관련주 투자 가이드에서 다룬 포트폴리오 논리와 놀랄 만큼 닮아 있습니다.

정리하면, 작게 시작하고, 지표를 보고, Graviton·Savings Plans·Spot 세 지렛대를 순서대로 거는 것. 이 습관 하나가 EC2 청구서를 가장 크게 바꿉니다.

이 글은 정보 제공을 목적으로 하며, 특정 아키텍처나 구매 방식을 권유하지 않습니다. AWS 요금과 인스턴스 사양은 수시로 바뀌므로 실제 비용은 반드시 AWS 공식 요금 페이지와 본인 계정의 Cost Explorer에서 확인하시기 바랍니다.