EC2 Graviton 전환: 절감 폭과 이전 체크리스트

인스턴스 단가를 구조적으로 낮추는 가장 큰 레버는 Graviton 전환입니다. Graviton은 AWS가 직접 설계한 arm64 CPU로, 동급 x86 인스턴스보다 시간당 단가가 대체로 20% 안팎 낮고, 세대에 따라 성능까지 감안한 가격 대비 성능은 최대 40%까지 벌어집니다. 전편들이 낭비를 줄이는 쪽이었다면, 이 글은 같은 일을 더 싼 단가로 하는 쪽입니다. “우리 워크로드도 옮길 수 있나?“에 답하는 체크리스트로 정리했습니다.

세대 현황: 무엇을 고를 것인가 #

2026년 중반 기준 상황은 이렇습니다.

Graviton5는 Graviton4 대비 컴퓨팅 성능이 최대 25% 높다고 발표됐지만, 이전을 시작하는 입장에서 세대 선택은 부차적인 문제입니다. arm64로 옮기는 작업 자체는 세대와 무관하므로, 일단 옮기면 이후 세대 교체는 인스턴스 타입 변경만으로 끝납니다. 신규 전환이라면 가용 리전과 가격을 보고 Graviton4 계열을 기본값으로 잡으면 됩니다. 버스터블이 필요한 개발 환경에는 t4g가 여전히 가성비 좋은 선택입니다.

전환 난이도: 워크로드별 감각 #

전환의 본질은 하나입니다. arm64에서 돌아가는 바이너리를 준비할 수 있는가?

• 쉬움(인터프리터·VM 언어): Python, Node.js, Ruby, PHP, JVM(Java·Kotlin) 애플리케이션은 런타임만 arm64용이면 코드 변경이 거의 없습니다. 최신 배포판의 패키지 저장소는 arm64를 기본 지원합니다.
• 보통(네이티브 의존성이 있는 경우): Python의 C 확장, Node의 네이티브 모듈은 대부분 arm64 휠·프리빌드가 있지만, 오래된 핀 버전이 발목을 잡을 수 있습니다. 재빌드로 해결되는지 CI에서 먼저 확인합니다.
• 직접 확인(자체 네이티브 코드, 서드파티 에이전트): Go·Rust는 크로스 컴파일이 쉬운 편이고, C/C++는 SIMD 인트린식(AVX 계열)을 썼다면 NEON/SVE로의 포팅 여부를 봐야 합니다. APM·보안 에이전트 같은 서드파티 바이너리는 벤더의 arm64 지원을 확인합니다. 주요 벤더는 대부분 지원하지만, 사내에 오래 굴러온 에이전트가 복병이 됩니다.
• 불가(x86 전용 상용 소프트웨어): 벤더가 arm64 빌드를 제공하지 않으면 그 워크로드는 대상에서 제외합니다. 전부 옮길 필요는 없습니다.

이전 체크리스트 #

실제 순서는 다음과 같습니다.

1. 의존성 인벤토리: 애플리케이션의 네이티브 의존성, 베이스 이미지, 설치하는 에이전트를 나열하고 arm64 지원을 확인합니다. 여기서 막히는 항목이 없으면 절반은 끝났습니다.
2. 멀티 아키텍처 이미지 빌드: 컨테이너 워크로드라면 docker buildx로 amd64·arm64를 한 태그에 묶습니다. 빌드 방법은 도커 고급 #2에서 다뤘습니다. CI 러너가 x86이면 에뮬레이션 빌드가 느리므로, arm64 네이티브 러너(GitHub Actions의 arm64 러너, CodeBuild의 Graviton 환경)를 쓰는 편이 빠릅니다.
3. 스테이징에서 기능·성능 검증: 기능 테스트에 더해 부하 테스트로 p99 지연과 처리량을 x86 기준선과 비교합니다. 대부분 동등하거나 낫지만, 워크로드 특성에 따라 다르므로 실측이 기준입니다.
4. 카나리 전환: ASG나 EKS 노드 그룹에 arm64 노드를 소수 섞어 실트래픽 일부를 받게 합니다. 컨테이너 오케스트레이터는 이미지가 멀티 아키텍처면 노드 아키텍처에 맞는 쪽을 알아서 당깁니다. 문제가 없으면 비율을 올려 완전 전환합니다.
5. 매니지드 서비스로 확대: EC2보다 쉬운 대상이 많습니다. RDS·Aurora·ElastiCache는 인스턴스 클래스를 g 계열로 바꾸는 것으로 끝나고(애플리케이션 변경 없음), Lambda는 함수 아키텍처를 arm64로 바꾸면 실행 단가가 20% 낮아집니다. Fargate도 arm64를 지원합니다. 오히려 이쪽부터 시작해 감을 잡는 것도 좋은 순서입니다.

자주 걸리는 함정 #

• 오래된 AMI·커스텀 AMI 파이프라인: x86 AMI를 굽던 Packer 템플릿 등을 arm64용으로 복제해야 합니다. 소스 AMI ID가 아키텍처별로 다릅니다.
• 락 파일에 고정된 x86 전용 휠: lock 파일이 x86 휠 해시를 고정하고 있으면 arm64 설치가 소스 빌드로 빠지며 느려지거나 실패합니다. 멀티 플랫폼 lock으로 재생성합니다.
• “성능이 같겠지"라는 가정: 대부분의 웹·API 워크로드는 동등 이상이지만, 특정 라이브러리가 x86 SIMD에 최적화돼 있으면 역전됩니다. 3단계의 실측을 건너뛰지 않습니다.
• 혼합 운영 기간의 이미지 태그 실수: 전환 기간에는 amd64 단일 이미지가 arm64 노드에 배포되는 사고가 나기 쉽습니다. 멀티 아키텍처 매니페스트를 기본으로 강제하면 예방됩니다.

절감 폭을 계산하는 법 #

전환 효과는 “단가 차이 × 옮긴 비중"입니다. 온디맨드 단가는 같은 세대의 x86 대비 대체로 20% 안팎 낮고, 여기에 Savings Plans를 겹치면 할인이 곱해집니다. 주의할 점 하나는 EC2 Instance Savings Plans가 인스턴스 패밀리에 묶인다는 것입니다. 전환 계획이 있다면 패밀리를 고정하는 약정보다 Compute Savings Plans처럼 아키텍처가 바뀌어도 유지되는 약정이 안전합니다. 약정 구조는 SAA Domain 4-1에서 다뤘습니다.

정리 #

• Graviton 전환은 동급 x86 대비 단가 약 20%를 구조적으로 낮추는 레버이고, 한 번 arm64로 옮기면 이후 세대 교체(현재 주력 Graviton4, Graviton5 GA)는 타입 변경만으로 끝납니다.
• 관건은 arm64 바이너리 준비입니다. 인터프리터·JVM 계열은 쉽고, 네이티브 의존성과 서드파티 에이전트가 확인 지점입니다.
• 순서는 의존성 확인 → 멀티 아키텍처 이미지 → 스테이징 실측 → 카나리 → 확대입니다. 실측을 건너뛰지 않습니다.
• RDS·ElastiCache·Lambda는 EC2보다 전환이 쉽습니다. 감을 잡는 출발점으로도 좋습니다.
• 전환 계획이 있으면 패밀리 고정 약정 대신 Compute Savings Plans를 선택합니다.