AWS Graviton5 C9g 인스턴스 비용 2026, ARM 전환 전 성능·운영 기준

AWS Graviton5 C9g 인스턴스 비용과 ARM 서버 전환을 검토하는 클라우드 운영팀 장면 — Graviton5 전환은 시간당 단가가 아니라 요청당 비용, 지연 시간, 운영 리스크를 같이 재야 한다.

AWS Graviton5 C9g 인스턴스 비용을 찾는 팀은 새 CPU가 빠른지보다 우리 워크로드에서 청구서가 줄어드는지 확인하려는 경우가 많다.

C9g와 C9gd는 Graviton5 기반 compute optimized 인스턴스라서 배치, 분석, 동영상 처리, CPU 기반 추론처럼 CPU가 병목인 작업에서 먼저 검토할 만하다.

다만 ARM 전환은 인스턴스 표 한 줄을 바꾸는 일이 아니며, 컨테이너 이미지, 라이브러리, 관측 지표, 구매 옵션까지 같이 움직인다.

AWS 공식 발표는 C9g가 이전 C8g보다 vCPU당 성능을 최대 25% 높이고 네트워크와 EBS 대역폭도 개선했다고 설명한다.

이 수치는 출발점일 뿐이고, 실제 비용 절감은 현재 x86 또는 C8g 환경의 요청당 비용과 장애 위험까지 비교해야 판단할 수 있다.

핵심 요약

AWS Graviton5 C9g 인스턴스 비용은 시간당 단가가 아니라 성능당 비용, 요청당 비용, 마이그레이션 비용으로 계산해야 한다.
C9g는 EBS 중심 compute workload에 맞고, C9gd는 로컬 NVMe 임시 저장소가 비용 또는 지연 시간을 줄일 때만 검토한다.
On-Demand로 벤치마크를 끝낸 뒤 Savings Plans, Spot, Dedicated 옵션을 workload별로 나눠야 구매 약정 리스크가 줄어든다.
ARM64 의존성, 벤더 에이전트, AMI, 보안 스캔, 롤백 경로가 준비되지 않으면 성능 수치가 좋아도 전환을 보류한다.

이 글이 필요한 사람

C8g, C7g, C6g 또는 x86 compute optimized 인스턴스에서 C9g 전환을 검토하는 클라우드 운영 담당자.
AWS Graviton5 C9g 인스턴스 비용을 FinOps 보고서에서 요청당 비용 기준으로 설명해야 하는 팀장.
C9gd의 로컬 NVMe가 EBS 비용과 지연 시간을 줄일지 판단해야 하는 데이터·미디어 처리 팀.
ARM64 빌드, 컨테이너 이미지, 보안 에이전트, 관측 도구 호환성을 점검해야 하는 플랫폼 엔지니어.
Savings Plans 약정 전에 새 인스턴스 패밀리의 실제 사용량과 리전 가용성을 확인하려는 구매 담당자.

검색 의도 정리: C9g 비용은 가격표보다 전환 비용이 먼저다

AWS Graviton5 C9g 인스턴스 비용이라는 검색어에는 두 가지 질문이 섞여 있다.

첫째는 C9g가 C8g 또는 x86 인스턴스보다 성능당 비용이 낮은지이고, 둘째는 ARM64 전환에 드는 운영 비용이 그 차이를 지우지 않는지다.

On-Demand 가격표만 보면 첫 질문 일부는 답할 수 있지만 두 번째 질문은 놓치기 쉽다.

컨테이너 이미지를 다시 빌드하고, 네이티브 라이브러리를 바꾸고, 모니터링 에이전트를 검증하고, 롤백 시나리오를 만드는 시간도 비용이다.

그래서 C9g 전환 판단은 시간당 가격 비교가 아니라 같은 부하에서 완료 요청 수, p95 지연 시간, 장애율, 운영 시간을 묶어 보는 방식이 맞다.

클라우드 비용 최적화 관점에서는 낮은 단가보다 안전하게 반복 측정할 수 있는 비용 모델이 더 중요하다.

C9g와 C9gd에서 공식적으로 확인할 수 있는 것

AWS News Blog와 C9g 제품 페이지 기준으로 C9g와 C9gd는 Graviton5 프로세서를 쓰는 compute optimized 계열이다.

AWS는 C9g가 Graviton4 기반 C8g보다 vCPU당 최대 25% 높은 성능을 제공한다고 설명한다.

또한 DDR5 8800MT/s 메모리, 더 큰 L3 캐시, 개선된 패킷 처리, Instance Bandwidth Configuration, ENA Express 지원을 발표했다.

