EC2 인스턴스 패밀리 선택 기준: t·m·c·r 비교

인프라 AWS 비용
6 분 소요

EC2 인스턴스 타입은 800종을 넘지만, 선택은 두 단계로 좁혀집니다. “어느 패밀리인가"와 “어느 크기인가"입니다. 이 글은 첫 단계인 패밀리 선택 기준을 정리합니다. 결론을 먼저 적으면, 기본값은 최신 세대 m 계열이고, CPU나 메모리 한쪽으로 쏠린 실측 근거가 있을 때만 c나 r로 옮깁니다. t는 싸 보이지만 조건이 맞을 때만 싼 타입입니다. 사양 표기를 읽는 일반론은 하드웨어 기초 #9에서 다뤘고, 여기서는 AWS 쪽 선택 기준에 집중합니다. 요금은 us-east-1 온디맨드 기준입니다.

이름 읽는 법: 패밀리, 세대, 속성 #

m8g.large는 세 부분으로 나뉩니다. 첫 글자 m이 패밀리(용도), 숫자 8이 세대, 뒤에 붙는 글자가 속성입니다. 속성 글자는 몇 개만 알면 대부분 읽힙니다.

  • g: AWS Graviton(ARM) 프로세서입니다. m8g, c8g, r8g가 현행 세대입니다.
  • i: Intel입니다. m8i, c8i(Xeon 6)가 최신이고, m7i가 널리 정착된 세대입니다.
  • a: AMD EPYC입니다. 같은 세대 Intel보다 약 10% 저렴하게 책정됩니다.
  • d: 로컬 NVMe SSD가 달려 있습니다. 인스턴스를 세우면 데이터가 사라지는 임시 디스크입니다.
  • n: 네트워크 대역폭 강화판입니다.
  • -flex: 같은 세대 표준형보다 약 5% 싸고, 상시 최대 성능이 필요 없는 워크로드용입니다.

세대 숫자는 클수록 새롭고, 같은 패밀리에서 세대만 올려도 요금이 같거나 낮아지면서 성능이 올라가는 경우가 대부분입니다. m5에서 m7i나 m8g로 가는 결정은 사실상 비교가 필요 없는 업그레이드입니다.

t 패밀리: 버스트 모델이 맞는 조건 #

t4g와 t3는 CPU를 베이스라인만큼만 상시 보장하고, 나머지는 크레딧으로 쓰는 모델입니다. 베이스라인은 크기별로 다릅니다. t3.micro는 vCPU의 10%, t3.small과 t3.medium은 20%, t3.large는 30%입니다. 유휴 시간에 크레딧이 쌓이고 바쁠 때 소진하는 구조라, 평균 사용률이 베이스라인 아래인 워크로드에서만 표시 요금이 실제 요금이 됩니다.

맞는 곳은 명확합니다. 개발·스테이징 서버, 트래픽이 낮은 관리용 도구, 하루 몇 번 몰리는 배치의 대기 시간이 긴 경우입니다. t4g.micro가 시간당 약 $0.008로, 같은 크기 t3(약 $0.010)보다 쌉니다.

어긋나는 곳도 명확합니다. CPU가 베이스라인을 상시 넘는 서비스입니다. 크레딧이 마르면 성능이 베이스라인으로 잘리고, 기본 활성화된 unlimited 모드에서는 잘리는 대신 초과분 과금이 붙습니다. 초과 과금이 이어지면 같은 크기 m 계열보다 비싸집니다. “며칠은 멀쩡했는데 갑자기 느려졌다"가 EBS에서는 gp2 크레딧 소진이었다면(gp3 vs io2 참조), EC2에서는 t 크레딧 소진입니다. CPUCreditBalance 지표가 바닥을 치는 그래프가 보이면 t 계열을 벗어날 때입니다.

m·c·r: vCPU 대 메모리 비율이 기준입니다 #

m, c, r은 같은 크기에서 vCPU 수가 같고 메모리만 다릅니다. 비율이 곧 용도입니다.

타입vCPU메모리비율시간당 요금프로파일
c8g.large24GiB1:2약 $0.080연산 위주
m8g.large28GiB1:4약 $0.090범용
r8g.large216GiB1:8약 $0.118메모리 위주

읽는 방향은 요금표가 아니라 실측입니다. CPU 사용률은 높은데 메모리가 절반 이상 놀면 c로, 메모리는 차는데 CPU가 놀면 r로 옮깁니다. c는 웹·API 서버, 빌드·CI, 인코딩, 게임 서버가 해당하고, r은 인메모리 캐시(Redis, Memcached), 대형 JVM 힙, 분석 워크로드가 해당합니다. 어느 쪽인지 확신이 없으면 m에서 시작해 실측으로 판정합니다. 같은 메모리를 기준으로 보면 차이가 더 선명합니다. 16GiB가 필요할 때 r8g.large(2vCPU)는 약 $0.118, m8g.xlarge(4vCPU)는 약 $0.180입니다. CPU가 놀고 있다면 r이 같은 메모리를 3분의 2 가격에 제공합니다.

