EBS gp2 vs gp3: IOPS 독립 확장과 비용 최적화 완전 가이드

EC2 인스턴스에 볼륨을 붙이려는데 콘솔에 gp2와 gp3가 나란히 보인다. 둘 다 '범용 SSD'라는 설명은 같은데, 실제 운영 환경에서 어떤 차이가 있는지 모르면 나중에 IOPS 부족으로 병목이 생기거나 불필요한 비용이 발생한다. EBS gp3는 스토리지 용량과 무관하게 IOPS를 독립적으로 조정할 수 있는 볼륨 타입으로, 대부분의 워크로드에서 gp2보다 비용 효율적이다.

TL;DR — gp2 vs gp3 핵심 비교

항목	gp2	gp3
IOPS 결정 방식	용량에 연동 (3 IOPS/GB)	용량과 독립적으로 설정
기본 IOPS	용량 기반 자동 산정	3,000 IOPS (기본 포함)
최대 IOPS	16,000	16,000
최대 처리량	250 MiB/s	1,000 MiB/s
버스트 메커니즘	크레딧 버킷 방식	없음 (기본 성능이 일정)
비용 구조	GB당 단일 요금	GB + IOPS + 처리량 분리 과금
신규 워크로드 권장	—	✓

가격과 한도는 변동될 수 있으므로 항상 AWS 공식 EBS 요금 페이지에서 최신 정보를 확인하라.

gp2와 gp3의 작동 방식 이해

gp2는 IOPS가 볼륨 크기에 묶여 있다. 1 GiB당 3 IOPS가 자동으로 할당되며, 최소 100 IOPS에서 최대 16,000 IOPS까지 선형으로 증가한다. 즉, 16,000 IOPS가 필요하면 최소 5,334 GiB 볼륨을 프로비저닝해야 한다. 실제로 그만큼의 스토리지가 필요 없더라도 IOPS를 위해 용량을 낭비하는 구조다.

버스트 메커니즘도 있다. 1 TiB 미만 볼륨은 크레딧 버킷을 소진하면서 최대 3,000 IOPS까지 일시적으로 올라가지만, 크레딧이 바닥나면 기본 IOPS로 떨어진다. 예측 불가능한 성능 저하의 원인이 된다.

gp3는 이 연동 구조를 끊었다. 용량과 무관하게 기본 3,000 IOPS와 125 MiB/s 처리량을 제공하고, 추가 비용을 내면 최대 16,000 IOPS와 1,000 MiB/s까지 독립적으로 올릴 수 있다. 버스트 크레딧 개념이 없어서 성능이 일정하게 유지된다.

graph TD A["볼륨 타입 선택"] --> B{"gp2 또는 gp3?"}; B -->|"gp2"| C["크기(GiB) 입력"]; C --> D["IOPS = GiB x 3 자동 산정"]; D --> E{"볼륨 < 1 TiB?"}; E -->|"Yes"| F["버스트 크레딧 사용 최대 3,000 IOPS"]; F --> G{"크레딧 소진?"}; G -->|"Yes"| H["기본 IOPS로 복귀 성능 저하 발생"]; G -->|"No"| I["버스트 IOPS 유지"]; E -->|"No"| J["기본 IOPS 고정"]; B -->|"gp3"| K["크기(GiB) 입력"]; K --> L["기본 3,000 IOPS 125 MiB/s 처리량 포함"]; L --> M{"추가 성능 필요?"}; M -->|"Yes"| N["IOPS / 처리량 독립 설정"]; M -->|"No"| O["기본 성능으로 운영 추가 비용 없음"]; N --> P["최대 16,000 IOPS 1,000 MiB/s"];

gp2 IOPS 결정 경로: 볼륨 크기가 입력되면 3 IOPS/GiB 공식이 자동 적용된다. 1 TiB 미만에서는 버스트 크레딧이 개입하지만, 크레딧 소진 시 기본 IOPS로 복귀한다.
gp3 IOPS 결정 경로: 볼륨 크기와 IOPS 설정이 완전히 분리된다. 기본 3,000 IOPS는 추가 비용 없이 제공되며, 그 이상은 별도 설정으로 조정한다.
처리량 차이: gp3의 최대 처리량(1,000 MiB/s)은 gp2(250 MiB/s)의 4배다. 대용량 순차 읽기/쓰기 워크로드에서 의미 있는 차이가 난다.

EBS gp3로 IOPS를 독립 설정하는 방법

