💸 AWS EC2 비용 최적화 실전 가이드: 불필요한 지출을 구조적으로 줄이는 방법

[cloudbro-radar]

AWS EC2를 사용하면서 비용이 지속적으로 증가하는데, 어떤 인스턴스가 낭비되고 있는지? 어디서 비용 최적화가 가능한지? 명확히 파악하지 못하는 상황이 발생하는 경우가 있습니다.

원인 분석

• EC2 비용 증가의 주요 원인은 다음과 같이 구조적으로 반복됩니다.
  • Idle / Underutilized 인스턴스: 사용률이 낮거나 거의 사용되지 않음
  • 잘못된 인스턴스 사이징: 실제 워크로드 대비 과도한 스펙
  • 온디맨드 위주의 사용: Savings Plan, Reserved Instance 미활용
  • 가시성 부족: 리소스, 비용, 사용 패턴을 한눈에 보기 어려움

해결 방안

• EC2 비용 절감을 위해 다음과 같은 접근이 있습니다.
  • 리소스 가시성 확보 → EC2, EBS, 네트워크 비용을 시각적으로 파악
  • 불필요한 리소스 식별 및 제거 → Idle 인스턴스, 미사용 볼륨 정리
  • Right-sizing 전략 → CPU / Memory 사용률 기반 인스턴스 재조정
  • • 비용 최적화 옵션 활용 → Reserved Instances, Savings Plans, Spot Instances 검토

실행 우선순위

우선순위	실행 항목	선정 기준
1	Idle EC2 식별 및 종료	즉각적인 비용 절감
2	Right-sizing 적용	리스크 대비 효과 큼
3	RI / Savings Plan 검토	중장기 비용 절감
4	시각화 도구 도입	지속적 관리 가능성

[출처] AWS EC2 Cost Optimization: Complete Guide (2025)

전문 번역 내용 (아래)

AWS EC2 비용 최적화: 완벽 가이드

EC2 비용은 일반적으로 가격 책정 모델, 인스턴스 선택, 낭비 제어라는 세 가지 레버로 귀결됩니다. 이 완벽 가이드에서는 무엇을 확인해야 하는지, 어떻게 안전하게 문제를 해결하는지, 그리고 수동 또는 자동화를 통해 동일한 문제가 재발하지 않도록 하는 방법을 보여줍니다.

체크리스트

• 퍼블릭 IPv4 / 탄력적 IP (Elastic IPs) — 필요하지 않은 것은 제거하고, 프라이빗 + NAT/ALB 또는 IPv6를 선호하세요. (아래의 자세한 해결 방법 참조.)
• 연결되지 않은/유휴 EBS 볼륨 — 필요한 경우 스냅샷을 생성한 다음 삭제하거나 크기를 줄이세요. (아래의 자세한 해결 방법 참조.)
• 유휴 ALB/NLB — 활성 대상/경로가 없는지 확인한 다음 삭제하세요. (아래의 자세한 해결 방법 참조.)
• 트래픽이 적은 NAT 게이트웨이 — 폐기하거나 재설계하고, AZ 간 통합을 피하세요. (아래의 자세한 해결 방법 참조.)

• 팁: 연결 해제된 EIP, 연결되지 않은/유휴 EBS, 유휴 로드 밸런서(LB), 유휴/트래픽이 적은 NAT 게이트웨이를 표면화하고 클릭 한 번으로 수정(EIP 릴리스, 볼륨/스냅샷/LB/NAT 삭제)할 수 있는 규칙+자동화 뷰를 사용하세요. Hyperglance는 이러한 정확한 검사 및 작업을 제공합니다.

90초 만에 보는 EC2 가격 책정 (2025 기준)

