[AWS 비용] AWS 인프라 비용 55% 절감 가이드 (Graviton 전환 및 고정비 최적화 전략)

 2024년부터 2026년 상반기까지 본부 및 팀 내 인프라를 직접 설계하고 구축하며 가장 집중한 것은 '불필요한 클라우드 지출을 최소화하면서도 견고한 아키텍처를 그려내는 것'이었습니다.

 특히 이번 포스팅에서는 AWS Graviton(ARM) 아키텍처를 전략적으로 활용하고, ALB, NAT Gateway, RDS와 같은 관리형 서비스를 직접 구축형으로 전환하여 기존 대비 운영비를 최대 55%(월 약 200만 원)까지 낮춘 실제 견적 데이터와 노하우를 상세히 공유하고자 합니다. 인프라 효율성을 고민하는 엔지니어분들에게 실질적인 가이드가 되길 바랍니다.

 

1. 2026년 AWS EC2 인스턴스 단가 비교 (서울 리전 기준) - 최신화 버전

 아래 표는 아시아 태평양(서울) 리전, Ubuntu 24.04 LTS (HVM) 기준으로 작성된 온디맨드 요금표입니다. CPU 아키텍처 선택 하나만으로 얼마나 큰 비용 차이(약 20%)가 발생하는지 확인 가능합니다.

반응형

인스턴스 유형	vCPUs	CPU 아키텍처	Mem	Storage	네트워크 성능	EC2 (per hour)	per month (30d)	per year (12 M)
m6g.large	2v CPU	Arm	8 GiB	EBS Only	Up to 10 Gigabit	$0.094	$67.68	$812.16
t4g.xlarge	4v CPU	Arm	16 GiB	EBS Only	Up to 5 Gigabit	$0.1664	$119.81	$1,437.70
t4g.medium	2v CPU	Arm	4 GiB	EBS Only	Up to 5 Gigabit	$0.0416	$29.95	$359.42
t2.micro	1v CPU	x86	1 GiB	EBS Only	Low to Moderate	$0.0144	$10.37	$124.42
r6g.large	2v CPU	Arm	16 GiB	EBS Only	Up to 10 Gigabit	$0.1220	$87.84	$1,054.08
r6g.xlarge	4v CPU	Arm	32 GiB	EBS Only	Up to 10 Gigabit	$0.2440	$175.68	$2,108.16
r5a.xlarge	4v CPU	x86	32 GiB	EBS Only	Up to 10 Gigabit	$0.2720	$195.84	$2,350.08
r6gd.xlarge	4v CPU	Arm	32 GiB	1 x 237 NVMe SSD	Up to 10 Gigabit	$0.2768	$199.30	$2,391.55
r5.xlarge	4v CPU	x86	32 GiB	EBS Only	Up to 10 Gigabit	$0.3040	$218.88	$2,626.56
r6g.xlarge	4v CPU	Arm	32 GiB	EBS Only	Up to 10 Gigabit	$0.2440	$175.68	$2,108.16
r6g.2xlarge	8v CPU	Arm	64 GiB	EBS Only	Up to 10 Gigabit	$0.4880	$351.36	$4,216.32

 

아키텍처만 바꿔도 월 $43.2가 절감됩니다.

 위의 단가표를 정밀 분석해 보면, CPU, Memory, Storage, Network 스펙이 완전히 동일함에도 불구하고 아키텍처 선택에 따라 약 20%의 가격 차이가 발생하는 것을 확인할 수 있습니다.

항목	r5.xlarge (x86 아키텍처)	r6g.xlarge (Arm 아키텍처)	차이 (Savings)
vCPU / Mem	4 vCPU / 32 GiB	4 vCPU / 32 GiB	동일
Storage / Network	EBS / Up to 10Gbps	EBS / Up to 10Gbps	동일
월 운영 비용 (30일)	$218.88	$175.68	-$43.2 (약 20% 절감)

 

 

그림 1 아키텍처(x86) 설정 시 ARM 인스턴스 선택이 제한되는 모습

 참고로 온디맨드 인스턴스 요금표를 봐도 CPU 아키텍처는 나오지 않습니다. 해당 표는 직접 인스턴스를 생성할때 확인할 수 있습니다. 예를 들어, 아키텍처를 64비트(x86)으로 해놓고 r6gd.xlarge 인스턴스 유형을 고를려고 하면 비활성화 되는 모습을 볼 수 있을 것입니다.

 