gp3 볼륨을 생성하거나 기존 gp2를 gp3로 전환할 때 IOPS와 처리량을 별도로 지정한다. 볼륨 수정은 인스턴스를 중단하지 않고도 가능하다 — Elastic Volumes 기능 덕분이다.

신규 gp3 볼륨 생성

aws ec2 create-volume \
  --volume-type gp3 \
  --size 100 \
  --iops 6000 \
  --throughput 250 \
  --availability-zone us-east-1a

위 예시는 100 GiB 볼륨에 6,000 IOPS를 설정한다. gp2였다면 같은 IOPS를 얻으려면 2,000 GiB가 필요했을 것이다.

기존 gp2 볼륨을 gp3로 전환

aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type gp3 \
  --iops 3000 \
  --throughput 125

전환 후 상태는 modifying → optimizing → completed 순으로 변한다. optimizing 상태에서도 볼륨은 정상 동작한다.

전환 상태 확인

aws ec2 describe-volumes-modifications \
  --volume-id vol-0123456789abcdef0 \
  --query 'VolumesModifications[*].{VolumeId:VolumeId,State:ModificationState,Progress:Progress}'

비용 구조 차이와 최적화 전략

gp2는 GB당 단일 요금만 존재한다. 단순하지만 IOPS를 올리려면 용량을 늘리는 수밖에 없어서, 스토리지가 남아도는 상태에서 비용이 증가한다.

gp3는 GB, IOPS, 처리량을 분리해서 과금한다. 기본 제공 범위(3,000 IOPS, 125 MiB/s)를 초과하는 부분만 추가 비용이 발생한다. AWS 공식 문서에 따르면 gp3는 gp2 대비 GB당 기본 요금이 낮으며, 동일한 IOPS를 구성할 경우 일반적으로 더 저렴하다. 정확한 수치는 리전마다 다르므로 공식 요금 페이지에서 직접 계산하라.

gp3의 비용 구조는 마치 클라우드 컴퓨팅의 '분리 과금' 철학과 같다. 필요한 것만 사고, 묶음 할인에 속아 필요 없는 용량을 사지 않는다.

비용 최적화 시나리오

가장 흔한 낭비 패턴은 이렇다: gp2에서 IOPS가 부족해서 볼륨을 500 GiB로 늘렸는데, 실제 데이터는 50 GiB밖에 안 된다. gp3로 전환하면 50 GiB + 필요한 IOPS만 설정해서 비용을 줄일 수 있다.

graph LR A["CloudWatch 메트릭 수집"] --> B["VolumeReadOps
VolumeWriteOps"]; A --> C["BurstBalance"]; B --> D{"실제 IOPS 패턴 분석"}; C --> E{"크레딧 잔량 확인"}; D --> F["필요 IOPS 산정"]; E -->|"지속적으로 낮음"| G["성능 병목 위험"]; E -->|"정상 범위"| H["현재 설정 유지 가능"]; F --> I["gp3 IOPS 설정값 결정"]; G --> I; I --> J["modify-volume 실행"]; J --> K["modifying → optimizing → completed"];

현재 IOPS 사용량 파악: CloudWatch VolumeReadOps, VolumeWriteOps 메트릭으로 실제 IOPS 패턴을 측정한다.
gp2 버스트 크레딧 잔량 확인: BurstBalance 메트릭이 지속적으로 낮다면 이미 성능 병목이 발생하고 있다는 신호다.
gp3 전환 후 IOPS 조정: 실측값 기준으로 필요한 IOPS만 설정한다. 기본 3,000 IOPS로 충분하다면 추가 비용이 전혀 없다.

실제 운영에서 마주치는 함정 — gp2 버스트 크레딧 소진

증상: 새벽 배치 작업이 평소엔 20분 만에 끝나는데, 특정 날은 2시간이 걸린다. 애플리케이션 로그에는 아무 에러가 없다.

처음엔 쿼리 플랜이 바뀌었거나 데이터 양이 급증했다고 의심한다. DB 슬로우 쿼리 로그를 뒤지고, 인스턴스 CPU를 확인하고, 네트워크 대역폭을 본다. 전부 정상이다.

실제 원인은 gp2 버스트 크레딧 소진이었다. 전날 낮에 트래픽이 몰리면서 크레딧을 다 써버렸고, 밤새 크레딧이 충분히 회복되지 않은 상태에서 배치가 돌았다. CloudWatch에서 BurstBalance를 보면 배치 시작 시점에 크레딧이 거의 0에 가까웠다.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name BurstBalance \
  --dimensions Name=VolumeId,Value=vol-0123456789abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T06:00:00Z \
  --period 300 \
  --statistics Average

gp3로 전환하고 나서 이 문제는 완전히 사라졌다. 버스트 크레딧 자체가 없으니 크레딧 소진도 없다. 설정한 IOPS가 항상 일정하게 제공된다.

gp2의 버스트 메커니즘은 간헐적 워크로드에는 유리하지만, 크레딧 소진 후 성능 저하가 애플리케이션 레이어에서 보이지 않아 진단이 어렵다.

gp3 볼륨 관리를 위한 IAM 정책

볼륨 생성과 수정 권한을 최소 권한 원칙에 따라 설정한다.

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

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeEBSVolumes",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeVolumes",
        "ec2:DescribeVolumesModifications"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ModifySpecificVolume",
      "Effect": "Allow",
      "Action": [
        "ec2:ModifyVolume"
      ],
      "Resource": "arn:aws:ec2:us-east-1:123456789012:volume/vol-0123456789abcdef0"
    },
    {
      "Sid": "CreateGp3Volume",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateVolume"
      ],
      "Resource": "arn:aws:ec2:us-east-1:123456789012:volume/*"
    }
  ]
}

