이 글에서 얻는 것

  • 클라우드 비용을 “아껴야지”가 아니라 어디서 돈이 새는지(Compute/Storage/Network/Observability) 구조로 파악할 수 있습니다.
  • 비용 최적화의 우선순위를 “큰 항목부터” 잡고, 효과가 큰 액션(권장 루틴)을 실행할 수 있습니다.
  • 자동 확장/예약 할인/캐시 같은 선택이 비용뿐 아니라 안정성/성능과 연결된다는 트레이드오프 감각이 생깁니다.

0) 비용 최적화는 ‘지출 절감’이 아니라 ‘가치 대비 비용’이다

진짜 목표는 보통 이겁니다.

  • 같은 트래픽을 더 적은 비용으로 처리하거나,
  • 같은 비용으로 더 높은 SLO/더 많은 기능을 제공하는 것.

그래서 비용 최적화도 관측성이 필요합니다. “어떤 요청/기능이 비용을 만든다”를 모르고 줄이면, 중요한 걸 잘라버릴 수 있습니다.

1) 비용의 큰 덩어리부터 본다

대부분의 서비스는 다음 순서로 비용이 큽니다(물론 케이스마다 다름).

  1. Compute(인스턴스/컨테이너) + DB(Managed DB 포함)
  2. Network(특히 egress, NAT, cross-AZ/리전)
  3. Storage(스냅샷/로그/오브젝트)
  4. Observability(로그/트레이스 저장 비용)

최적화는 “가장 큰 항목 1~2개”부터 손대는 것이 ROI가 좋습니다.

2) Compute: 리소스 과대할당을 먼저 제거한다

가장 흔한 낭비는 “필요 이상으로 큰 인스턴스/리소스”입니다.

  • Rightsizing: CPU/메모리 사용률을 보고 적정 사이즈로 조정(피크/여유 버퍼 포함)
  • Autoscaling: 트래픽 패턴이 변동적이면 확장/축소로 평균 비용을 낮춤
  • 스케줄링: 내부 도구/배치처럼 야간에만 필요하면 시간대 기반으로 꺼두기
  • Spot/Preemptible: 중단되어도 되는 워크로드(배치/비동기)에서 강력

주의:

  • 오토스케일은 잘못 설정하면 “추락(스파이크) → 과확장 → 비용 증가”가 발생합니다(지표/쿨다운이 중요).

3) DB: 성능 최적화가 곧 비용 최적화다

DB는 “늘리면 비싸고, 줄이기 어렵고, 장애에 민감”합니다.

  • 슬로우 쿼리/인덱스/락을 먼저 잡으면 인스턴스 스펙을 올리지 않아도 됩니다.
  • 읽기가 많으면 캐시/리드 레플리카로 “비싼 쓰기 노드” 부담을 줄일 수 있습니다.
  • 커넥션 폭주가 비용/장애를 부르므로 풀/타임아웃/레이트리밋을 근거화합니다.

4) Network: 숨은 비용(egress/NAT/cross-AZ)이 크다

가장 많이 놓치는 구간입니다.

  • Egress: 인터넷으로 나가는 트래픽(이미지/파일/응답)이 커지면 비용이 빠르게 증가합니다.
    • CDN/압축/캐시로 줄일 수 있습니다.
  • NAT: 프라이빗 서브넷의 아웃바운드가 많으면 NAT 비용이 커질 수 있습니다.
    • S3/ECR 같은 서비스는 VPC Endpoint로 NAT 트래픽을 줄이는 것이 효과적일 때가 많습니다.
  • cross-AZ/리전: 같은 서비스라도 AZ를 넘나들면 데이터 전송 비용이 붙을 수 있습니다.
    • “항상 같은 AZ로 붙기”가 정답은 아니지만, 비용/지연이 커질 수 있다는 감각은 필요합니다.

5) Storage/로그: ‘보존 기간’이 비용을 만든다

스토리지 자체보다, “쌓이는 속도 + 보존 기간”이 비용을 결정합니다.

  • 오브젝트 스토리지는 수명 주기 정책(Lifecycle)로 Hot→Cold로 내리기
  • 스냅샷/백업은 보존 정책을 명확히(무한 보존은 언젠가 비용 폭탄)
  • 로그는 “전부 저장”이 아니라 샘플링/필터링/마스킹/구조화를 통해 필요 정보만 남기기

6) 예약 할인(RI/Savings Plan): 안정 구간만 커밋하라

예약 할인은 “항상 켜져 있는 워크로드”에만 효과적입니다.

  • 먼저 2~4주 정도 사용 패턴을 보고 “항상 필요한 바닥(기저)”을 파악한 뒤,
  • 그 바닥에만 커밋하는 방식이 안전합니다.

너무 빨리 커밋하면 “쓰지 않는 예약”이 생겨 낭비가 됩니다.

7) 비용 최적화 운영 루프(추천)

비용은 기술 문제가 아니라 “운영 프로세스”로 잡히는 경우가 많습니다.

  • 태깅/코스트 할당: 서비스/팀/환경 기준으로 비용을 쪼갤 수 있게
  • 예산/알림: 급증(anomaly)을 빨리 감지
  • 월간 리뷰: 상위 비용 항목 3개만 보고 1개 개선
  • 단위 지표: “요청 1건당 비용”, “활성 사용자 1명당 비용” 같은 감각을 만든다

연습(추천)

  • 이번 달 비용 상위 3개 항목을 뽑고, 각각 “한 번의 액션”으로 줄일 수 있는 아이디어를 적어보기
  • NAT가 붙은 구조라면 “S3/ECR 접근이 NAT를 타는지” 확인하고 Endpoint로 절감 가능성을 계산해보기
  • 로그/트레이스 보존 기간을 30일→14일로 줄였을 때 비용과 관측성 리스크를 비교해보기