가장 큰 48xlarge 크기는 최대 100Gbps 네트워크 대역폭과 최대 72Gbps EBS 대역폭을 제공한다고 공지됐다.

출시 시점의 가용 리전은 US East의 Ohio와 N.

Virginia, US West의 Oregon, Europe의 Frankfurt로 공지됐고 추가 리전은 뒤따를 수 있다.

항목	C9g	C9gd	비용 판단
저장소 구조	EBS 전용 구성.	로컬 NVMe SSD 포함.	임시 데이터가 많지 않으면 C9g가 단순하다.
대표 워크로드	배치, HPC, 분석, CPU 추론.	미디어 처리, 로그 처리, scratch 공간.	로컬 I/O가 병목일 때만 C9gd를 검토한다.
대역폭 관점	네트워크와 EBS 대역폭 개선.	로컬 SSD 지연 시간까지 추가.	EBS 비용과 로컬 SSD 운영 리스크를 같이 본다.
구매 옵션	On-Demand, Spot, Savings Plans 가능.	On-Demand, Spot, Savings Plans 가능.	약정 전에는 On-Demand 벤치마크가 먼저다.
운영 리스크	ARM64 호환성과 EBS 병목 점검.	인스턴스 종료 시 로컬 데이터 소실 점검.	백업과 재처리 비용을 계산한다.

C9gd의 로컬 NVMe는 빠르지만 지속 저장소가 아니므로 장애와 종료 시 데이터 보존 전제를 다시 설계해야 한다.

EBS 중심 구조에서 gp3 또는 io2 비용이 이미 최적화돼 있다면 C9gd가 항상 저렴하다고 단정하면 안 된다.

비용 계산식: 시간당 단가 대신 요청당 비용으로 본다

C9g 전환의 핵심 지표는 시간당 인스턴스 비용이 아니라 같은 시간에 처리한 안전한 작업량이다.

예를 들어 배치 작업이면 완료 job당 비용을 보고, API 서버이면 정상 요청 100만 건당 비용을 본다.

CPU 사용률이 낮은 서비스는 빠른 인스턴스로 바꿔도 비용이 줄지 않을 수 있다.

반대로 CPU가 병목이고 병렬화가 잘 되는 작업은 더 큰 처리량 때문에 같은 SLA를 더 적은 노드로 맞출 수 있다.

비용 항목	측정 방법	C9g 전환에서 볼 신호	주의점
EC2 사용량	인스턴스 시간과 purchase option.	동일 SLA에서 필요한 vCPU 수가 줄어드는지 본다.	리전별 가격과 가용성은 공식 가격표로 확인한다.
EBS 비용	볼륨 크기, IOPS, throughput.	C9g의 EBS 대역폭이 병목을 줄이는지 본다.	EBS 한계와 볼륨 한계를 같이 봐야 한다.
관측 비용	CloudWatch metrics, logs, traces.	벤치마크 로그가 production보다 커지는지 본다.	마이그레이션 기간 로그 비용을 따로 잡는다.
네트워크 비용	AZ 간 전송, 인터넷 전송, NAT.	대역폭 증가가 전송량 증가로 이어지는지 본다.	성능 향상과 데이터 전송 비용은 별도다.
전환 인건비	빌드 수정, 테스트, 보안 검토 시간.	ARM64 이슈가 반복되는지 본다.	1회성 비용도 약정 절감액에서 차감한다.

AWS EC2 On-Demand 가격은 초 또는 시간 단위 청구 조건과 운영체제 조건에 따라 달라진다.

정확한 C9g 단가는 발행 시점 이후 바뀔 수 있으므로 AWS Pricing Calculator와 공식 가격 페이지를 최종 기준으로 둔다.

AWS Graviton5 C9g 인스턴스 비용을 내부 보고서에 넣을 때는 표 가격, 측정 처리량, 전환 비용을 분리해야 숫자가 흔들리지 않는다.

실무 시나리오 1: CPU 바운드 배치 작업을 C9g로 옮기는 경우

첫 번째 시나리오는 매일 밤 도는 데이터 변환이나 영상 인코딩 job이 CPU 사용률 80% 이상으로 오래 머무는 경우다.

이 조건이면 검토한다: job 시간이 길고, I/O 대기보다 CPU 사용률이 높으며, 동일 입력 데이터로 반복 벤치마크를 만들 수 있다.