ec2:DescribeVolumes와 ec2:DescribeVolumesModifications는 Describe 계열 액션으로, 특정 리소스 ID를 사전에 알 수 없는 일반적인 정책 구성에서는 "Resource": "*"를 사용한다. ec2:ModifyVolume은 특정 볼륨 ARN으로 범위를 제한할 수 있다.

gp2와 gp3 중 선택 기준

graph TD A["새 볼륨 필요"] --> B{"신규 생성?"}; B -->|"Yes"| C["gp3 선택"]; B -->|"No — 기존 gp2"| D{"성능 문제 있음?"}; D -->|"BurstBalance 자주 낮음"| E["gp3 전환 권장"]; D -->|"IOPS 위해 용량 과다 프로비저닝"| E; D -->|"안정적 운영 중"| F{"신규 볼륨 추가 예정?"}; F -->|"Yes"| G["신규분은 gp3로 표준화"]; F -->|"No"| H["gp2 유지 가능 단, 모니터링 지속"]; E --> I["modify-volume으로 무중단 전환"]; C --> J["create-volume --volume-type gp3"];

신규 볼륨: 특별한 이유가 없다면 gp3를 선택한다. 기본 성능이 더 높고 비용도 낮다.
기존 gp2 마이그레이션: BurstBalance가 자주 낮아지거나, IOPS를 위해 필요 이상으로 용량을 늘린 볼륨은 gp3 전환 효과가 크다.
gp2 유지가 합리적인 경우: 이미 안정적으로 운영 중이고 성능 문제가 없다면 굳이 전환할 긴급성은 없다. 다만 신규 프로비저닝은 gp3로 표준화하는 것이 낫다.

EBS gp3 전환 시 다음 단계

gp3는 gp2 대비 IOPS 독립 설정과 비용 효율 두 가지를 모두 개선한다. 기존 환경에서 gp2 볼륨을 사용 중이라면 아래 순서로 전환을 검토하라.

CloudWatch에서 현재 gp2 볼륨의 BurstBalance와 실제 IOPS 사용량을 2주 이상 수집한다.
AWS Pricing Calculator로 동일 성능 기준 gp3 비용을 비교한다.
비프로덕션 환경에서 modify-volume으로 gp3 전환을 테스트한다.
프로덕션 전환 후 describe-volumes-modifications로 완료 상태를 확인한다.

관련 주제: Amazon EBS Elastic Volumes 공식 문서에서 무중단 볼륨 수정 절차를 확인할 수 있다.

핵심 용어 정리

용어	설명
IOPS	초당 입출력 작업 수. 데이터베이스처럼 소규모 랜덤 읽기/쓰기가 많은 워크로드에서 핵심 성능 지표다.
처리량 (Throughput)	초당 전송되는 데이터 양 (MiB/s). 대용량 순차 읽기/쓰기 워크로드에서 중요하다.
버스트 크레딧 (Burst Credit)	gp2 전용 메커니즘. 볼륨이 유휴 상태일 때 크레딧을 축적하고, 피크 시 소진하며 일시적으로 높은 IOPS를 제공한다.
Elastic Volumes	EC2 인스턴스를 중단하지 않고 EBS 볼륨 타입, 크기, IOPS, 처리량을 변경할 수 있는 기능이다.
BurstBalance	gp2 볼륨의 버스트 크레딧 잔량을 나타내는 CloudWatch 메트릭. 0에 가까워지면 성능 저하가 발생한다.

이 블로그 검색

SW BBANG K