월말, 재무팀에서 연락이 옵니다. "클라우드 비용이 지난달보다 40% 늘었는데 왜죠?" 청구서를 열어보지만 '컴퓨트 3200만원'처럼 뭉뚱그려져 어느 팀·서비스가 쓴 건지 알 수가 없습니다. 한참 파보니 누군가 테스트로 띄운 대형 인스턴스 5대가 3주째 돌고 있었고, 삭제된 인스턴스의 볼륨 수십 개가 그대로 과금되고 있었습니다. 클라우드 비용은 방치하면 조용히 샙니다.
- 1클라우드 비용이 '설계·운영의 결과'임을 이해한다
- 2흔한 비용 누수 패턴을 알고 찾아낼 수 있다
- 3예약/Savings Plans와 스팟의 적용 기준을 구분할 수 있다
- 4태깅으로 비용을 분해·추적하는 법을 안다
- 5rightsizing·수명주기·자동 종료로 비용을 줄일 수 있다
비용은 어디서 새는가
가장 흔한 누수 — 쓰지 않는데 켜진 것
비용 최적화의 80%는 화려한 기법이 아니라 '고아 자원' 청소입니다.
- 끄지 않은 개발/테스트 인스턴스(주말·야간 유휴)
- 어디에도 안 붙은 EBS 볼륨, 미사용 탄력적 IP
- 트래픽 없는 NAT 게이트웨이(VPC와 서브넷)
- 잊힌 오래된 스냅샷·로그(수명주기 없는 스토리지 오브젝트·블록·파일 스토리지)
이것만 정기적으로 청소해도 청구서가 눈에 띄게 줍니다. 비용 대비 효과가 가장 큽니다.
과대 프로비저닝 — 큰 옷을 입혀두기
온프레 사양을 그대로 옮기거나 "혹시 몰라" 크게 잡으면, 평균 CPU 5%인 인스턴스에 큰돈을 냅니다. rightsizing은 실제 사용률을 보고 한 단계 작은 타입으로 줄이는 작업입니다(가상 서버(EC2)의 타입 선택). 오토스케일링(오토스케일링 + 로드밸런서)으로 베이스는 작게, 피크만 늘리면 더 효율적입니다.
약정과 스팟 — 워크로드 성격에 맞춘 할인
- 예약 인스턴스 / Savings Plans: 1~3년 사용 약정 → 온디맨드 대비 크게 할인. 항상 도는 베이스 워크로드에 적합.
- 스팟 인스턴스: 남는 용량을 최대 수십~90% 싸게 → 단, 용량이 필요해지면 회수(중단). 배치·재시도 가능 워커처럼 중단에 견디는 워크로드에 적합.
패턴: 상시 베이스는 예약, 변동분은 온디맨드/스팟으로 섞어 최적 비용을 만듭니다.
어디에도 연결되지 않은(available) EBS 볼륨을 찾습니다. 이들은 쓰지 않아도 과금됩니다.
aws ec2 describe-volumes --filters Name=status,Values=available \
--query "Volumes[].{Id:VolumeId,Size:Size,Created:CreateTime}" --output table
+------------------+------+----------------------+
| vol-0aaa... | 100 | 2026-03-01T... | ← 3개월째 미사용
| vol-0bbb... | 50 | 2026-05-12T... |
+------------------+------+----------------------+
aws ec2 describe-volumes필수 태그(예: team)가 없는 자원을 찾습니다. 태그 없는 자원은 비용 책임 주체가 불명확합니다.
aws resourcegroupstaggingapi get-resources \
--query "ResourceTagMappingList[?length(Tags[?Key=='team'])==\`0\`].ResourceARN" --output text | head
arn:aws:ec2:...:instance/i-0xxx # team 태그 없음 → 누구 것인지 불명
aws resourcegroupstaggingapi get-resources- status=available인 EBS 볼륨·미연결 탄력적 IP — 사용 안 하면 즉시 삭제·반납(스냅샷 후)
- 필수 태그(team/service/env) 누락 자원 — 비용 분해 불가. 태그 정책으로 강제하고 누락분 소급 태깅
- CPU 사용률이 며칠째 한 자릿수인 인스턴스 — 과대 프로비저닝. rightsizing 또는 오토스케일 전환
- 월별 비용 추세에서 갑자기 튄 항목 — 예산 알림(budget alert)으로 조기 감지. 사후가 아니라 사전에
상황: 비용 급증의 원인을 특정하지 못해 대응이 늦어짐.
원인: 자원에 일관된 태그가 없어 비용을 팀·서비스·환경 차원으로 분해할 수 없음. 태깅이 사후약방문이 됨.
진단: 비용 탐색 도구(Cost Explorer 등)에서 태그·서비스별 분해 시도 → 태그 없는 비중 확인.
해결: ① 필수 태그(team/service/env) 정책을 가드레일로 강제(태그 없으면 생성 차단)(관측과 거버넌스), ② IaC(IaC와 Terraform)에 태그를 코드로 박아 일관성 확보, ③ 예산 알림으로 임계 초과 시 사전 통보. 태깅은 '나중에'가 아니라 처음부터.
비용 최적화(FinOps)는 인프라 엔지니어·PM 모두의 관심사가 됐습니다. "비용을 어떻게 관리하나요?"에 좋은 답은 ① 태깅으로 가시화, ② 고아 자원 정기 청소, ③ rightsizing, ④ 베이스는 예약·변동은 스팟, ⑤ 예산 알림으로 사전 감지 — 입니다.
PM 관점에서 중요한 메시지: "클라우드로 옮기면 싸진다"는 보장이 아닙니다(왜 클라우드인가). 최적화 없는 lift-and-shift는 오히려 비싸집니다. 비용은 기능·아키텍처 결정의 결과이므로, 설계 단계에서부터 비용을 고려하는 문화가 핵심입니다. 절감의 80%는 화려한 기법이 아니라 '안 쓰는 것 끄기'에서 나옵니다.
다음 모듈에서는 이 트랙의 마지막 — 자원을 관측하고 다계정을 통제하는 모니터링과 거버넌스(가드레일) 를 다룹니다.