이 경우는 보류한다: 라이브러리의 ARM64 바이너리가 불안정하고, 실패한 job 재처리 비용이 인스턴스 절감액보다 클 가능성이 있다.

현재 인스턴스에서 job당 EC2 시간, EBS 처리량, 실패율, 평균 재시도 횟수를 2주 이상 저장한다.
동일 AMI 계열 또는 동일 컨테이너 이미지의 ARM64 빌드가 가능한지 먼저 확인한다.
C9g와 현재 인스턴스를 On-Demand로 나란히 띄우고 동일 입력 데이터로 warmup과 steady state를 분리한다.
완료 job당 비용, p95 처리 시간, 오류율, 재시도 비용을 같은 표에 넣는다.
Savings Plans 적용은 벤치마크가 끝나고 30일 실제 사용량이 쌓인 뒤 결정한다.

배치 작업은 Spot 후보가 될 수 있지만 checkpoint와 재시도 설계가 없으면 저렴한 인스턴스가 더 비싼 실패로 바뀐다.

C9g 전환의 승패는 CPU 성능보다 재처리 비용과 롤백 시간을 같이 줄였는지에서 갈린다.

실무 시나리오 2: C9gd 로컬 NVMe로 로그 처리 비용을 줄이는 경우

두 번째 시나리오는 로그 정규화, 임시 정렬, 미디어 transcode처럼 scratch 공간을 많이 쓰는 파이프라인이다.

이 조건이면 검토한다: 임시 파일이 크고 수명이 짧으며, EBS IOPS 또는 throughput 비용이 월별 청구서에서 눈에 띈다.

이 경우는 보류한다: 중간 결과를 잃으면 재처리가 어렵고, 인스턴스 교체나 중단 때 데이터 복구 절차가 없다.

C9gd의 NVMe는 고속 임시 저장소로 보고 영구 데이터는 S3, EBS, 데이터베이스에 남긴다.
노드 종료와 장애를 가정해 scratch 파일 재생성 시간이 SLA 안에 들어오는지 확인한다.
EBS 비용 절감액에서 로컬 데이터 재처리 시간과 운영 자동화 비용을 뺀다.
CloudWatch와 nvme-cli 관측값을 같이 남겨 I/O 크기별 지연 시간과 queue depth를 본다.
운영팀이 인스턴스 교체를 자동화하지 못하면 C9g와 EBS 조합이 더 안전할 수 있다.

C9gd는 빠른 저장소가 필요한 팀에 유용하지만 모든 데이터를 로컬에 두라는 의미는 아니다.

임시 저장소가 비용을 줄이는 조건과 데이터 소실 리스크를 견디는 조건이 동시에 맞아야 한다.

마이그레이션 순서: ARM64 호환성부터 확인한다

AWS Graviton Getting Started 저장소는 언어별, 컨테이너별, 운영체제별 전환 고려사항을 정리한다.

C9g도 같은 ARM64 전환 원칙을 따른다.

가장 먼저 볼 것은 CPU 성능이 아니라 빌드 체인과 런타임이 arm64를 안정적으로 지원하는지다.

운영체제, AMI, 컨테이너 base image, 패키지 저장소가 arm64를 지원하는지 확인한다.
Java, Go, Node.js, Python, .NET, Rust처럼 사용 언어별 네이티브 의존성과 최소 버전을 점검한다.
CI에서 amd64와 arm64 이미지를 분리 빌드하고 secret scan과 unit test를 양쪽에서 실행한다.
벤더 모니터링 에이전트, 보안 에이전트, APM, 로그 collector가 arm64를 지원하는지 확인한다.
production 전환은 canary, partial traffic, rollback to previous family 순서로 작게 나눈다.
성능이 낮게 나오면 인스턴스를 키우기 전에 프로파일링과 컴파일러 옵션을 먼저 확인한다.

마이그레이션 체크리스트가 없는 상태에서 C9g를 바로 Auto Scaling 그룹에 넣으면 장애 원인을 인스턴스 문제로만 오해하기 쉽다.

실제로는 의존성, JIT warmup, 암호화 라이브러리, compression 설정, thread pool 값이 성능 차이를 만들 수 있다.

Savings Plans와 Spot: 벤치마크 전 약정은 늦춘다

C9g와 C9gd는 On-Demand, Spot Instances, Savings Plans 같은 구매 옵션을 검토할 수 있다.

그러나 새 패밀리를 처음 쓰는 시점에는 약정 할인보다 workload 적합성 검증이 먼저다.

