청구서를 여는 순간 무엇부터 보는가

한 줄 요약

비용 절감은 금액이 큰 항목부터, 위험이 낮은 조치부터 봅니다.
반대로 하면 노력 대비 효과가 안 나오고, 서비스를 망가뜨립니다.

왜 이게 필요했나

할인 계약이나 아키텍처 변경부터 시작하면 사용하지 않는 자원까지 장기간 고정하거나
작은 절감 때문에 서비스 위험을 키울 수 있습니다. 되돌리기 쉬운 낭비 제거에서
측정이 필요한 크기 조정으로 이동하는 순서가 비용과 운영 안정성을 함께 지킵니다.

어떻게 동작하나

순서

1. 안 쓰는 것 지우기        ← 위험 0, 효과 즉시2. 안 쓸 때 끄기            ← 위험 낮음, 효과 큼3. 크기 줄이기(right-sizing) ← 측정 필요4. 저장 계층 옮기기          ← 수명주기 정책5. 아키텍처 바꾸기           ← 효과 크지만 오래 걸림6. 약정 할인 구매            ← 위 5개를 끝낸 뒤에 한다

6번이 마지막인 것이 중요합니다. 낭비를 그대로 둔 채 약정을 사면
낭비를 3년 계약으로 고정하는 셈입니다. 정리부터 하고, 정리된 기준선에
약정을 붙입니다.

1. 안 쓰는 것

체크리스트로 만들어 두고 분기마다 돕니다.

• 분리된 볼륨(unattached)
• 사용되지 않는 고정 IP
• 아무 대상도 없는 로드밸런서
• 오래된 스냅샷·AMI
• 비어 있는 데이터베이스 인스턴스
• 30일간 로그가 없는 로그 그룹
• 아무도 조회하지 않는 테이블

이것만으로 10~20% 가 줄어드는 경우가 흔합니다.

2. 스케줄

비운영 환경을 업무시간에만 켭니다. 실행은 간단하고 효과는 큽니다.
주의할 점은 끄기 전에 알림을 보내는 것 — 야근 중인 사람이 있을 수
있습니다. 그리고 예외 태그(AlwaysOn=true)를 두어 필요한 것은 남깁니다.

3. 크기 줄이기

지표 없이 하면 사고가 납니다. 최소한 이렇게 봅니다.

• CPU 최대치가 2주간 40% 미만이면 한 단계 줄일 후보
• 메모리 — 이게 진짜 제약인 경우가 많습니다. 반드시 함께 봅니다
• 버스트 크레딧 — 버스트형 인스턴스는 크레딧 소진 여부를 봐야 합니다.

평균 CPU 가 낮아도 크레딧이 바닥이면 이미 성능 제약 상태입니다.

한 단계씩 줄이고 관찰합니다. 두 단계를 한 번에 줄이면 되돌릴 때 판단할
근거가 없습니다.

4. 스토리지 수명주기

로그·백업·이미지에 정책을 겁니다.

0~30일    자주 접근 계층30~90일   저빈도 계층90~365일  아카이브365일 이후 삭제

삭제 규칙을 넣기 전에 보존 요건을 확인해야 합니다. 규제상 몇 년을
보관해야 하는 데이터가 섞여 있을 수 있습니다.

5. 아키텍처

앞에서 다룬 것들입니다 — 엔드포인트 도입, CDN, AZ 배치, 관리형 전환/이탈.
효과는 크지만 리드타임이 길어 앞의 네 단계와 병행합니다.

절감을 유지하는 법

한 번 줄여도 6개월이면 원래대로 돌아옵니다. 유지하려면 절차가 필요합니다.

• 예산과 알림 — 팀별 예산을 걸고 초과 예상 시 알림
• 태그 강제 — 태그 없는 자원은 생성 차단
• 정기 리뷰 — 분기마다 상위 10개 항목을 함께 본다
• 가시성 — 팀이 자기 비용을 볼 수 있게 한다. 안 보이면 안 줄어듭니다

마지막이 핵심입니다. 비용을 재무팀만 보면 아무도 안 줄입니다.
만든 사람이 값을 볼 수 있어야 합니다.

현장에서 만나는 모습

• 약정을 먼저 샀다가 아키텍처를 못 바꿈 → 순서가 틀렸다.
• 크기를 두 단계 줄여 장애 → 지표 없이 판단했다.
• 절감 후 반년 만에 원복 → 절차가 아니라 일회성 작업이었다.

이어지는 실습에서 할 것

이 순서를 실제 숫자로 확인합니다. 지표만 보고 크기를 줄이려 하면 다섯 대 중
셋이 막혀 있고, 무엇이 막는지는 CPU 가 아니라 메모리와 버스트 크레딧에 있습니다.
그리고 정리 전에 약정을 샀다면 3년에 얼마를 더 내는지를 직접 계산합니다.

다음에 볼 것

가용성에도 값이 있습니다. RTO/RPO 로 그 값을 정하는 법.