AWS T3 인스턴스 CPU 크레딧 완전 이해: 갑작스러운 성능 저하의 진짜 원인

배포 직후엔 멀쩡하던 서버가 트래픽이 몰리고 나서 갑자기 응답이 느려진다. CPU 사용률을 보면 100%도 아닌데 레이턴시는 치솟는다. T3 인스턴스를 운영하다 보면 한 번쯤 마주치는 상황이고, 원인을 모르면 인스턴스 타입을 무작정 업그레이드하게 된다. 문제는 CPU 크레딧이다.

TL;DR — T3 CPU 크레딧 핵심 요약

항목	내용
T3 동작 방식	기준선(Baseline) 이하 사용 시 크레딧 적립, 초과 시 소진
크레딧 소진 시 동작	Standard 모드: CPU가 기준선으로 스로틀링 / Unlimited 모드: 추가 과금 후 버스트 유지
T3 기본 모드	Unlimited (T3 출시 이후 기본값)
성능 저하 주요 원인	Standard 모드에서 크레딧 고갈, 또는 Unlimited 모드에서 예상치 못한 추가 비용
진단 지표	CloudWatch: CPUCreditBalance, CPUSurplusCreditsCharged

T3 버스터블 인스턴스의 동작 원리

T3는 일반 인스턴스와 달리 vCPU를 항상 전속력으로 쓸 수 없다. 인스턴스 크기마다 정해진 CPU 기준선(Baseline)이 있고, 그 이하로 사용하면 크레딧이 쌓이고, 초과하면 크레딧을 소진하는 구조다. 크레딧이 있을 때만 기준선 이상의 CPU 성능을 낼 수 있다.

기준선은 인스턴스 크기에 따라 다르다. 예를 들어 t3.micro는 vCPU 2개 기준으로 약 10%의 기준선을 가진다. 즉, 평균 CPU 사용률이 10% 이하일 때 크레딧이 적립되고, 10%를 넘으면 크레딧을 소진한다. 정확한 기준선 수치는 인스턴스 크기마다 다르므로 AWS 공식 문서에서 확인해야 한다.

크레딧 시스템은 은행 계좌와 비슷하다. 조용할 때 저축하고, 바쁠 때 인출한다. 잔고가 바닥나면 더 이상 인출할 수 없다 — Standard 모드에서는.