모델	적합한 용도	장점	주의 사항
온디맨드 (On-Demand)	예측 불가능하거나 수명이 짧은 경우	약정 없음	24x7 지속적인 사용 시 가장 비쌈
Savings Plans (Compute/EC2)	꾸준하지만 변화하는 경우	광범위한 적용 범위, 유연성	1~3년 동안 시간당 금액($/hour) 약정
예약 인스턴스 (Reserved Instances - 영역/리전)	수명이 길고 안정적인 경우	더 깊은 할인, 용량 예약	SP보다 유연성이 떨어짐
스팟 (Spot)	중단 가능 (배치, CI/CD, ML 학습)	가장 큰 할인	2분 중단 알림; 재조정 자동화 필요

• 선택 방법 (경험 기반):

  • 정상 상태(“항상 켜져 있는” 베이스라인)를 측정하세요. 조직의 편안한 수준까지 Savings Plans (SP) / 예약 인스턴스 (RI)로 커버하세요. 중단 가능한/배치 작업에는 스팟(Spot)을 계층화하세요. 급증하는 나머지 부분은 온디맨드(On-Demand)로 남겨두세요.

• 팁: 적정 규모 조정(Right-sizing) 및 약정 계획을 비용 대시보드와 페어링하여 RI/SP로 커버할 항목과 온디맨드로 남겨둘 항목을 확인할 수 있습니다. Hyperglance에는 더 안전한 약정을 안내하기 위한 RI 권장 사항, 적정 규모 조정, 예산 및 태그가 지정된 지출 보기가 포함되어 있습니다.

올바른 인스턴스 유형 (및 세대) 선택

• 세 가지 일반적인 실수:

  • “만약을 대비해” vCPU/RAM을 과다 프로비저닝함.
  • 최신 세대를 무시함 (더 적은 성능에 더 많은 비용 지불).
  • 워크로드 요구 사항이 변경되었을 때 레거시 패밀리에 머무름 (예: 메모리 집약적 vs 컴퓨팅 집약적).

• 간단한 방법:
  대표적인 기간 동안의 CPU, 메모리, 네트워크 및 EBS 지표를 기준으로 삼으세요. 차세대 패밀리를 테스트하세요 (예: 호환되는 경우 m5에서 m7g/m7i 동급으로 이동). 성능을 검증하고, 동일하거나 더 나은 경우 Savings Plans (SP) / 예약 인스턴스 (RI)로 절감액을 확정하세요.

• 적정 규모 조정 101 (크기 사다리 & 예시)
  작은 개발/테스트 서비스의 경우 t3.micro는 t3.large보다 훨씬 저렴할 수 있으며, 새로운 AWS 계정(12개월 미만)에서는 t2.micro(또는 t2.micro를 사용할 수 없는 경우 t3.micro) 하나가 프리 티어 대상입니다(월 최대 750시간).

• 작게 시작하여 사용률(CPU/RAM/EBS 처리량)을 지켜보고 병목 현상에 따라 스케일 업(더 큰 크기)하거나 스케일 아웃(더 많은 인스턴스)하세요. 유휴 헤드룸에 비용을 지불하지 않으려면 적절한 경우 오토스케일링을 사용하세요. 항상 콘솔에서 프리 티어 자격을 확인하세요.

• 팁: 약정을 확정하기 전에 적정 규모 조정 패스를 실행하세요. Hyperglance는 적정 규모 조정 권장 사항과 약정 계획을 제공하므로 최신 패밀리를 시험해 본 다음 확신을 가지고 약정할 수 있습니다.