2. 용도별 인스턴스 패밀리 선택 전략

비용 절감과 동시에 인스턴스 유형의 패밀리를 알맞게 사용해야 합니다.

 

• t 패밀리 (버스트 가능): 소규모 워크로드에 최적입니다. CPU 크레딧을 사용하여 간헐적인 트래픽 폭주를 저렴하게 처리합니다.
• m 패밀리 (다목적): CPU, 메모리, 네트워크 성능의 균형이 필요할 때 선택합니다. 고정 성능을 제공하며 안정적인 WAS 운영에 적합합니다.
• r 패밀리 (메모리 최적화): DB, 캐시(Redis), 대규모 데이터 분석 등 메모리 집약적 작업에 필수입니다. 특히 ARM 기반의 r6g는 x86 대비 압도적인 가성비를 자랑합니다.

 

 

3. 관리형 서비스(SaaS) 대신 직접 구축을 통한 고정비 방어

 인프라 역량이 뒷받침된다면 관리형 서비스를 직접 구축형으로 대체하여 고정비를 대폭 줄일 수 있습니다

 

3.1 ALB 대신 Nginx Reverse Proxy 활용 :  월 $16.43 절감

 ALB는 편리하지만 트래픽이 없어도 고정비가 발생합니다. 저는 Bastion 서버에 Nginx를 설치하고 Certbot(SSL)을 적용하여 직접 라우팅을 설정함으로써 ALB 비용을 완전히 제거했습니다.

 

3.2 NAT Gateway 대신 NAT Instance 구축 : 월 $33.75 절감

 Private Subnet의 외부 통신을 돕는 NAT Gateway는 시간당 요금이 비쌉니다. Bastion 서버를 NAT Instance로 구성하여 운영하면, 데이터 처리 비용을 포함해 약 월 $33.75를 절약할 수 있습니다. (한달에 약 30GB의 데이터를 처리 가정)

 

• NAT 게이트웨이당 요금(USD/시간) : USD 0.045
• 처리된 데이터 GB당 요금 (USD): USD 0.045

 

참고: NAT 인스턴스 구축 상세 가이드는 저의 이전 포스팅(1편/2편)을 참고하세요.

 

AMI를 통한 NAT Instance 구축 (1편)

[AWS 인프라] NAT Gateway 비용 절감을 위한 AMI로 NAT 인스턴스 구축 및 설정 (1부)

 

직접 Linux IP Tables를 조작하여 Instance 구축 (2편) : 설정은 1편에 있으므로 1편 설정 이후 2편 참조해주세요

[AWS 인프라] NAT Gateway 비용 절감을 위한 NAT 인스턴스 구축 및 설정 (2부)

 

3.3 Route53 Domain 비용 .com 기준으로 약 $14.51발생 

• Route53: Domain 고정비는 줄이기 어렵기 때문에, 가장 큰 비중을 차지하는 EC2에서나 ALB, NAT Gateway등에서 고정비용을 줄이는 것을 효율적으로 선택하시면 됩니다. 아니면 좀 더 싼 도메인 사이트에 가서 사오시면 됩니다.

 

4. RDS 리스크 관리 및 DB 직접 설치 전략

 Oracle RDS(db.m5.4xlarge 등)는 라이선스 포함 시 월 $2,800~$6,000에 달하는 막대한 비용이 발생합니다. 심지어 라이선스를 이미 보유하고 있는 기업(BYOL)이라 할지라도 RDS 운영 비용은 결코 만만치 않습니다 약$1,551.67 가 나옵니다. 저는 이를 최적화하기 위해 다음과 같은 전략을 선택했습니다.

• RDS 관리비 vs EC2 직접 구축: 이미 회사에 비축된 라이선스가 있다면, RDS에 지불하는 비용은 순수하게 '관리 대행료'입니다. 하지만 이 비용이 인스턴스 비용을 상회할 만큼 큽니다.
• Oracle RDS (BYOL)의 함정: 8vCPU, 32GiB RAM 사양을 기준으로 Standard Edition Two (SE2) 라이선스를 직접 가져와서(BYOL) 사용하더라도, AWS에 지불하는 RDS 관리 비용만 약 $1,551.67에 달합니다.
• ARM 기반 DB-EC2로의 전환: 저는 이 비용을 아끼기 위해 RDS 대신 8vCPU ARM, 64GiB RAM, 512GB Storage 사양의 EC2를 선택했습니다.
  • 월 운영비: $382.35 (EBS 스토리지 포함)
  • 결과: RDS 관리비 대비 약 75% 이상의 비용을 즉시 절감했습니다. 심지어 메모리는 RDS(32GiB)보다 2배 더 많은 64GiB를 확보하여 성능 이점까지 챙겼습니다.

 

