🔥 인스턴스 타입: CPU, 메모리, 네트워크를 함께 고르는 법

EC2를 띄우려고 콘솔의 인스턴스 타입 드롭다운을 처음 누르면, 약 700개의 옵션이 줄지어 뜬다. t3.nano부터 r8g.48xlarge까지, 영문자 한두 글자 뒤에 숫자가 붙고 그 뒤에 또 어떤 글자가 붙고, 마침표 뒤로 nano / micro / small / medium / large / xlarge / 2xlarge ... 48xlarge / metal이 따라붙는다. 처음 EC2 인스턴스 목록을 봤을 때, 700개가 어떤 기준으로 나뉘는지부터 막막했다. 사실 그 700개는 네 토막짜리 이름표 위에서 정렬한 한 표다.

EC2란 무엇인가: 가상 머신 추상화가 하는 일에서 EC2의 정의를 "다섯 이웃 위에 얹힌 가상 컴퓨터 한 대"로 두었다. 여기서 먼저 확인할 기준은 인스턴스 타입 이름을 읽는 법이다. 인스턴스 타입은 단순한 등급이 아니라 CPU·메모리·네트워크 비율의 한 묶음이고, 그 위에 T 가족 하나만 시간 변동성이라는 한 계층을 더 얹은 가족이다.

이름은 네 토막짜리 표다

m6i.large라는 이름 한 줄에는 네 가지 정보가 들어 있다. 앞에서부터 패밀리, 세대, 옵션, 크기다. m은 General Purpose 패밀리, 6은 6세대, i는 Intel 프로세서, large는 크기 한 단계다. 공식 문서는 이 네 칸을 Family, Generation, Options, Size라고 정의한다 (EC2 Instance Type Naming Convention, verified 2026-04-28). 이름은 Family, Generation, Options, Size 네 칸으로 읽는다.

왜 이렇게 네 토막으로 나눴을까. 한 차원에 한 결정이 매달려 있어서다. 패밀리는 워크로드 성격을 먼저 고르는 단계다. CPU가 먼저 부족한지, 메모리가 먼저 부족한지부터 나눈다. 세대는 연식이다. 6세대 m6i는 5세대 m5보다 같은 가격에 같은 vCPU 수를 주면서도 새 Intel Ice Lake 위에서 돌아간다. 옵션은 프로세서·스토리지·네트워크 변형을 한 자로 줄인 표시다. a는 AMD, g는 AWS Graviton(ARM), i는 Intel, n은 네트워크·EBS 강화, d는 인스턴스 스토어 부착, e는 추가 메모리(또는 추가 스토리지)다. 크기는 vCPU·메모리·네트워크 총량을 한 번에 두 배씩 키운 단계 표다.

예를 들어 c7gn.xlarge라는 이름은 한 줄에 다섯 가지 정보를 적어 둔다. Compute optimized, 7세대, Graviton, 네트워크 강화, 4 vCPU 크기다. 이름을 네 부분으로 나눠 읽으면 구조가 바로 드러난다.

패밀리 여섯 가족이 비율을 결정한다

서울 리전(ap-northeast-2)에서 가장 자주 마주치는 패밀리는 T, M, C, R, I, G 여섯 가지다. 각 가족은 vCPU 1개당 메모리·네트워크·디스크 비율이 다르다. 가족이 곧 비율의 이름이다.

• T (Burstable): 베이스라인 CPU + 가끔 튀는 워크로드용. 가장 싸다. 같은 vCPU·메모리 기준 M·C·R 가족보다 한 자릿수에서 두 자릿수 % 저렴하다 (On-Demand 가격에서 리전별 시점 가격 확인).
• M (General Purpose): vCPU:메모리 = 1:4. 한 가족만 골라야 한다면 이게 무난하다. m6i.large = 2 vCPU + 8 GiB RAM.
• C (Compute Optimized): 1:2. 같은 vCPU에 메모리는 절반. 컴파일·인코딩·CPU-bound 백엔드.
• R (Memory Optimized): 1:8. r6i.large = 2 vCPU + 16 GiB RAM. 캐시·인메모리 DB·Spark.
• I (Storage Optimized): NVMe 인스턴스 스토어 직결. ClickHouse / Cassandra / 로컬 디스크 IOPS 워크로드.
• G (Graphics intensive): 그래픽·렌더링·게임 스트리밍·일부 ML 추론. 현재 G4·G5·G6는 NVIDIA GPU 기반.