• 기타 고려 사항

  • 버스트 가능(t) 및 크레딧 수학: t-시리즈는 CPU 크레딧을 적립/소비합니다. 버스트가 있는 낮은 꾸준한 CPU의 경우 비용 효율적입니다. 크레딧이 고갈되면 비용이 상승하며, 특히 잉여 크레딧이 게시된 vCPU-시간당 요금으로 청구되는 무제한(Unlimited) 모드에서는 더욱 그렇습니다. CPUCreditBalance 및 예산 알림을 모니터링하세요. 스택이 ARM을 지원하는 경우 더 나은 가격/성능을 위해 t4g(Graviton)를 고려하세요.
  • 네트워크/스토리지 제약: 네트워크/EBS 대역폭이 더 높은 인스턴스를 선택하세요.
  • GPU/AI 워크로드: 학습의 경우 P5(H100) 또는 P4d(A100)를 고려하고, 추론/그래픽의 경우 G5/G6(A10G/L4급)를 고려하세요. 지원되는 경우 학습용 Trn1(Trainium) 및 추론용 Inf2(Inferentia)를 평가해 보세요. 종종 처리량당 비용($/throughput)이 더 낮습니다. 모델 크기에 맞춰 GPU 수와 메모리를 적정 규모로 조정하고, 70% 이상의 지속적인 GPU 사용률과 높은 메모리 점유율을 목표로 하세요.
  • 처리량 병목 현상: 가속기에 빠른 I/O를 공급하세요. 분산 학습을 위한 EFA, Lustre/S3 데이터 파이프라인을 위한 FSx, 적절한 EBS/인스턴스 NVMe를 사용하세요. 호스트 측 지연을 최소화하기 위해 데이터 로더와 배치 크기를 최적화하세요.
  • 용량 예약 및 가격 책정: 꾸준한 GPU 대기열의 경우 가용성을 확보하기 위해 Savings Plans/예약 인스턴스를 온디맨드 용량 예약과 결합하세요. 잦은 체크포인트와 자동 재조정이 있는 내결함성 작업에만 스팟(Spot)을 사용하세요.
  • 동일한 작업을 더 저렴하게: 프레임워크가 허용하는 경우 혼합 정밀도(FP16/bfloat16/FP8), 그라디언트 체크포인팅, 양자화(INT8/FP8)를 사용하여 GPU 시간과 메모리 요구 사항을 줄이세요.
  • AMD 대 Intel 가격/성능: AMD(m7a/c7a)는 많은 지역에서 유사한 Intel(m7i/c7i)보다 온디맨드 가격이 더 낮은 경우가 많습니다. 약정하기 전에 해당 지역/크기의 현재 가격을 확인하세요. 짧은 카나리아 배포로 검증하세요.
  • Graviton (ARM) 절감: 지원되는 경우 Graviton(arm64)은 x86/x64 대비 최대 ~40% 더 나은 가격/성능을 제공할 수 있습니다. 롤아웃 전에 멀티 아키텍처 빌드를 테스트하고 p95/p99를 측정하세요.

스팟, RI 및 Savings Plans를 책임감 있게 사용하기

• 스팟 (Spot): AWS는 최소 2분의 중단 알림으로 용량을 회수할 수 있으며, 이는 종종 수동으로 대응하기에 충분한 시간이 아닙니다. 중단에 대비해 설계하고(체크포인팅, 멱등성 작업, 다양한 풀), 신호가 일찍 도착했을 때 2분 타이머 전에 교체를 시작하기 위해 인스턴스 재조정 권장 사항(IMDS + EventBridge) 및 오토 스케일링의 용량 재조정을 사용하세요. 온디맨드 폴백(fallback)을 유지하세요.

• 최선의 노력 참고 사항: 재조정 신호는 2분 경고에 임박하여 도착할 수 있으므로 자동화가 사람의 개입보다 낫습니다.

• Savings Plans 대 RI:

  • SP는 더 유연합니다(특히 Compute SP). RI는 더 깊은 할인이나 용량 보장을 제공할 수 있습니다.
  • 과도하게 약정하지 마세요. 사용량의 피크가 아닌 알려진 꾸준한 부분만 커버하세요.

• 커버리지 접근 방식: 측정 → SP/RI로 꾸준한 부분 커버 → 중단 가능한 부분에 스팟 추가 → 분기별 검토.

낭비 해결 (단계별)