Compute Savings Plans는 유연성이 있지만 사용량 약정을 만들고, EC2 Instance Savings Plans는 특정 인스턴스 패밀리와 리전 선택이 더 중요해진다.

구매 방식	먼저 쓰는 상황	C9g 비용 효과	리스크
On-Demand	초기 벤치마크와 canary.	약정 없이 실제 처리량을 확인한다.	장기 운영에는 단가가 높을 수 있다.
Compute Savings Plans	여러 서비스와 리전에 compute 사용량이 넓다.	C9g 전환 실패 시 다른 compute로 흡수 가능하다.	예상 사용량을 과하게 잡으면 낭비가 된다.
EC2 Instance Savings Plans	C9g 계열 사용량이 확정됐다.	패밀리 단위 절감률을 노릴 수 있다.	리전과 패밀리 선택이 틀리면 유연성이 낮다.
Spot Instances	중단 허용 batch와 queue worker.	일부 작업의 단기 비용을 낮출 수 있다.	중단 처리와 재시도 비용이 없으면 위험하다.
Dedicated 옵션	규제와 라이선스 요구가 명확하다.	격리 요구를 만족할 수 있다.	비용 절감 목적과는 다르게 움직일 수 있다.

AWS Graviton5 C9g 인스턴스 비용을 줄이려면 purchase option을 기술 검증 뒤에 붙여야 한다.

먼저 약정을 잡고 나중에 ARM64 문제가 발견되면 할인율보다 미사용 약정이 더 큰 비용이 될 수 있다.

보안과 운영 리스크: 빠른 CPU가 승인 절차를 대신하지 않는다

C9g 제품 페이지는 Graviton5가 메모리 암호화, vCPU 전용 캐시, pointer authentication 같은 보안 기능을 제공한다고 설명한다.

AWS Nitro System도 가상화 기능을 전용 하드웨어와 경량 hypervisor로 분리해 격리와 성능을 제공하는 구조로 설명된다.

그렇더라도 인스턴스 보안 기능이 애플리케이션 권한, 패치, 비밀값 관리, 공급망 검증을 자동으로 해결하지는 않는다.

리스크	비용 영향	운영 기준	보안 기준
ARM64 미지원 에이전트	장애 감지와 로그 수집 공백이 생긴다.	벤더 지원 목록을 전환 전 확인한다.	보안 에이전트 누락 시 production 차단.
AMI와 패키지 차이	재현 불가 장애와 패치 지연이 생긴다.	이미지 provenance와 patch baseline을 고정한다.	서명과 취약점 스캔 결과를 보관.
로컬 NVMe 데이터	재처리와 복구 비용이 생긴다.	scratch 데이터만 저장한다.	민감 데이터는 로컬 임시 저장 금지.
관측 지표 변경	성능 저하를 늦게 발견한다.	p95, saturation, error budget을 양쪽에서 비교한다.	로그에 secret이 남지 않게 필터 적용.
롤백 지연	장애 시간이 절감액을 초과한다.	이전 인스턴스 패밀리로 돌아가는 runbook을 만든다.	권한 상승 변경은 별도 승인.

비용 절감을 이유로 승인 단계를 줄이면 ARM64 전환 문제가 보안 사고나 긴 장애로 확대될 수 있다.

C9g 전환은 성능 테스트와 보안 검토가 같은 변경 티켓 안에 들어갈 때 운영 부담이 작다.

정책 스켈레톤: C9g 파일럿을 비용 실험으로 관리하기

아래 YAML은 실제 AWS 설정 파일이 아니라 C9g 파일럿을 승인하기 위한 내부 기준 예시다.

핵심은 성능 목표, 비용 항목, ARM64 호환성, 보안 요구, 롤백 기준을 한 문서에서 같이 보는 것이다.

# graviton5-c9g-cost-pilot.yaml
# 목적: C9g/C9gd 전환을 가격표 비교가 아니라 성능·운영·보안 검증으로 통제한다.
# 실제 리전, 계정, 예산, 인스턴스 크기, 승인자는 조직 정책에 맞게 바꾼다.

owner:
  application: checkout-api
  platform: cloud-platform
  finops: cloud-cost-owner
  security: cloud-security-reviewer

scope:
  source_architecture: x86_64
  target_architecture: arm64
  candidate_instances:
    - c9g.4xlarge
    - c9g.8xlarge
    - c9gd.4xlarge
  launch_regions:
    - us-east-1
    - us-east-2
    - us-west-2
    - eu-central-1