graph TD A["CPU 사용률 < 기준선"] -->|"크레딧 적립"| B["CPUCreditBalance 증가"] B --> C{"버스트 필요?"} C -->|"No"| A C -->|"Yes"| D["CPU 사용률 > 기준선"] D -->|"크레딧 소진"| E["CPUCreditBalance 감소"] E --> F{"잔고 > 0?"} F -->|"Yes"| D F -->|"No — Standard 모드"| G["CPU 기준선으로 스로틀링
응답 지연 발생"] F -->|"No — Unlimited 모드"| H["Surplus Credit 발생
추가 요금 청구"]

크레딧 적립 구간: CPU 사용률이 기준선 미만일 때, 시간당 일정량의 크레딧이 적립된다. 적립 속도와 최대 잔고는 인스턴스 크기에 따라 다르다.
버스트 구간: CPU 사용률이 기준선을 초과하면 크레딧을 소진하며 높은 성능을 유지한다.
크레딧 고갈 (Standard 모드): 잔고가 0이 되면 CPU는 기준선 수준으로 스로틀링된다. 이 시점부터 응답 지연이 발생한다.
Unlimited 모드: 크레딧이 고갈되어도 버스트를 유지하되, 초과분에 대해 추가 요금이 부과된다.

Standard 모드 vs Unlimited 모드 — 무엇이 다른가

T3 인스턴스는 출시 시점부터 Unlimited 모드가 기본값이다. T2는 Standard가 기본값이었기 때문에, T2에서 T3로 마이그레이션할 때 이 차이를 놓치는 경우가 많다.

graph LR A["T3 인스턴스 생성"] --> B["기본값: Unlimited 모드"] B --> C{"크레딧 잔고?"} C -->|"잔고 있음"| D["버스트 성능 제공"] C -->|"잔고 없음 — Unlimited"| E["Surplus Credit 사용
추가 요금 발생"] C -->|"잔고 없음 — Standard"| F["CPU 기준선으로 스로틀링"] D --> G["정상 응답"] E --> G F --> H["성능 저하 / 응답 지연"]

Standard 모드: 크레딧 잔고가 0이 되면 CPU 성능이 기준선으로 하드 스로틀링된다. 비용은 예측 가능하지만 성능이 갑자기 떨어진다.
Unlimited 모드: 크레딧 잔고가 0이 되어도 버스트를 계속 허용한다. 대신 'Surplus Credit'이 발생하고, 이 초과분에 대해 시간당 추가 요금이 청구된다. 비용이 예상보다 크게 늘어날 수 있다.
모드 전환: 실행 중인 인스턴스에서도 모드 변경이 가능하다. 단, Unlimited → Standard로 전환 시 누적된 Surplus Credit 비용이 즉시 정산된다.

CPU 크레딧 진단 — CloudWatch 지표 읽기

성능 저하가 크레딧 문제인지 확인하는 가장 빠른 방법은 CloudWatch에서 두 가지 지표를 보는 것이다. CPUCreditBalance가 0에 수렴하는 시점과 응답 지연 발생 시점이 일치하면 크레딧 고갈이 원인이다.

아래 CLI로 특정 인스턴스의 크레딧 잔고 추이를 확인할 수 있다.

# CPUCreditBalance 조회 (최근 3시간, 5분 단위)
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time $(date -u -d '3 hours ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 300 \
  --statistics Minimum \
  --region us-east-1

# Unlimited 모드에서 초과 크레딧 과금 여부 확인
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUSurplusCreditsCharged \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time $(date -u -d '3 hours ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 300 \
  --statistics Sum \
  --region us-east-1

CPUSurplusCreditsCharged 값이 0보다 크다면 Unlimited 모드에서 추가 요금이 발생하고 있다는 뜻이다. 이 지표가 지속적으로 올라간다면 워크로드 패턴이 T3에 맞지 않는다는 신호다.

현재 인스턴스의 크레딧 옵션(Standard/Unlimited) 확인은 아래 명령으로 한다.

aws ec2 describe-instance-credit-specifications \
  --instance-ids i-1234567890abcdef0 \
  --region us-east-1

실제 장애 패턴 — 오진에서 정확한 원인까지

증상: 오전 9시부터 트래픽이 몰리는 서비스에서 매일 오전 11시쯤 API 응답 시간이 3배 이상 늘어난다. CPU 사용률 그래프를 보면 60~70% 수준이라 '충분히 여유 있어 보이는데?'라고 생각하기 쉽다.

첫 번째 오진: 팀은 처음에 데이터베이스 쿼리 성능 문제로 보고 슬로우 쿼리 로그를 뒤졌다. 쿼리 자체는 문제없었다.

실제 원인: 인스턴스가 Standard 모드로 설정되어 있었고, 오전 9시부터 2시간 동안 버스트를 지속하면서 크레딧을 소진했다. 오전 11시에 CPUCreditBalance가 0이 되면서 CPU가 기준선(예: 20%)으로 스로틀링됐다. CloudWatch에서 CPU 사용률은 여전히 '60%처럼' 보였는데, 이는 스로틀링 이후 처리 대기 중인 요청들이 쌓이면서 CPU가 기준선 수준에서 계속 돌고 있었기 때문이다.

수정: 해당 인스턴스를 Unlimited 모드로 전환하거나, 워크로드 패턴이 지속적으로 높은 CPU를 요구한다면 M5 같은 고정 성능 인스턴스로 교체하는 것이 맞다.

CPU 사용률 그래프가 '정상'으로 보여도 스로틀링 중일 수 있다. CPUCreditBalance를 같은 타임라인에 겹쳐서 봐야 진짜 그림이 나온다.

크레딧 모드 변경 — CLI 실습

Standard 모드를 Unlimited로 전환하거나 그 반대로 변경할 때는 modify-instance-credit-specification을 사용한다. 실행 중인 인스턴스에 즉시 적용된다.

# Standard → Unlimited 전환
aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications InstanceId=i-1234567890abcdef0,CpuCredits=unlimited \
  --region us-east-1

# Unlimited → Standard 전환 (누적 Surplus Credit 즉시 정산 주의)
aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications InstanceId=i-1234567890abcdef0,CpuCredits=standard \
  --region us-east-1

Unlimited → Standard 전환 시, 그동안 누적된 Surplus Credit 비용이 즉시 청구된다는 점을 반드시 확인하고 진행해야 한다.

T3 인스턴스에 적합한 워크로드와 그렇지 않은 워크로드

T3가 비용 효율적인 선택이 되는 경우와 오히려 독이 되는 경우는 명확하게 구분된다.

graph TD A["워크로드 CPU 패턴 분석"] --> B{"평균 CPU가
기준선 이하?"} B -->|"Yes — 대부분의 시간"| C["T3 적합
크레딧 적립 가능"] B -->|"No — 지속적 초과"| D{"Unlimited 추가 요금 vs
M5/C5 비용 비교"} D -->|"T3 Unlimited가 저렴"| E["T3 Unlimited 유지"] D -->|"고정 성능 인스턴스가 저렴"| F["M5 / C5 마이그레이션 권장"] C --> G["CPUCreditBalance 모니터링 설정"]

T3 적합: 개발/스테이징 환경, 낮은 평균 CPU를 유지하는 웹 서버, 간헐적 배치 작업, 트래픽 패턴이 예측 가능하고 피크가 짧은 서비스.
T3 부적합: 지속적으로 높은 CPU를 요구하는 인코딩/렌더링 작업, 기준선을 상시 초과하는 워크로드. 이 경우 Unlimited 모드에서 추가 요금이 고정 성능 인스턴스 비용을 초과할 수 있다.
판단 기준: 평균 CPU 사용률이 해당 인스턴스의 기준선을 지속적으로 초과한다면, M5/C5 같은 고정 성능 인스턴스가 더 비용 효율적이다.

IAM — CloudWatch 지표 조회에 필요한 최소 권한

운영 팀이 크레딧 지표를 모니터링하기 위해 필요한 최소 IAM 정책이다.

🔽 IAM 정책 예시 (클릭하여 펼치기)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:ListMetrics",
        "ec2:DescribeInstanceCreditSpecifications",
        "ec2:DescribeInstances"
      ],
      "Resource": "*"
    }
  ]
}

cloudwatch:GetMetricStatistics와 ec2:DescribeInstanceCreditSpecifications는 리소스 수준 제한을 지원하지 않아 "Resource": "*"가 필요하다. AWS Service Authorization Reference에서 각 액션의 리소스 수준 지원 여부를 확인하고 적용해야 한다.

T3 CPU 크레딧 이해로 성능 저하 예방하기 — 마무리

T3 인스턴스의 갑작스러운 성능 저하는 대부분 크레딧 고갈에서 비롯된다. 핵심은 세 가지다: 워크로드의 평균 CPU 패턴이 기준선과 맞는지 확인하고, CPUCreditBalance를 핵심 운영 지표로 모니터링하고, Standard/Unlimited 모드 선택을 비용과 성능 요구사항에 맞게 의식적으로 결정하는 것이다.

지속적으로 크레딧을 소진하는 워크로드라면 T3 Unlimited의 추가 요금과 동급 M5 인스턴스 비용을 비교해보는 것이 현명하다. 비용과 성능 예측 가능성 모두에서 고정 성능 인스턴스가 나을 수 있다.

다음 단계로 CloudWatch 알람을 설정해 CPUCreditBalance가 특정 임계값 이하로 떨어질 때 알림을 받도록 구성하는 것을 권장한다. 관련 내용은 AWS 공식 모니터링 가이드를 참고하라.

핵심 용어 정리

용어	설명
CPU 기준선 (Baseline)	인스턴스 크기별로 정해진 CPU 사용률 기준. 이 이하로 사용 시 크레딧 적립.
CPU 크레딧 (CPU Credit)	버스트 성능을 사용할 수 있는 단위. 1 크레딧 = vCPU 1개를 1분간 100% 사용.
CPUCreditBalance	현재 보유 중인 크레딧 잔고. CloudWatch 지표.
Surplus Credit	Unlimited 모드에서 크레딧 잔고 초과 후 사용한 추가 버스트량. 별도 과금.
스로틀링 (Throttling)	Standard 모드에서 크레딧 고갈 시 CPU 성능이 기준선으로 제한되는 현상.

이 블로그 검색

SW BBANG K