• 연결되지 않은/유휴 EBS 볼륨

  • 발견하기: 연결되지 않은 볼륨; 중지된 인스턴스에 연결된 볼륨; 사용량 대비 엄청나게 과도하게 프로비저닝된 gp3/io*.
  • 안전하게 수정하기: 스냅샷을 생성한 다음 삭제하거나 적정 규모로 조정하세요.
  • 방지하기: IaC + 이미지 파이프라인에서 합리적인 기본값 설정; DeleteOnTerminate=true 강제; N일 이상 연결되지 않은 경우 자동화 플래그 지정.

• 팁: 위생 루프를 자동화하세요. N일 동안 연결되지 않음/유휴 상태인 후 스냅샷 → 삭제/적정 규모 조정. Hyperglance에는 연결되지 않은/유휴 EBS에 대한 규칙과 볼륨 및 스냅샷을 삭제하는 작업이 포함되어 있습니다.

퍼블릭 IPv4 / 탄력적 IP (사용 중 또는 유휴)

• 발견하기: 계정의 모든 퍼블릭 IPv4(탄력적 IP)—연결됨 또는 유휴—는 비용을 발생시킵니다. 유휴 상태인 것은 가치가 없습니다.
• 안전하게 수정하기: 연결 해제된 EIP를 다시 연결하거나 해제(release)하세요. 워크로드에 실제로 퍼블릭 IPv4가 필요한지 검토하세요(ALB/NLB, NAT 또는 IPv6로 충분할 수 있음).
• 방지하기: 소유권과 목적 태그 지정; 연결 해제된 EIP 및 불필요한 퍼블릭 IPv4가 있는 리소스에 대한 알림; 지원되는 경우 IPv6 선호.

• 팁: 퍼블릭 IPv4의 실시간 인벤토리를 유지하고 드리프트를 자동 정리하세요. EIP가 연결 해제되면 유예 기간 후 이를 해제하는 자동화를 트리거하세요. Hyperglance는 해당 규칙과 탄력적 IP 해제 작업을 제공합니다.

유휴 ALB/NLB

• 발견하기: 등록된 대상 없음; 롤링 윈도우 동안 요청이 거의 0에 가까움.
• 안전하게 수정하기: DNS 및 상태 확인(health check)을 다시 확인한 다음 삭제하세요.
• 방지하기: X일 유휴 상태 후 폐기하는 수명 주기 규칙.

• 팁: ALB/NLB에 대상이 없거나 지속적으로 트래픽이 거의 0인 경우 변경 티켓을 제기하고 승인 시 자동으로 삭제하세요. Hyperglance에는 유휴/대상 없는 LB 규칙과 로드 밸런서 삭제 작업이 있습니다.

트래픽이 미미한 NAT 게이트웨이

• 발견하기: 처리된 바이트가 거의 0; 작은 서브넷/AZ당 중복된 NAT.
• 안전하게 수정하기: 트래픽이 미미할 때만 통합하세요. AZ 간 통합을 피하세요(AZ 간 데이터 처리/전송 요금으로 인해 절감액이 사라질 수 있음). 라우팅 테이블을 확인하세요. 적절한 경우 대안(AZ별 NAT, S3/DynamoDB용 VPC 게이트웨이 엔드포인트)을 고려하세요.
• 방지하기: 최소 처리량 정책 + 알림.

• 팁: 유휴/활용도가 낮은 NAT를 플래그 지정하고 안전한 경우 NAT 게이트웨이 삭제 작업을 대기열에 넣으세요. 팀이 AZ 간 통합 실수를 피할 수 있도록 AZ별 트래픽을 강조 표시하세요. Hyperglance에는 유휴 NAT 규칙과 NAT 게이트웨이 삭제 작업이 포함되어 있습니다.

스냅샷 위생

• 발견하기: 목적을 다한 고아 또는 아주 오래된 스냅샷.
• 안전하게 수정하기: 보존 정책 적용(예: 7/30/90); 종료된 리소스에 대한 스냅샷 정리.
• 방지하기: 자동화된 수명 주기 관리 + 예외 태그.