이 비율표를 머리에 한 번 넣어 두면 이름 한 줄로 워크로드를 거꾸로 추정할 수 있다. 동료가 "어제 r5.4xlarge에 Redis 띄워 놨어요"라고 하면, 16 vCPU + 128 GiB RAM 한 대를 캐시 전용으로 잡았다는 그림이 즉시 떠오른다.

내가 처음 헷갈렸던 곳은 "그러면 같은 vCPU 4개짜리인데 m6i.xlarge하고 c6i.xlarge는 뭐가 다른가" 하는 대목이었다. 메모리가 다르다. m6i.xlarge는 16 GiB, c6i.xlarge는 8 GiB다(m6i 사양, c6i 사양). 겉으로는 한 자릿수 퍼센트 차이처럼 보여도, 월말 비용표에서는 그 차이가 계속 늘어난다. 다만 정확한 가격은 시점과 리전에 따라 다시 확인해야 하므로 On-Demand 페이지에서 ap-northeast-2를 골라 확인한다. 메모리가 필요 없는 워크로드라면 c6i가 매번 결과적으로 싸다.

vCPU는 코어 수와 바로 같지 않다: 보통은 스레드 단위로 센다

가장 자주 새는 오해 한 가지를 짚고 가야겠다. vCPU 4개 = 물리 CPU 4코어가 아니다.

공식 문서 설명은 간단하다. vCPU는 기본적으로 하드웨어 스레드 기준으로 잡는다. "Each thread is represented as a virtual CPU (vCPU) on the instance" (CPU options for Amazon EC2 instances, verified 2026-04-28). Intel·AMD 프로세서는 SMT(simultaneous multithreading, 흔히 하이퍼스레딩)를 켠 상태라 물리 코어 1개 = 스레드 2개 = vCPU 2개다. 즉 m6i.xlarge의 vCPU 4개는 실제로는 물리 코어 2개다.

다만 두 가지 예외가 있다. 첫째, AWS Graviton은 ARM 기반이라 SMT를 쓰지 않는다. 그래서 vCPU 1개를 물리 코어 1개로 보면 된다. m6g.xlarge는 vCPU 4개가 실제 코어 4개다. 둘째, *.metal 인스턴스는 하이퍼바이저 자체를 통과해 물리 서버 한 대를 그대로 받는 형식이라 vCPU 수가 곧 물리 스레드 수와 일치한다.

이게 왜 매터링 하냐. 동등한 vCPU 수에서도 워크로드 성능이 다르게 나오기 때문이다. CPU-bound 워크로드를 m6i와 m6g에 같은 vCPU로 띄워 보면, m6g 쪽이 컨텍스트 스위치 오버헤드 없이 4코어 풀로 돌아가서 종종 더 매끄럽게 나온다. 반대로 메모리 대역폭이 좁은 ARM 워크로드라면 Intel/AMD가 유리할 수도 있다. 둘 중 하나를 늘 정답으로 둘 수는 없다. 같은 워크로드를 올려 놓고 청구서·지연·CPU 사용률 세 가지를 같이 봐야 한다.

옵션 글자 한 자가 바꾸는 게 단지 가격이 아니라 코어의 의미 자체라는 사실은, 처음 EC2를 잡을 때 나도 모르고 지나갔던 곳이다.

T 계열만 계산법이 다른 이유: CPU 크레딧 모델

