Graviton vs x86: EC2 인스턴스 아키텍처 선택 기준
EC2 인스턴스 패밀리를 고르고 나면 한 축이 더 남습니다. 같은 m 계열 안에서도 x86(m7i, m8i)과 ARM(m8g, m9g)이 나뉘기 때문입니다. 결론을 먼저 적으면, 아키텍처를 새로 정할 수 있는 워크로드는 Graviton이 기본값입니다. 시간당 단가가 10〜15% 낮고 세대가 갈수록 성능 격차가 벌어져, 가격 대비 성능으로는 수십 % 차이가 납니다. x86이 남는 이유는 성능이 아니라 호환성(상용 바이너리, 특정 명령어 의존, Windows 라이선스)입니다. 패밀리 선택 자체는 EC2 인스턴스 패밀리 비교에서, 전환 실무 절차는 Graviton 전환 체크리스트에서 다뤘고, 이 글은 선택 판단에 집중합니다. 요금은 us-east-1 기준입니다.
한눈에 보는 비교 #
| 구분 | Graviton (ARM) | x86 (Intel·AMD) |
|---|---|---|
| 시간당 단가 (m 계열 large) | m8g 약 $0.090 | m7i 약 $0.101 |
| 가격 대비 성능 | 동급 x86 대비 수십 % 우위 (워크로드별 상이) | 기준 |
| 소프트웨어 호환 | 오픈소스 생태계 대부분 지원 | 사실상 전부 |
| 컨테이너 | arm64 이미지·멀티 아치 빌드 필요 | 기존 이미지 그대로 |
| 상용 소프트웨어 | 벤더별 지원 확인 필요 | 대부분 지원 |
| Windows | 미지원 | 지원 |
| 최신 세대 | Graviton5 (m9g, 2026-06 GA) | 세대 병행 갱신 |
요금과 성능: 격차의 실제 크기 #
시간당 단가부터 보면, m8g.large(Graviton4)가 약 $0.090, m7i.large(Intel)가 약 $0.101로 Graviton이 약 11% 쌉니다. 단가 차이는 이 정도지만 실제 격차는 성능에서 벌어집니다. AWS는 Graviton4 기반 인스턴스가 동급 x86 대비 수십 % 좋은 가격 대비 성능을 낸다고 밝히고 있고, 웹 서버·API 서버류의 벤치마크에서는 같은 vCPU 수로 더 높은 처리량이 나오는 결과가 일반적입니다. vCPU의 실체가 다르다는 점도 작용합니다. x86의 vCPU는 하이퍼스레드 1개인 반면 Graviton의 vCPU는 물리 코어 1개입니다.
2026년 6월에는 Graviton5 기반 m9g·m9gd가 GA되었습니다. m8g보다 시간당 약 9% 비싸지만 성능이 최대 25% 올라, 가격 대비 성능은 다시 15%가량 개선됩니다. 다만 출시 초기라 제공 리전이 제한적(버지니아, 오하이오, 오리건, 프랑크푸르트부터)이므로, 리전 제약이 없으면 m9g, 그 외에는 m8g가 현재 기본값입니다. GPU나 NVIDIA 세대 표기와 마찬가지로 세대 정보는 시점에 따라 달라지므로, 도입 시점에 최신 세대와 리전 지원을 확인합니다.
절감 수단으로서의 특징은 약정 없이 단가가 내려간다는 점입니다. RI나 Savings Plans은 1〜3년 약정의 대가지만, Graviton 전환은 약정 없이 같은 폭의 절감을 만들고, 그 위에 약정을 겹칠 수 있습니다. 약정 체계는 RI vs Savings Plans에서 다뤘습니다.
어디부터 옮기는가: 매니지드 먼저 #
전환 난이도는 계층에 따라 완전히 다릅니다.
매니지드 서비스가 가장 쉽습니다. RDS, Aurora, ElastiCache, OpenSearch 같은 서비스는 인스턴스 클래스를 db.m7i에서 db.m8g로 바꾸는 것이 전부입니다. 내 코드가 그 위에서 돌지 않으므로 호환성 문제가 원천적으로 없고, 재기동 창만 확보하면 됩니다. Graviton 절감을 시작하는 자리는 EC2가 아니라 여기입니다.
인터프리터·JVM 계열은 쉬운 편입니다. Python, Node.js, Ruby, PHP, Java, Go는 arm64 런타임이 성숙해 대부분 재빌드나 이미지 교체로 끝납니다. 걸리는 것은 언어가 아니라 네이티브 의존성입니다. C 확장을 포함한 패키지, 사내 빌드 바이너리, 오래된 베이스 이미지가 arm64 빌드를 제공하는지 확인이 필요합니다.
컨테이너는 멀티 아치 빌드가 관문입니다. CI에서 amd64·arm64 이미지를 함께 빌드해 매니페스트로 묶는 체계를 갖추면, 노드 그룹 단위로 점진 전환할 수 있습니다. 상세 절차와 검증 항목은 전환 체크리스트에 정리해 두었습니다.
x86이 남는 영역은 명확합니다. arm64 빌드를 제공하지 않는 상용 소프트웨어, x86 특정 명령어(AVX 계열 등)에 최적화된 수치 연산, Windows 워크로드, 그리고 검증 비용을 정당화할 수 없는 소규모 레거시입니다. 이 목록에 해당하지 않는데 x86을 쓰고 있다면, 관성 외의 이유가 있는지 점검할 가치가 있습니다.
선택 순서 #
- 신규 워크로드는 Graviton으로 시작합니다: 처음부터 arm64로 빌드하면 전환 비용이 0입니다. 리전이 되면 m9g, 아니면 m8g입니다.
- 매니지드 서비스부터 바꿉니다: RDS·ElastiCache의 인스턴스 클래스 변경은 코드 수정 없이 단가만 내려갑니다. 가장 확실한 첫 절감입니다.
- 자체 워크로드는 의존성 스캔 후 파일럿을 돌립니다: arm64 미지원 의존성이 없는지 확인하고, 카나리아나 별도 노드 그룹으로 실측 성능·요금을 비교합니다.
- 혼용 기간을 설계합니다: 멀티 아치 이미지와 아키텍처 무관 배포 파이프라인을 갖추면 서비스 단위로 점진 전환할 수 있습니다. 한 번에 전부 옮길 필요가 없습니다.
- x86 잔류 목록을 명시적으로 관리합니다: 상용 바이너리·특정 명령어·Windows처럼 남는 이유를 기록해 두면, 벤더 지원이 생겼을 때 재검토할 수 있습니다.
정리 #
- 아키텍처를 정할 수 있는 워크로드는 Graviton이 기본값입니다. 시간당 10〜15% 싸고 가격 대비 성능 격차는 그보다 큽니다.
- 현재 기본값은 m8g(Graviton4)이고, 리전이 지원하면 2026년 6월 GA된 m9g(Graviton5)가 가격 대비 성능을 15%가량 더 얹습니다.
- 시작은 매니지드 서비스입니다. RDS·ElastiCache는 인스턴스 클래스 변경만으로 절감이 확정되고 호환성 리스크가 없습니다.
- 자체 워크로드의 관문은 네이티브 의존성과 멀티 아치 빌드입니다. 절차는 전환 체크리스트를 따르고, 파일럿 실측으로 확정합니다.
- Graviton 절감은 약정 없이 나오는 단가 인하라 RI·SP와 겹쳐 쓸 수 있습니다. x86 잔류는 호환성 사유가 있을 때만 남깁니다.