[Daily morning study] 클라우드 비용 최적화 전략

in Daily morning study / Cloud

#daily morning study

Image

클라우드 비용 최적화 전략

클라우드는 편하지만 방심하면 청구서가 무섭다. 쓴 만큼 낸다는 게 장점이기도 하고 함정이기도 하다. 비용 최적화는 성능을 포기하는 게 아니라, 낭비를 없애는 작업이다.

왜 클라우드 비용이 예상보다 많이 나오나

  • 개발·테스트 환경을 퇴근 후에도 켜 놓는다
  • 인스턴스 스펙을 실제 트래픽보다 과하게 잡는다
  • 사용하지 않는 EBS 볼륨, 스냅샷, 탄력적 IP가 남아 있다
  • 데이터 전송 비용(egress)을 간과한다
  • 로그, S3 오브젝트를 주기적으로 정리하지 않는다

핵심 최적화 전략

1. 올바른 인스턴스 유형 선택 (Right-Sizing)

실제 CPU·메모리 사용률을 보고 인스턴스 크기를 조정하는 것.

AWS CloudWatch, GCP Cloud Monitoring 등으로 2~4주치 사용률을 본 뒤 결정한다.

상황권장 조치
CPU 사용률이 계속 10% 미만인스턴스 다운사이즈
메모리만 많이 쓰고 CPU는 낮음메모리 최적화 타입으로 변경
워크로드가 불규칙Auto Scaling 도입

AWS Compute Optimizer나 GCP Recommender 같은 도구가 right-sizing 권고를 자동으로 제안해 준다.

2. 예약 인스턴스 / Savings Plans

온디맨드(On-Demand)는 가장 비싸다. 장기적으로 쓸 리소스가 보장된다면 약정을 걸면 된다.

AWS 기준

구매 옵션할인율특징
On-Demand0%약정 없음, 언제든 중단 가능
Reserved Instance (1년)최대 40%인스턴스 타입·리전 고정
Reserved Instance (3년)최대 60%더 높은 할인, 유연성 낮음
Savings Plans (Compute)최대 66%인스턴스 패밀리·리전 무관하게 적용
Spot Instance최대 90%중단 가능, 내결함성 워크로드에 적합

Savings Plans는 Reserved Instance보다 유연해서 인스턴스 타입이나 리전을 바꿔도 할인이 유지된다.

3. 스팟 인스턴스 활용

AWS가 여유 용량을 저렴하게 파는 방식. 단, 용량이 부족해지면 2분 예고 후 인스턴스가 회수된다.

적합한 워크로드

  • 배치 처리, 빅데이터 분석
  • CI/CD 빌드 파이프라인
  • 기계학습 학습(Training) 잡
  • 영상 인코딩

부적합한 워크로드

  • 실시간 API 서버
  • 데이터베이스 (상태를 직접 관리하는 경우)

Kubernetes에서는 Spot 노드 풀을 따로 구성하고, 중단에 민감하지 않은 파드를 배치하는 패턴을 많이 쓴다.

4. 자동 스케일링과 스케줄링

Auto Scaling 트래픽에 따라 인스턴스 수를 자동으로 조절한다. 최소/최대/희망 인스턴스 수를 설정해 두면 피크 때 자동으로 늘고, 여유 있을 때 줄어든다.

스케줄 기반 스케일링 예측 가능한 트래픽 패턴이 있다면 시간표를 짜는 게 효율적이다.

# AWS CLI로 예약된 스케일링 액션 추가 예시
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name my-asg \
  --scheduled-action-name scale-down-night \
  --recurrence "0 22 * * *" \
  --desired-capacity 1 \
  --min-size 1 \
  --max-size 2

개발 환경은 아예 야간·주말에 인스턴스를 꺼버리는 것도 좋다. Lambda나 EventBridge로 자동화할 수 있다.

5. 스토리지 비용 관리

S3 스토리지 클래스 계층화

접근 빈도에 따라 적합한 클래스로 이동시키면 비용을 크게 줄일 수 있다.

클래스특징적합한 데이터
S3 Standard빠른 접근, 가장 비쌈자주 쓰는 데이터
S3 Standard-IA덜 자주 접근, 조회 비용 발생30일 이상 접근 안 하는 데이터
S3 Glacier Instant Retrieval밀리초 조회, 저렴분기에 한 번 정도 접근
S3 Glacier Deep Archive가장 저렴, 복원에 시간 걸림규정상 보관만 해야 하는 데이터

S3 Lifecycle Policy를 설정하면 일정 기간 후 자동으로 더 저렴한 클래스로 이동하거나 삭제한다.

{
  "Rules": [
    {
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 }
    }
  ]
}

EBS 볼륨 정리 인스턴스를 삭제해도 EBS 볼륨이 남아 있으면 요금이 계속 나온다. 미사용 볼륨은 주기적으로 확인하고 삭제해야 한다.

6. 데이터 전송 비용(Egress) 줄이기

클라우드에서 데이터를 외부로 내보낼 때 비용이 발생한다. 같은 리전 내 트래픽은 대부분 무료이거나 매우 저렴하다.

  • 서비스를 같은 리전·가용 영역에 모아 배치한다
  • CDN(CloudFront, Cloud CDN)으로 엣지 캐싱해서 오리진 트래픽을 줄인다
  • S3 → EC2 전송은 같은 리전이면 무료이므로 리전을 일치시킨다

7. 비용 모니터링 도구 활용

비용 최적화는 한 번 설정하고 끝이 아니라 지속적으로 모니터링해야 한다.

AWS

  • Cost Explorer: 서비스·계정·태그 단위로 비용 트렌드 분석
  • Budgets: 예산 초과 시 알림 설정
  • Cost and Usage Report (CUR): 세밀한 원시 데이터를 S3로 내보내 Athena로 분석
  • Trusted Advisor: 비용 절감 권고 항목 자동 제시

GCP

  • Billing Reports: 프로젝트·서비스별 비용 시각화
  • Budget Alerts: 예산 임계치 알림
  • Recommender: right-sizing 권고

8. 태그(Tag) 전략으로 비용 책임 명확화

리소스에 태그를 붙이면 팀·프로젝트·환경별로 비용을 분리해서 볼 수 있다.

Environment: production / staging / dev
Team: backend / frontend / data
Project: user-service / payment-service

태그 없이 전체 청구서를 보면 어디서 돈이 나가는지 파악이 안 된다. 처음부터 태그 정책을 만들어 두는 게 중요하다.

비용 최적화 체크리스트

  • 사용하지 않는 리소스(인스턴스, 볼륨, 탄력적 IP) 정기 점검
  • 개발 환경 야간·주말 자동 중지 설정
  • CPU/메모리 사용률 기반 right-sizing 검토
  • 안정적인 워크로드에 예약 인스턴스 / Savings Plans 적용
  • S3 Lifecycle Policy 설정
  • CDN으로 egress 트래픽 최소화
  • 예산 알림 설정 (월 예산의 80% 도달 시 알림)
  • 모든 리소스에 태그 부착

정리

클라우드 비용 최적화에는 정답이 하나 없다. 워크로드 특성을 이해하고, 사용률 데이터를 기반으로 지속적으로 개선해 나가는 과정이다.

가장 큰 절감 효과를 내는 순서는 보통 이렇다:

  1. 미사용 리소스 제거 (즉시 효과, 노력 대비 ROI 최고)
  2. 개발 환경 스케줄링
  3. Right-sizing
  4. 예약 인스턴스 / Savings Plans
  5. Spot 인스턴스 도입
  6. 스토리지 계층화