공용 서브넷에 두는 것이 싸 보였는데 요금을 실제로 계산해 보니 반대였다. Elastic IP 를 적게 쓰니 그쪽이 쌀 것이라고 짐작한 것이 전부였다.
Table of contents
Open Table of contents
원인 — 요금표가 뒤집은 판단
요금표를 보니 Elastic IP 단가와 데이터 전송 단가가 있었고 같은 VPC 안의 사설 통신은 무료로 돼 있었다. 그중 세 번째 항목이 이 판단에서 결정적이었다.
전용 VPC 는 주소를 여러 개 받는 대신 장비 간 통신이 무료가 되고 공용 서브넷은 주소를 적게 쓰는 대신 장비끼리 통신할 때 공인 IP 로 밖으로 나간다. 주소 값보다 전송료가 훨씬 컸으므로 싸 보이던 쪽이 실제로는 비쌌다.
검증 — 실측한 전송량
계산에 쓸 숫자를 짐작하지 않고 실제로 쟀다. VPC Flow Logs 로 월간 전송량을 보고 그중 얼마가 우리 다른 장비로 가는지를 dstaddr 별로 확인하니 70퍼센트가 내부 통신이었다.
같은 VPC 에 두면 그 70퍼센트가 통째로 무료가 된다. 두 가지 방법이 있었는데 공용 서브넷에 두고 주소를 아끼는 것과 전용 VPC 에 두고 사설 통신으로 묶는 것이다. 뒤쪽을 골랐다. 이유는 실측값으로 계산하니 전송료가 주소 값보다 훨씬 커서다. 대신 Elastic IP 몇 개의 월 요금과 VPC 를 하나 더 관리하는 것을 감수했다.
과금 단위의 확인
계산하면서 요금이 매겨지는 단위가 무엇인지도 확인해야 했다. 전송은 나갈 때만 과금되고 S3 저장은 용량과 기간의 곱이며 PUT 요청은 1,000건 단위로 센다.
세 번째가 걸렸는데 작은 요청을 자주 보내면 그 건수만큼 과금되기 때문이다. 한 건씩 수천 번 보내던 것을 100건씩 묶으니 요청 수가 100분의 1이 됐고 단위를 알아야 무엇을 줄일지가 정해진다.
판단 기준 — 비중으로 정한 대상
Cost Explorer 에서 어디에 얼마를 쓰는지를 서비스별로 나눠 보니 S3 저장이 가장 컸고 전송이 그다음이었다. 전송을 줄이는 데 시간을 쓰고 있다가 그 표를 보고 방향을 바꿨다.
무엇이 저장 용량을 차지하는지 목록을 뽑아 보니 옛 백업이 대부분이었다. Lifecycle 규칙으로 보관 기간을 정하고 오래된 것을 GLACIER 등급으로 옮기니 저장 비용이 3분의 1로 줄었다.
조치 — 태그와 사전 계산
이렇게 항목별로 나눠 보려면 자원마다 태그가 붙어 있어야 했다. AWS 공식 문서대로 비용 할당 태그를 활성화해야 청구 보고서가 그 태그로 비용을 나눠 주므로 Project 와 Environment 와 Owner 를 붙이고 태그가 없는 자원을 찾아 하나씩 채웠다.
청구 도구가 제한적일 때는 태그가 나눠 보는 유일한 수단이다. 새 자원을 만들 때 얼마인지 모르고 만들고 있어서 인스턴스와 볼륨과 예상 전송량으로 월 비용을 미리 계산하는 표도 만들었다. 만들고 나서 청구서로 아는 것과 만들기 전에 아는 것은 정할 수 있는 것이 다르고 실제로 한 번은 그 계산을 보고 더 작은 것으로 바꿨다.
정리
- 싸 보이는 쪽이 요금 구조에 따라 반대일 수 있다
- 요금표를 보고 실제 사용량을 재서 계산한다
- 요금이 매겨지는 단위를 확인한다
- 건수 단위면 묶어서 보낸다
- 어디에 얼마 쓰는지 나눠 보고 큰 것부터 줄인다
- 비용 할당 태그를 붙여야 Cost Explorer 에서 나눠 볼 수 있다
- 태그 없는 자원은 어디 것인지 알 수 없다
- 만들기 전에 예상 비용을 계산하면 선택이 달라진다