5. 최종 비용 비교: 관리형 서비스 vs 직접 구축 (Monthly)

항목	수량	USD / Month	직접 구축 최적화 (USD)	관리형 서비스 중심 (USD)	비고
VPC (EIP)	1	21.9	✔	✔	공통 고정비
Route53 (Domain)	1	14.53	✔	✔	공통 고정비
EC2 (Service) ARM	5	175.68	✔	-	4v CPU ARM 32GiB
EC2 (Service) x86	5	218.88	-	✔	4v CPU ARM 32GiB
EC2 (Bastion)	1	66.4	✔	✔	관리형에서는 Bastion으로만 사용 (NAT, Proxy역할 X)
EC2 (DB)	1	382.35	✔	-
RDS (BYOL) Oracle	1	1,551.67	-	✔
NAT Gateway	1	33.75	-	✔	직접 구축형에서는 NAT Instnace로 대체
ALB	1	16.43	-	✔	직접 구축형에서는 Nginx Proxy로 대체
Total (USD/ Month)			1,263.58	2,799.08	차이 = 1,535.5 쵀대 약 55% 절약

 

결론: 효율적인 비용 감축의 선택

 모든 관리형 서비스를 포기하라는 의미가 아닙니다. 하지만 엔지니어의 역량을 활용해 선택적으로 비용을 감축(ARM 전환, NAT/Proxy 직접 구축, DB 직접 설치)한다면, 한정된 예산 안에서 훨씬 더 고성능의 아키텍처를 운영할 수 있습니다.

 월 약 $1,535(한화 약 200만 원)의 고정비 절감은 충분히 의미가 있으며, 이 또한 엔지니어링적인 측면에서 고려해야할 중요 요소라 생각합니다.

 

 

6. ARM 아키텍처 전환 시 주의사항: 호환성 문제와 사례

 비용을 절감하는 것도 중요하지만, 아키텍처 전환으로 인해 서비스가 중단되는 리스크는 반드시 피해야 합니다. 불과 몇 년 전까지만 해도 ARM 아키텍처는 호환성 문제로 인해 도입을 꺼리는 경우가 많았으나, 2026년 현재 대부분의 메이저 라이브러리와 OS에서 안정화가 이루어졌거나 진행중입니다.

 

제가 실무환경에서 겪은 문제 하나를 공유하고자 합니다.

Python - Oracle DB 연동 시 'DPI-1047' 에러

Python 기반 서비스를 ARM 인스턴스로 이전할 때 가장 흔히 겪는 문제는 드라이버 호환성입니다.

• 문제 상황: 기존 x86 환경에서 사용하던 cx_Oracle 라이브러리를 ARM 환경에서 그대로 사용하면 DPI-1047 에러가 발생하며 DB 연결에 실패합니다. 이는 해당 라이브러리가 특정 C 라이브러리 의존성을 가지고 있기 때문입니다.
• 해결 방법: Oracle 인스턴트 클라이언트 설치가 필요 없는 python-oracledb Thin 모드를 사용해야 합니다. Thin 모드는 C 라이브러리 의존성 없이 순수 Python으로 작동하므로 ARM 아키텍처에서도 완벽하게 동작합니다.

 만약, 현재 Python 서비스를 운영 중이고 cx_Oracle을 사용하고 계시다면, 아래 상세 해결 가이드 포스팅을 통해 시행착오를 줄이시길 바랍니다.

 

OracleDB - Python 연동시 발생한 문제 (DPI-1047)

[SQLAlchemy] AWS Graviton(ARM)에서 Python Oracle DB 연결 오류 DPI-1047 해결 | SQLAlchemy, oracledb

 

---

참고자료 AWS 공식 사이트 자료

1. AWS 온디맨드 인스턴 (https://aws.amazon.com/ko/ec2/pricing/on-demand/)

EC2 온디맨드 인스턴스 요금

 

2. AWS VPC 요금 (https://aws.amazon.com/ko/vpc/pricing/)

Amazon VPC 요금