What Do You Look At First When You Open the Bill

한 줄 요약

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

왜 이게 필요했나

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

어떻게 동작하나

순서

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년에 얼마를 더 내는지를 직접 계산합니다.

줄이기 전에 확인할 것

앞의 다섯 단계는 무엇을 줄일지 알려 주지만, 줄여도 되는지는 따로 봐야 한다. 이 확인을 건너뛰어 생기는 사고가 절감으로 아낀 것보다 비싼 경우가 흔하다.

정말 안 쓰는가. 지표가 0 이라는 것과 아무도 안 쓴다는 것은 다르다. 한 달에 한 번 도는 정산 배치, 분기마다 쓰는 보고용 인스턴스, 재해 복구용으로 꺼 둔 자원이 전부 평소에는 0 으로 보인다. 관측 기간이 그 자원의 가장 긴 주기보다 길어야 판단할 수 있고, 그렇지 않으면 지우기 전에 소유자에게 물어야 한다.

누가 쓰는지 아는가. 태그가 없어 소유자를 모르는 자원이 가장 지우기 어렵다. 그럴 때는 지우는 대신 먼저 꺼 본다. 며칠 두었다가 아무도 찾지 않으면 그때 지운다. 되돌릴 수 있는 단계를 하나 끼우는 것만으로 이 판단이 훨씬 쉬워진다.

의존하는 것이 있는가. 스토리지 등급을 내리기 전에 그것을 읽는 쪽이 지연을 견디는지 봐야 하고, 인스턴스 종류를 바꾸기 전에 그 위에 고정된 라이선스나 IP 가 있는지 봐야 한다.

언제 되돌릴지 정했는가. 크기를 줄인 뒤 무엇을 보고 되돌릴지, 그리고 며칠 동안 지켜볼지를 미리 적어 둔다. 앞에서 두 단계를 한 번에 줄여 장애가 났다는 사례가 나오는데, 그 사고의 본질은 큰 폭이 아니라 되돌릴 조건을 안 정한 것이다.

마지막으로 아낀 금액을 기록한다. 무엇을 언제 줄여 얼마를 아꼈는지가 남으면 다음 분기에 같은 논의를 처음부터 하지 않아도 되고, 무엇보다 되돌려야 할 때 그 대가를 숫자로 말할 수 있다.

다음에 볼 것

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