• 팁: 7/30/90 보존을 강제하고 정책보다 오래된 고아 스냅샷을 일괄 제거하세요. Hyperglance에는 “30일 이상 된 고아 EBS 스냅샷” 규칙과 EBS 스냅샷 삭제 작업이 포함되어 있습니다.

시작/중지 일정 및 개발/테스트 최대 절전 모드 (Hibernate)

• 간단한 태그 기반 일정을 만드세요 (예: 근무 시간).
• 또는 환경별로 AWS 계정을 분할(예: 전용 개발 계정)하고 해당 계정에 포괄적인 자동화를 적용(예: 예외를 제외한 모든 인스턴스를 금요일 20:00에 종료)하며 예외에 대한 허용 목록을 두세요.
• 가능한 경우 빠른 재개를 위해 최대 절전 모드를 지원하세요.
• 예외 목록을 유지하세요 (예: Schedule=NeverStop).

• 표준화할 수 있는 태그 예시:

  • Owner=team-x
  • Environment=dev
  • Schedule=OfficeHours # 예: 08:00–19:00 월–금
  • Retire-After=2025-12-31
  • CostCenter=CC-1234

• 팁: 태그 또는 환경 계정(예: dev)별로 포괄적인 일정을 적용한 다음 주간 회피 시간을 보고하세요. Hyperglance는 컴퓨팅 리소스에 대한 자동화된 시작/중지 일정을 지원합니다.

고착되는 가드레일 (예방 계층)

• 자동화를 주도하는 태그 지정 표준: Owner, CostCenter, Environment, Schedule, Retire-After, DataClass.

• 골든 이미지 / IaC 기본값:

  • 적정 규모의 루트 볼륨 (“그냥” 100GB가 아님)
  • 기본값으로 최신 세대 패밀리 사용
  • DeleteOnTerminate=true

• 기본적으로 동일 AZ 사용: HA가 허용하는 경우 동일 AZ 데이터 경로를 선호하세요. AZ 간 데이터 전송 비용에 대해 명확히 하세요. AZ 간 트래픽을 최소화하기 위해 AZ별 NAT 및 캐시 계층을 설계하세요.

• 변경 기간 및 승인: 쉬운 문제는 자동 수정하고, 위험한 문제는 티켓을 발행하세요.

• 팁: 태그 완전성 및 정규화를 제어 수단으로 취급하여 비용 소유권과 일정이 고착되도록 하세요. Hyperglance(또는 유사 서비스)는 태그 정규화와 함께 규모에 따라 태그를 추가/업데이트/제거하는 자동화를 제공합니다.

자동화할 것 (그리고 하지 말아야 할 것)

• 자동 수정해도 안전한 것:

  • 24시간 이상 된 연결 해제된 EIP → 해제 (release)
  • 7일 이상 된 연결되지 않은 EBS → 스냅샷 + 삭제
  • 14일 동안 대상이 없는 유휴 ALB/NLB → 삭제
  • 스냅샷 수명 주기 강제

• 먼저 알림/티켓 발행할 것:

  • 프로덕션 라우팅을 변경할 수 있는 모든 것
  • NAT 게이트웨이 변경
  • 중요 앱에 대한 인스턴스 패밀리 마이그레이션

KPI 및 보고

• 영향을 증명하기 위해 다음을 추적하세요:

  • 제거된 낭비 (월별 $) 환경/팀별 분할
  • 수정 시간 (알림 → 조치)
  • SP/RI에 의한 커버리지 (꾸준한 사용량의 커버 %)
  • 스팟 사용 시간 (및 폴백 이벤트)
  • 예외 수 (및 반복적인 위반자)

• 팁: 태그가 지정된 지출, 예산, 추세/이상 징후 및 비 FinOps 이해 관계자가 이해할 수 있는 “자동화를 통한 절감액” 롤업에 대한 대시보드를 사용하세요. Hyperglance(또는 유사 서비스)는 Cost Explorer(태그가 지정된 지출), 예산, 추세/이상 징후를 기본적으로 커버합니다.