지금까지 본 가족들(M, C, R, I, G)은 모두 vCPU 풀 시간 100%를 그대로 쓴다. 1시간을 빌리면 1시간 어치 CPU를 다 써도 추가 청구가 없다. T 가족은 그 약속이 다르다.

T 가족(T3, T3a, T4g)은 베이스라인 + 버스트 모델이다. 베이스라인이란 "이 인스턴스가 쉬지 않고 지속적으로 쓸 수 있는 CPU 비율"이다. 그 위로 튀는 시간은 CPU 크레딧 잔고를 깎아 가며 잠깐 100%까지 올라간다. 크레딧을 다 쓰면 처리 가능한 CPU 사용률이 베이스라인 수준으로 내려간다.

크기별 베이스라인이 공식 문서에 명시돼 있다 (Burstable Performance Instance CPU Credits and Baseline Utilization, verified 2026-04-28). T3와 T4g가 같다.

크기	vCPU	베이스라인	시간당 적립 크레딧	최대 누적
t3.nano	2	5%	6	144
t3.micro	2	10%	12	288
t3.small / medium	2	20%	24	576
t3.large	2	30%	36	864
t3.xlarge	4	40%	96	2304
t3.2xlarge	8	40%	192	4608

왜 5%, 10%, 20%처럼 값이 끊어지는지는 공식에 그대로 드러난다. 시간당 적립 크레딧을 vCPU 수로 나누고 그 값을 60분 기준으로 바꾸면 베이스라인 퍼센트가 나온다. t3.nano도 같은 식으로 계산하면 (6 / 2) / 60 = 0.05, 즉 5%가 그대로 나온다.

t3.medium 숫자를 한 번 끝까지 적어 두면 계산 흐름이 드러난다. 베이스라인 20%, vCPU 2개인 t3.medium을 12시간 동안 평균 CPU 5%로 돌리면 시간당 18크레딧((20% - 5%) × 2 vCPU × 60분 / 100)이 잔고에 추가로 들어간다. 잠깐 트래픽 스파이크가 와서 1시간을 100%로 튀면, 그 1시간에 (100% - 20%) × 2 vCPU × 60분 / 100 = 96 크레딧이 잔고에서 줄어든다. 며칠을 한가하게 쉬다 갑자기 한두 시간 튀는 워크로드면 T가 압도적으로 싸다. 반대로 베이스라인을 24시간 초과로 올리는 워크로드면 잔고가 항상 마른다. Unlimited 모드에서는 남은 크레딧을 다 쓴 뒤 초과분 비용을 따로 부과한다. T4g는 vCPU-시간당 $0.04, T3는 $0.05다(Linux 기준, Unlimited mode pricing, verified 2026-04-28).

T3·T3a·T4g는 기본값이 unlimited 모드라 잔고가 마르면 곧장 추가 요금이 붙는다. standard 모드로 바꾸면 잔고가 마른 시점부터 베이스라인까지만 쓰고 throttle된다. 어느 쪽이든 운영 의도에 안 맞게 들어가면 청구서 또는 지연이 한 번씩 나를 놀라게 한다.

그래서 언제 T를 안 써야 하는가

T 가족은 매력적이지만, 지속 부하가 베이스라인을 24시간 넘기는 서비스에는 두지 않는다. 프로덕션에서 트래픽이 들쭉날쭉한 게 아니라 항상 평균 30% CPU로 도는 백엔드면, t3.large(베이스라인 30%)에 띄우는 순간 unlimited 모드면 매일 추가 크레딧 청구가 늘어난다. standard 모드라면 크레딧이 바닥나는 순간 30%에서 곧바로 제한 구간으로 들어간다. 어느 쪽이든 m6i.large에 그냥 띄우는 것보다 비싸거나 느리다.

