청구서의 네 줄

한 줄 요약

클라우드 요금은 결국 네 축으로 정리됩니다 — **켜 둔 시간, 저장한 양,
옮긴 양, 호출한 횟수.** 어느 축에서 돈이 나가는지 알면 최적화 방향이 정해집니다.

왜 이게 필요했나

클라우드 요금은 서버 가격 하나가 아니라 실행 시간, 저장 용량과 요청, 데이터
전송, 관리형 기능의 합입니다. 한 축만 줄이면 다른 축의 비용이 커질 수 있으므로
청구서를 자원 종류가 아니라 비용이 생기는 원인별로 읽어야 합니다.

어떻게 동작하나

네 축

| 축 | 과금 기준 | 줄이는 방법 |
| --- | --- | --- |
| 컴퓨팅 | 인스턴스 × 시간 | 크기 축소, 안 쓸 때 끄기, 약정 할인 |
| 스토리지 | GB × 월 | 수명주기 정책, 저렴한 계층, 지우기 |
| 데이터 전송 | GB (주로 나가는 방향) | 경로 재설계, 캐시, 압축 |
| 요청/작업 | 호출 횟수 | 배치 처리, 캐시 |

"안 쓸 때 끄기" 가 첫 줄에 있는 게 핵심입니다. 개발·스테이징 환경을
평일 업무시간에만 켜면 그것만으로 약 70% 가 줄어듭니다
(24×7 = 168시간 중 9×5 = 45시간만 사용).

약정 할인의 구조

같은 인스턴스라도 어떻게 사느냐로 값이 크게 달라집니다.

| 방식 | 할인 | 조건 |
| --- | --- | --- |
| 온디맨드 | 없음 | 언제든 켜고 끈다 |
| 약정(1~3년) | 30~60% | 기간을 약속. 안 써도 낸다 |
| 스팟/선점형 | 60~90% | 언제든 회수될 수 있다 |

스팟은 할인 폭이 압도적이지만 갑자기 회수됩니다. 그래서 **중단돼도 되는
작업**에만 씁니다 — 배치, CI 러너, 재시도 가능한 큐 소비자. 상태를 가진
서비스에 쓰면 사고가 납니다.

약정은 그 반대입니다. 최소 기준선(baseline) 만큼만 약정하고 변동분은
온디맨드로 채우는 것이 정석입니다. 피크 기준으로 약정하면 놀리는 만큼 손해입니다.

스토리지 계층

접근 빈도에 따라 값이 10배 이상 차이 납니다.

자주 접근  →  가끔  →  드묾  →  보관용(아카이브)비쌈                              가장 쌈, 꺼내는 데 시간·요금

수명주기 정책으로 자동 이동시킵니다 — "30일 지나면 저빈도, 90일 지나면
아카이브, 365일 지나면 삭제" 같은 규칙. 이걸 안 걸면 로그가 몇 년치 쌓여
가장 비싼 계층에 그대로 남습니다.

주의: 아카이브 계층은 꺼낼 때 요금과 시간이 듭니다. 자주 볼 데이터를
넣으면 오히려 비싸집니다.

숨어 있는 요금들

청구서를 처음 보면 이해 안 되는 줄이 몇 개 있습니다.

• 할당됐지만 안 쓰는 것 — 인스턴스에서 분리된 볼륨, 안 붙은 고정 IP.

둘 다 존재만으로 과금됩니다.

• 스냅샷 누적 — 자동 스냅샷에 보존 정책이 없으면 계속 쌓입니다.
• 로그 저장 — 로그 수집을 켜고 보존을 무제한으로 두는 경우.
• NAT 게이트웨이 — 앞 코스에서 다룬 그것.
• 리전 간 복제 — 켜 놓고 잊기 쉽습니다.

태그가 없으면 아무것도 못 한다

비용을 줄이려면 먼저 누가 무엇을 왜 만들었는지 알아야 합니다. 태그가
그 역할을 합니다.

Owner       = platform-teamEnv         = prod | stage | devService     = paymentsCostCenter  = 1042

태그 규칙은 자원이 적을 때 세워야 지켜집니다. 수백 개가 태그 없이
쌓인 뒤에는 소급이 사실상 불가능합니다. 그리고 태그 없는 자원 생성을
정책으로 막아 두면 규칙이 저절로 지켜집니다.

현장에서 만나는 모습

• 개발 환경을 밤에도 켜 둬 컴퓨트 비용이 운영 환경과 비슷해짐 → 먼저 스케줄을 봅니다.
• 분리된 볼륨을 지우지 못함 → 소유자 태그가 없어 사용 여부를 판단할 수 없습니다.
• 아카이브로 옮겼는데 비용이 증가함 → 복원 빈도까지 포함한 총비용을 보지 않았습니다.

다음에 볼 것

네 축 중에서 가장 자주 과소평가되는 것 — 데이터 전송.