benchmark_gate:
  warmup_minutes: 15
  steady_state_minutes: 60
  compare_against:
    - current_x86_instance
    - current_graviton4_c8g
  pass_when:
    p95_latency_regression_percent_max: 3
    error_rate_delta_percent_max: 0.2
    throughput_per_vcpu_improvement_required: true
    cost_per_request_lower_or_equal: true

cost_boundary:
  include:
    - ec2_instance_hours
    - ebs_volume_iops_throughput
    - data_transfer
    - cloudwatch_metrics_logs
    - ci_build_minutes_for_arm64
    - migration_engineering_hours
  purchase_model_tests:
    - on_demand_baseline
    - compute_savings_plans
    - ec2_instance_savings_plans
    - spot_for_batch_only

operations_gate:
  require_arm64_container_image: true
  require_dependency_compatibility_report: true
  require_rollback_to_previous_instance_family: true
  require_observability_dashboard: true
  require_capacity_and_quota_check: true

security_gate:
  require_ami_provenance: true
  require_ssm_patch_baseline: true
  require_secret_scan_in_arm64_build: true
  require_nitro_and_ebs_encryption_review: true
  block_if_vendor_agent_missing_arm64_support: true

이런 기준 없이 벤치마크를 시작하면 가장 좋은 결과만 보고 약정 구매로 넘어가기 쉽다.

FinOps 담당자는 YAML의 cost_boundary 항목을 실제 태그, 예산, 청구서 카테고리와 연결해야 한다.

점검 스크립트: 같은 조건으로 C9g 벤치마크를 반복하기

아래 Bash 스켈레톤은 바로 운영에 넣는 코드가 아니라 측정 흐름을 고정하기 위한 출발점이다.

실제 환경에서는 AMI, VPC, 부하 도구, 보안 그룹, IAM 권한, 비용 태그를 조직 기준에 맞게 바꿔야 한다.

#!/usr/bin/env bash
# graviton5-c9g-benchmark-skeleton.sh
# 목적: C9g/C9gd 전환 전 동일한 부하·동일한 관측값으로 비용당 처리량을 비교한다.
# 실제 AMI, VPC, 부하 도구, 태그, 리전은 조직 환경에 맞춰 채운다.

set -euo pipefail

REGION="${AWS_REGION:-us-east-1}"
CURRENT_INSTANCE="${CURRENT_INSTANCE:-c8g.4xlarge}"
TARGET_INSTANCE="${TARGET_INSTANCE:-c9g.4xlarge}"
AMI_ID="${AMI_ID:?set arm64 compatible AMI id}"
SUBNET_ID="${SUBNET_ID:?set subnet id}"
SECURITY_GROUP_ID="${SECURITY_GROUP_ID:?set security group id}"
KEY_NAME="${KEY_NAME:-}"
RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)"

launch_instance() {
  local name="$1"
  local instance_type="$2"
  aws ec2 run-instances     --region "$REGION"     --image-id "$AMI_ID"     --instance-type "$instance_type"     --subnet-id "$SUBNET_ID"     --security-group-ids "$SECURITY_GROUP_ID"     --tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value=$name},{Key=CostTest,Value=graviton5-c9g},{Key=RunId,Value=$RUN_ID}]"     --query 'Instances[0].InstanceId'     --output text
}

collect_metrics() {
  local instance_id="$1"
  local label="$2"
  echo "collect CloudWatch, app latency, throughput, and error-rate metrics for ${label}/${instance_id}"
  echo "export cost per request = instance hours + EBS + network + observability cost divided by completed requests"
}

CURRENT_ID="$(launch_instance graviton-cost-current "$CURRENT_INSTANCE")"
TARGET_ID="$(launch_instance graviton-cost-target "$TARGET_INSTANCE")"

trap 'aws ec2 terminate-instances --region "$REGION" --instance-ids "$CURRENT_ID" "$TARGET_ID" >/dev/null || true' EXIT

aws ec2 wait instance-running --region "$REGION" --instance-ids "$CURRENT_ID" "$TARGET_ID"
echo "run identical warmup and steady-state load against current and target instances"
collect_metrics "$CURRENT_ID" current
collect_metrics "$TARGET_ID" target
echo "compare p95 latency, throughput per vCPU, error rate, and cost per request before rollout"

중요한 것은 C9g만 좋은 조건으로 돌리고 현재 인스턴스는 낡은 조건으로 두지 않는 것이다.

warmup, steady state, 로그 수집 범위, 테스트 데이터, 실패 처리 기준이 같아야 비용당 성능 비교가 의미를 갖는다.