EC2 인스턴스·크레딧·요금 문답

네 부분으로 되어 있습니다. 앞의 두 글자가 성격을, 점 뒤가 크기를 결정합니다.

t     3     i(생략)   .   medium
│     │     │             │
│     │     │             └─ 크기
│     │     └─ CPU 제조사 (i=Intel, a=AMD, g=Graviton/Arm)
│     └─ 세대 (숫자가 클수록 최신·저렴·빠름)
└─ 패밀리 (용도)

패밀리(첫 글자) — 성격을 결정한다

크기

large에서 한 단계 오를 때마다 vCPU·메모리·가격이 대략 2배입니다.

nano < micro < small < medium < large < xlarge < 2xlarge < 4xlarge ...

실제 스펙

vCPU란 물리 CPU 코어를 하이퍼스레딩으로 둘로 쪼갠 논리 단위입니다. 2 vCPU ≈ 물리 1코어로 생각하면 됩니다. 노트북이 8~16 vCPU인 걸 생각하면 t3.medium은 상당히 작은 기계입니다.

해결되지 않습니다. t3.medium과 t3.large는 vCPU가 둘 다 2개입니다. 바뀌는 건 메모리(4GB → 8GB)뿐이고 계산 속도는 그대로입니다.

메모리가 모자라 프로세스가 죽는 상황이라면 t3.large가 답입니다. 그러나 응답이 느린 문제라면 원인은 vCPU 수와 CPU 크레딧이라, 같은 t 계열 안에서 한 단계 올리는 것으로는 아무것도 달라지지 않습니다.

t3는 CPU를 항상 100% 쓸 수 있는 기계가 아닙니다. 데이터 요금제와 구조가 같습니다 — 기본 제공량이 있고, 덜 쓰면 쌓이고, 넘겨 쓰면 까입니다.

크레딧이 바닥났을 때 — 두 가지 모드

t3.medium을 2 vCPU 100%로 계속 돌리면 이렇게 됩니다.

시간당 적립      24 크레딧
시간당 소비     120 크레딧
잉여             96 크레딧 = 1.6 vCPU-시간
추가 요금        1.6 × $0.05 = 시간당 $0.08
인스턴스 요금                  시간당 $0.052

인스턴스 값보다 크레딧 값이 더 나옵니다. 기본값이 unlimited라 아무 설정도 하지 않으면 이 상태입니다.

측정 대상이 CPU 성능이 아니라 크레딧 잔고가 되기 때문입니다. 같은 코드로 같은 부하를 걸어도 이렇게 나옵니다.

코드는 하나도 안 바뀌었는데 숫자가 4배 차이납니다. “여러 번 실행한 값 중 최저치를 기준선으로 고정”하는 방법을 써도, 그 최저치가 CPU 성능을 의미하지 않게 됩니다.

짧은 프로젝트에서 약정 할인은 회수할 시간이 없고, 스팟은 회수 위험이 측정 신뢰도를 직접 깎습니다. 온디맨드로 두고 안 쓸 때 끄는 쪽이 총액이 낮습니다.

되지 않습니다. 끄는 것과 지우는 것은 다르고, 둘 다 저장소·IP 요금은 따로입니다.

30GB EBS(월 약 $2.7) + EIP(월 약 $3.6)는 인스턴스를 꺼 둔 동안에도 계속 나갑니다. 종료했더라도 EIP를 따로 해제하지 않으면 IP 요금은 남습니다.

EBS / gp3

EC2에 붙는 가상 하드디스크입니다. gp3는 SSD 계열 표준 타입이고, 용량만큼 월 단위로 과금됩니다. 30GiB면 월 약 $2.7입니다.

EIP(탄력적 IP) / 공인 IPv4

인터넷에서 접근 가능한 고정 IP입니다. 2024-02-01부터 연결 여부와 무관하게 시간당 $0.005(월 약 $3.6)입니다. 인스턴스를 종료해도 EIP를 별도로 해제하지 않으면 계속 나갑니다.

데이터 전송(이그레스)

AWS 밖 인터넷으로 나가는 트래픽입니다. 모든 서비스·리전 합산 매달 100GB까지 무료이고, 초과분은 서울 기준 GB당 약 $0.126입니다. 들어오는 트래픽은 무료입니다. 자막·JSON 위주 규모라면 100GB를 넘길 일이 없습니다.

NAT Gateway

인터넷에서 직접 접근할 수 없는 서버(프라이빗 서브넷)가 밖으로 나갈 때 쓰는 관문입니다. 시간당 요금 + 트래픽당 요금이 동시에 붙어 월 $35 이상이 나가고, 비용 사고의 단골입니다.

리전 / AZ

리전은 지리적 묶음(서울 = ap-northeast-2), AZ(가용영역)는 그 안의 독립된 데이터센터 동(2a, 2b…)입니다. 같은 AZ 안 인스턴스끼리는 왕복 1ms 수준이고 통신료가 없습니다. 추론 인스턴스를 따로 떼어 놓아도 지연 예산에 영향이 없는 근거가 이것입니다.

파라미터는 모델 내부에 저장된 숫자의 개수입니다(M=백만, B=십억). 계산은 단순합니다 — 파라미터 1개당 몇 바이트를 쓰느냐입니다.

양자화는 숫자의 정밀도를 낮춰 메모리를 줄이는 기법입니다. 품질이 조금 떨어지는 대신 크기가 크게 줍니다.

VRAM은 GPU 전용 메모리입니다. 모델이 VRAM에 안 들어가면 GPU로 돌릴 수 없습니다. g4dn.xlarge의 T4는 16GB이므로 7B 모델까지 여유롭게 들어갑니다.

LLM이 글을 만드는 과정은 두 단계입니다.

[프리필 prefill]  프롬프트 전체를 한 번에 읽는다
                  ↓ 계산량이 프롬프트 길이에 비례해 늘어남
                  ↓ ★ 여기가 CPU에서 느린 구간
[디코드 decode]   한 글자씩 뱉는다 (토큰 하나마다 모델 전체를 다시 통과)

TTFT = 요청부터 첫 글자가 화면에 뜨기까지이고, 대부분이 프리필 시간입니다.

차이는 반복 횟수입니다. 분류기는 “이 문장이 위반인가”를 한 번 판정하고 끝이지만, 생성은 글자 하나 만들 때마다 모델 전체를 다시 통과시킵니다.

프리필은 거대한 행렬 곱셈입니다. GPU는 그 계산을 수천 개 코어로 동시에 처리하고, vCPU 2개는 순차적으로 처리합니다. 이 구조 차이는 인스턴스 등급을 한두 단계 올려서 메울 수 있는 게 아닙니다.

100번 측정해서 빠른 순으로 줄을 세웠을 때 몇 번째 값이냐입니다.

느린 순 ────────────────────────────────────→
 p50            p95      p99
  │              │        │
  ▼              ▼        ▼
[========================][==][=]
 절반은 여기보다 빠름   상위 5%  상위 1%

평균을 쓰지 않는 이유: 100번 중 95번이 0.2초, 5번이 10초라면 평균은 0.7초로 나옵니다. 숫자는 좋아 보이지만 20번에 한 번씩 10초를 기다리는 상담원이 실제 사용자입니다. 평균은 이 고통을 숨깁니다.