들어가며
EC2 인스턴스를 처음 만들 때 누구나 한 번은 멈칫한다. t2, t3, m5, c5, r5, g4... 알파벳과 숫자로 가득한 목록 앞에서 "그냥 컴퓨터 한 대 빌리는 건데 왜 이렇게 많지?"라는 생각이 든다.
이 글은 그 질문에서 출발한다. 인스턴스 타입의 알파벳이 실제로 무엇을 의미하는지, 요금 모델 네 가지가 왜 동시에 존재하는지, 그리고 이 "타입을 고르는 행위" 자체가 온프레미스 서버 운영과 어떻게 다른지를 정리한다.
1. 인스턴스 패밀리: 알파벳은 CPU 대 메모리 비율이다
인스턴스 타입 이름은 m5.large처럼 패밀리 + 세대 + 크기로 구성된다. 여기서 패밀리(첫 글자)가 가장 중요한데, 이것이 가리키는 건 용도가 아니라 vCPU 대비 메모리의 비율이다.
패밀리 이름 vCPU : 메모리 용도
| M | 범용 (General Purpose) | 1 : 4 | 웹서버, 소규모 DB 등 균형이 필요한 대부분의 워크로드 |
| C | 컴퓨팅 최적화 (Compute Optimized) | 1 : 2 | 배치 처리, 게임 서버, 고성능 웹서버처럼 CPU가 병목인 작업 |
| R | 메모리 최적화 (Memory Optimized) | 1 : 8 | 인메모리 DB, 실시간 빅데이터 분석, Redis 같은 캐싱 서비스 |
| T | 버스트 가능 (Burstable) | 워크로드에 따라 가변 | 평소엔 CPU 사용량이 낮다가 가끔 튀는 워크로드 (소규모 웹, 개발 서버) |
| G / P | 가속 컴퓨팅 (Accelerated) | GPU 탑재 | 그래픽 렌더링·추론(G), 딥러닝 학습(P) |
실제 숫자로 보면 이 비율이 뚜렷하다. m5.large는 2 vCPU에 8GB(vCPU당 4GB)인 반면, r5.large는 같은 2 vCPU에 16GB(vCPU당 8GB)다. 같은 CPU 성능을 사면서 메모리만 두 배를 받는 구조다. C 패밀리는 반대로 메모리 비중을 줄이고 CPU 비중을 높인다.
T 패밀리는 이 축과는 다른 차원의 특수 케이스다.
CPU 크레딧을 평소에 적립해두었다가 순간적으로 몰아 쓰는 구조라, 대부분의 시간 동안 CPU를 조금만 쓰는 워크로드(트래픽이 간헐적인 소규모 서비스)에 유독 저렴하다. 다만 크레딧을 다 쓰면 성능이 기준선 아래로 떨어지므로, 상시 고부하 작업에는 맞지 않는다.
2. 왜 이렇게 잘게 나눴을까: 사용자 편의는 절반의 이유다
"CPU와 메모리 비율이 다른 서버를 골라 쓰게 하면 낭비가 줄어든다"는 것은 맞는 설명이지만, 이야기의 절반에 불과하다. 나머지 절반은 AWS의 하드웨어 사정에 있다.
AWS는 실제로 CPU 대 메모리 비율이 다른 물리 서버를 종류별로 구매해 데이터센터에 배치한다. 범용 서버, 컴퓨팅 특화 서버, 메모리 특화 서버, GPU가 장착된 서버가 각각 별도의 하드웨어 재고로 존재한다. 만약 AWS가 "인스턴스는 한 종류뿐"이라고 팔았다면, 메모리가 많이 필요한 고객은 쓰지도 않을 CPU까지 돈을 내며 큰 인스턴스를 빌려야 했을 것이고, GPU가 필요한 고객은 애초에 서비스를 이용할 수 없었을 것이다.
즉 인스턴스 패밀리 분화는 이미 이종으로 존재하는 하드웨어 재고를, 그 재고에 정확히 맞는 수요와 연결하는 상품화 전략에 가깝다. 사용자 입장에서는 낭비를 줄이는 것이고, AWS 입장에서는 각 하드웨어 재고를 정밀하게 판매하는 것이다. 같은 동전의 양면이다.
여기에 더해 생존의 문제도 있다. 인메모리 데이터베이스나 딥러닝 학습처럼 전용 하드웨어가 사실상 필수인 시장이 있다. 이런 시장에서 범용 서버 한 종류만 판다면 그 시장 자체를 처음부터 포기하는 것과 같다. R 패밀리와 G/P 패밀리는 편의 기능이 아니라 그 시장에 진입하기 위한 최소 조건이었던 셈이다.
(참고로 AWS는 이 다양화를 더 유리하게 만들기 위해 자체 설계한 Graviton(ARM) 칩까지 만들어, 같은 범용 서버도 인텔/AMD 대비 더 저렴한 가격대를 추가로 확보했다.)
3. 요금 모델 네 가지: 약정의 정도가 다를 뿐이다
인스턴스 타입이 "어떤 서버냐"의 문제라면, 요금 모델은 "얼마나 확실하게 쓸 거냐"의 문제다.
온디맨드(On-Demand)는 약정 없이 쓴 만큼 시간(또는 초) 단위로 낸다.
기준 가격이며, 나머지 셋은 전부 여기서 할인받는 방식이다. 예약 인스턴스(Reserved Instance, RI)는 특정 리전의 특정 인스턴스 타입을 1년 또는 3년 쓰겠다고 약정하고 최대 70% 이상 할인받는다. 문제는 스펙에 묶인다는 점이다. 약정한 인스턴스 타입을 바꾸면 할인이 깨지거나 재조정이 필요하다.
Savings Plans는 RI의 개선판이라고 보면 된다.
특정 스펙이 아니라 "시간당 이만큼(예: $10/h)을 쓰겠다"고 금액에 약정을 건다. 그 한도 안에서는 인스턴스 패밀리나 리전을 바꿔도 할인이 그대로 유지된다. 그래서 최근에는 RI보다 Savings Plans가 먼저 권장된다. AWS re:Post의 설명에서도 이 유연성 차이를 핵심으로 다룬다.
스팟 인스턴스(Spot)는 AWS 데이터센터에서 그 순간 온디맨드로 팔리지 않고 남아도는 용량을 최대 90%까지 할인해 빌려주는 방식이다. 다만 다른 고객이 온디맨드로 그 자리를 요청하면 AWS는 2분 전 중단 경고를 보내고 인스턴스를 회수해간다.
이 네 가지가 동시에 존재하는 이유는 고객마다 "확실성에 지불할 의사"가 다르기 때문이다. 3년치 트래픽을 예측할 수 있는 대기업은 RI나 Savings Plans로 확정 할인을 받고, 트래픽이 들쭉날쭉한 스타트업은 온디맨드를 쓰고, 죽어도 상관없는 배치 작업을 돌리는 팀은 스팟으로 최대한 아낀다. AWS 입장에서도 스팟은 "어차피 안 팔리면 그냥 놀리는" 유휴 용량을 그나마 현금화하는 수단이라 손해 볼 것이 없다.
여기서 Day 2에서 다룬 원칙이 다시 등장한다.
EC2 인스턴스는 언제든 버릴 수 있는 소모품이고 상태는 인스턴스 밖에 둬야 한다는 원칙 말이다. 스팟이 성립하는 이유가 바로 이것이다. 상태를 인스턴스 밖(S3, RDS, 외부 큐)에 두고 여러 대를 로드밸런서 뒤에 둔 워크로드라면, 한 대가 2분 뒤에 회수돼도 서비스에는 문제가 없다. 반대로 로컬 디스크에 유일한 데이터를 들고 있는 DB 서버를 스팟에 올리면, "저렴함"이 "데이터 유실 위험"으로 바뀐다. 스팟을 쓸 수 있느냐 없느냐는 결국 그 인스턴스가 얼마나 소모품답게 설계되었느냐를 확인하는 시험이다.
4. 온프레미스와의 결정적 차이: "바꾼다"의 의미가 다르다
여기서 자연스럽게 드는 질문이 있다. 온프레미스에서도 서버 사양을 바꿀 수 있지 않은가?
부분적으로는 가능하다. 메모리를 추가로 꽂거나, GPU 카드를 PCIe 슬롯에 장착하거나, 디스크를 SSD로 교체하는 것은 할 수 있다. 하지만 여기엔 명확한 물리적 한계가 있다. 메인보드가 지원하는 메모리 슬롯 수, 전원 공급 장치(PSU)의 용량, GPU 장착에 필요한 슬롯과 발열을 감당할 냉각 설계, 심지어 랙의 공간과 하중까지 전부 서버를 설계할 때 이미 정해진다. CPU 중심으로 설계된 1U 서버에 GPU 4장을 추가로 꽂으려 하면, 전원도 냉각도 감당하지 못해 물리적으로 불가능한 경우가 대부분이다.
즉 "M 타입 서버를 R 타입으로 바꾼다"는 것은 부품 몇 개를 교체하는 일이 아니라, 그 서버를 폐기하고 메모리 중심으로 설계된 다른 서버를 새로 사는 일에 가깝다. 설령 부품 교체가 물리적으로 가능하더라도, 발주와 배송을 기다리고 다운타임을 잡아 엔지니어가 직접 작업해야 하니 짧아도 며칠, 대규모라면 몇 주가 걸린다.
EC2에서는 이 과정이 이렇게 압축된다.
# 1. 인스턴스 중지
aws ec2 stop-instances --instance-ids i-0123456789abcdef0
# 2. 인스턴스 타입 변경 (m5.large → r5.large)
aws ec2 modify-instance-attribute \
--instance-id i-0123456789abcdef0 \
--instance-type "{\"Value\": \"r5.large\"}"
# 3. 다시 시작
aws ec2 start-instances --instance-ids i-0123456789abcdef0
몇 분이면 끝난다. 물리적으로는 CPU 대 메모리 비율이 전혀 다른 별개의 호스트로 옮겨가는 것이지만, 사용자에게는 그저 콘솔에서 타입 하나를 바꾸는 일로 보인다. 가상화 계층이 "어떤 물리 서버로 옮길지"를 대신 찾아주기 때문이다.
정리하면 이렇다. 온프레미스에서 서버 종류를 바꾸는 것은 새 하드웨어를 사는 일이고, EC2에서 인스턴스 타입을 바꾸는 것은 가상화 계층이 대신 다른 물리 호스트를 찾아 옮겨주는 일이다.
5. 한계
이 편리함에는 몇 가지 조건이 붙는다.
인스턴스 타입 변경은 같은 가상화 세대(아키텍처) 안에서만 자유롭다.
예를 들어 인텔/AMD 기반 인스턴스에서 AWS 자체 설계 칩인 Graviton(ARM) 기반 인스턴스로 바꾸는 것은 단순한 "타입 변경"이 아니라 OS 이미지 자체를 ARM용으로 다시 준비해야 하는 별개의 작업이다.
그리고 Day 1에서 다룬 내용과도 이어진다. 원하는 인스턴스 타입이 항상 모든 가용 영역에 재고가 있는 것은 아니다. 최신 GPU 인스턴스나 대형 메모리 최적화 타입은 특정 AZ에서 InsufficientInstanceCapacity 오류로 거절될 수 있다. "타입을 자유롭게 고를 수 있다"는 것이 "언제나 원하는 만큼 확보할 수 있다"는 뜻은 아니다.
마지막으로 요금 약정 쪽의 한계도 있다. RI나 Savings Plans로 약정을 걸어두면, 그 기간 동안은 온디맨드보다 저렴한 대신 쓰지 않아도 비용이 나간다. 트래픽을 정확히 예측하지 못하는 초기 단계의 서비스라면, 할인율에 현혹되어 과도하게 약정을 거는 것이 오히려 손해로 돌아올 수 있다.
마치며
인스턴스 타입 목록 앞에서 느끼는 복잡함은, 사실 AWS가 자신의 이종 하드웨어 재고를 그대로 상품 목록으로 펼쳐놓았기 때문에 생기는 것이다. 그 복잡함 뒤에는 "각 하드웨어에 맞는 수요를 정확히 찾는다"는 단순한 원리가 있고, 요금 모델 네 가지 역시 "얼마나 확실하게 쓸 것인가"라는 하나의 축 위에 놓여 있다.
그리고 이 모든 유연함 (타입을 몇 분 만에 바꾸고, 스펙이 다른 서버로 옮겨 다니고, 필요 없으면 지우는 것) 은 결국 Day 2에서 배운 전제 위에 서 있다. 서버는 애지중지 키우는 것이 아니라 소모품이라는 전제 말이다. 그 전제가 없었다면 인스턴스 타입을 이렇게 자유롭게 바꾸는 것도, 스팟으로 90% 할인을 받는 것도 애초에 불가능했을 것이다.
참고 자료
'AWS > 기초' 카테고리의 다른 글
| EC2는 "클라우드에 있는 서버"가 아니다 — 온프레미스 서버와 EC2의 진짜 차이 (0) | 2026.09.10 |
|---|---|
| AWS 서울 리전 이중화, 왜 다들 a존과 c존을 쓸까? (0) | 2026.09.09 |
댓글