한 가지 주의할 점은 크기를 정할 때 CPU·메모리만 보면 안 된다는 것입니다. 인스턴스 크기에는 네트워크 대역폭과 EBS 대역폭·IOPS 한도가 함께 묶여 있습니다. 작은 인스턴스에 고성능 gp3를 걸어도 인스턴스 한도에서 잘리는 문제는 gp3 vs io2에서 다뤘습니다.

아키텍처 축: Graviton, Intel, AMD #

패밀리와 별개로 아키텍처 축이 있습니다. 같은 m8 세대에서 Graviton(m8g)이 Intel(m7i·m8i) 대비 시간당 요금이 약 10% 낮고, 세대 성능 향상까지 겹치면 가격 대비 성능 차이는 더 벌어집니다. m8g.large가 약 $0.090, m7i.large가 약 $0.101입니다. AMD(a)는 Intel과 같은 x86이라 바이너리 호환이면서 약 10% 저렴한 중간 선택지입니다.

Graviton은 ARM이므로 전환 전에 확인이 필요합니다. 인터프리터 언어(Python, Node.js, Ruby)와 JVM은 대체로 그대로 옮겨지고, 네이티브 바이너리와 컨테이너 이미지는 ARM 빌드가 있는지 확인해야 합니다. 절감 폭 추정과 전환 체크리스트는 EC2 Graviton 전환에 정리했습니다. 신규 워크로드라면 Graviton을 먼저 검토하고, 막히는 의존성이 있을 때 x86으로 돌아오는 순서가 요금상 유리합니다.

나머지 패밀리는 필요가 명확할 때만 #

t·m·c·r 밖의 패밀리는 io2와 같은 성격입니다. 필요 조건이 명확할 때만 선택합니다.

  • x, u(고메모리): 비율이 1:16 이상으로, SAP HANA 같은 대형 인메모리 DB용입니다. r로 부족하다는 실측이 먼저입니다.
  • i, d(스토리지): 로컬 NVMe·HDD 밀도가 높은 계열로, 분산 DB나 검색 엔진처럼 로컬 디스크 IOPS가 병목인 경우입니다. 대부분의 워크로드는 EBS로 충분합니다.
  • p, g, inf, trn(가속): GPU·AI 가속기 계열입니다. 어느 쪽이 필요한지는 학습 서버와 추론 서버, GPU 서버는 무엇이 다른가에서 다뤘습니다.

선택 순서: 실측이 먼저입니다 #

  1. 현재 소비량을 잽니다: CloudWatch의 CPUUtilization으로 CPU 프로파일을 보고, 메모리는 기본 지표에 없으므로 CloudWatch Agent를 붙여서 잽니다. t라면 CPUCreditBalance도 함께 봅니다.
  2. Compute Optimizer를 켭니다: 무료이고, 실측 기반으로 과대·과소 프로비저닝과 추천 타입을 계정 단위로 뽑아 줍니다. 놀고 있는 인스턴스 정리는 상시 점검 목록과 겹치는 작업입니다.
  3. 패밀리를 정합니다: 평균 CPU가 베이스라인 아래로 낮고 간헐 부하면 t, 균형이면 m, 실측이 한쪽으로 쏠려 있으면 c나 r입니다.
  4. 아키텍처와 세대를 정합니다: Graviton 가능 여부를 먼저 확인하고, 세대는 특별한 이유가 없으면 최신을 고릅니다.
  5. 크기는 작게 시작해 올립니다: 크기 변경은 재부팅 한 번으로 끝나므로, 넉넉히 잡고 줄이지 못하는 쪽보다 작게 잡고 올리는 쪽이 쌉니다. 장기 운영이 확정되면 Savings Plans 약정으로 온디맨드 대비 요금을 더 내립니다.

정리 #

  • 타입 이름은 패밀리(용도), 세대, 속성(g=Graviton, i=Intel, a=AMD, d=로컬 NVMe)으로 읽습니다. 같은 패밀리라면 최신 세대가 기본값입니다.
  • t는 평균 사용률이 베이스라인 아래일 때만 싼 타입입니다. 크레딧 소진과 unlimited 초과 과금이 보이면 m으로 옮깁니다.
  • m·c·r은 vCPU 대 메모리 비율(1:4, 1:2, 1:8)이 기준입니다. 실측으로 CPU와 메모리 어느 쪽이 병목인지 본 뒤에 옮깁니다.
  • 같은 세대에서 Graviton이 x86보다 약 10% 저렴합니다. 신규 워크로드는 Graviton 먼저 검토가 요금상 유리합니다.
  • 크기는 CloudWatch와 Compute Optimizer 실측으로 정하고, 작게 시작해 올립니다. CPU·메모리 외에 네트워크와 EBS 한도도 크기에 묶여 있다는 점을 기억합니다.
X