내가 작년에 한 번 데였던 케이스가 정확히 이 패턴이었다. 사이드 프로젝트라 t3.medium에 백엔드를 올려 두었는데, 트래픽이 늘면서 평균 CPU가 25%를 넘기 시작하니까 청구서에 매일 $1~2씩 CPU 크레딧 surcharge 항목이 붙었다. 한 달이 지난 뒤 m6i.large로 바꾸니 청구서는 비슷한데 지연이 절반으로 줄었다. 그때 메모를 한 줄 남겼다. 평균 CPU가 늘 높게 붙는 작업이라면 T를 기본 선택지에서 뺀다.

그래서 T 가족이 실제로 잘 맞는 곳은 두 갈래다. 첫째, 유휴 시간이 많고 가끔 튀는 사이드 프로젝트·CI 워커·개발 서버. 둘째, 베이스라인 안쪽으로 충분히 정착한 저트래픽 배치잡 / 스케줄러 / cron 호스트. 그 외에는 M·C·R로 가는 게 매번 결과적으로 싸고 안정적이었다.

서울 리전(ap-northeast-2)에서 고를 수 있는 가족

서울 리전에는 위 여섯 가족이 거의 다 풀 라인업으로 와 있다. General Purpose만 봐도 M4·M5·M5a·M5d·M6g·M6i·M7g·M7i·M8g·M8i 등 10세대 가까이 쌓여 있고, T 가족도 T2, T3, T3a, T4g를 모두 고를 수 있다 (Amazon EC2 instance types by Region, verified 2026-04-28). 단, AWS 신형 가속기 가족(Trainium·Inferentia 후속·일부 P 시리즈 변형)은 us-east-1·us-west-2에 먼저 도착한 뒤 서울에 늦게 합류하는 경향이 있어서, GPU/ML 학습 워크로드라면 작업 시점에 region 표를 한 번 더 확인하는 게 안전하다.

세대를 고를 때 고민은 하나로 줄어든다. 같은 워크로드라면 대개 최신 세대부터 확인하면 된다. 6세대(m6i) 대비 5세대(m5)는 같은 vCPU·메모리에서 가격이 5~15% 더 비싸거나 같다. 신규로 띄우는 인스턴스라면 m6i / c6i / r6i를 default로 두고, 그 위에 옵션(Graviton g, AMD a)을 붙일지 결정하는 순서가 가장 단순하다.

인스턴스 타입은 결정의 시작이지 끝이 아니다

여기까지 보면, 인스턴스 타입은 한 번 고르고 끝나는 라벨이 아니라 매시간 책임지는 비율 결정이다. 이름은 네 항목을 차례로 붙여 만든다. 패밀리는 워크로드 성격을, 세대는 연식을, 옵션은 프로세서나 네트워크 변형을, 크기는 총량을 뜻한다. 그리고 T 가족만 거기에 시간 변동성이라는 한 계층이 더 따라온다.

EC2란 무엇인가: 가상 머신 추상화가 하는 일에서 본 "관리형이 아니라는 사실이 매일 부과하는 5가지 작업" 가운데 하나가 사실은 이 결정이다. Lambda나 Fargate 같은 관리형으로 가면 인스턴스 타입을 고르는 판단을 아예 미룰 수도 있지만, 그만큼 비용과 성능을 세밀하게 맞출 여지는 줄어든다. 인스턴스 타입을 고른 뒤에는 AMI: 머신 이미지의 라이프사이클, EBS vs Instance Store: 디스크는 어디 붙어 있는가, Spot, On-Demand, Reserved: 세 가지 가격 모델을 각각 따로 확인하면 된다. 그리고 단원 끝에서 언제 EC2가 아닌 다른 걸 써야 하는가를 한 번 더 묻는다.

지금 내가 기본값으로 가장 자주 두는 선택은 m6i.large 한 대다. 2 vCPU + 8 GiB + 적당한 네트워크. 거기서 워크로드 성격에 따라 C·R·T·G로 변경한다. 결국 운영에서는 어떤 기준부터 먼저 정하느냐가 비용과 성능을 오래 끌고 간다.