비용 배분 태그, 나중에 붙이면 늦는 이름표
태그를 붙이는 일과 비용 분석에서 켜는 일은 달라요. 과거 비용에 소급할 수 있는 것과 되살릴 수 없는 기록을 구별해 봐요.
이 글의 목차두 동작이 따로 있다4
창고에서 물건이 나갈 때마다 어느 부서가 가져갔는지 적어 두는 장부가 있다고 해 볼게요. 석 달 뒤에 부서별 사용량을 정산하려는데, 장부에 부서 칸이 비어 있으면 어떻게 해도 나눌 수 없어요. 지금부터 적기 시작하는 것과 지난 석 달을 되살리는 것은 다른 일이에요.
클라우드 청구서를 쪼개 보는 일이 이 장부예요. 총액이 늘었다는 사실만으로는 무엇을 줄일지 정할 수 없고, 그러려면 각 지출이 어디에 속하는지가 데이터에 남아 있어야 해요. AWS에서 그 칸에 해당하는 것이 비용 배분 태그예요.
두 동작이 따로 있다
여기서 처음 헷갈리는 것이 동작이 하나가 아니라는 점이에요. 자원에 이름표를 붙이는 일과, 그 이름표를 청구 데이터에서 쓰겠다고 켜는 일이 별개예요. 앞의 것은 자원을 만들 때 하고, 뒤의 것은 청구 화면에서 해요.
AWS는 사용자가 직접 정의한 이름표를 청구 데이터에 쓰려면 청구 화면에서 따로 활성화해야 한다고 안내해요. 붙였는데 켜지 않으면 청구 데이터에 나타나지 않아요. 반대로 켜기만 하고 자원에 붙이지 않으면 켠 이름표에 값이 없어요. 두 동작이 모두 있어야 한 줄이 완성되는데, 화면이 서로 떨어져 있어서 한쪽만 하고 끝내기 쉬워요.
소급되는 것과 안 되는 것
AWS는 소급 수단을 제공해요. 관리 계정에서 최대 열두 달치까지 이름표의 현재 활성화 상태를 소급 적용하도록 요청할 수 있어요. 늦게 켰더라도 지난 몇 달을 다시 나눠 볼 수 있다는 뜻이에요.
그런데 같은 문서가 조건을 하나 달아 둬요. 소급된 비용 데이터에 값이 나오려면 그 이름표가 그 시점에 실제로 자원에 붙어 있었어야 해요. 문서의 예시도 정확히 그 경계를 설명해요. 6월에 자원에 붙고 11월에 켠 이름표를 1월부터 소급하면, 값이 채워지는 것은 6월부터이고 1월부터 5월까지는 비어 있어요.
정리하면 소급되는 것은 켠 상태이고, 소급되지 않는 것은 붙인 사실이에요. 이 구분이 실무에서 중요한 이유는 순서가 결정되기 때문이에요. 켜는 일은 나중에 해도 되지만 붙이는 일은 나중에 할 수 없어요. 그래서 이름표 규칙은 자원을 만들기 전에 정해야 해요.
| 언제 무엇을 했나 | 지난달을 나눠 볼 수 있나 | 이유 |
|---|---|---|
| 붙였고 켰다 | 볼 수 있다 | 데이터에 값이 있다 |
| 붙였는데 안 켰다 | 소급 요청하면 볼 수 있다 | 켠 상태만 되살리면 된다 |
| 안 붙였는데 켰다 | 볼 수 없다 | 되살릴 값 자체가 없다 |
지금 어떤 상태인지 확인할 방법도 있어요. 화면에는 이름표가 마지막으로 켜지거나 꺼진 날과 마지막으로 어느 자원에 쓰인 달이 함께 표시돼요. 두 값을 나란히 보면 위 표의 어느 줄에 해당하는지 바로 갈려요.
태그를 붙이기 전의 구간은 이 소급 기능으로 복원할 수 없어요. 다른 사용량 기록이나 자원 식별자로 별도 배분할 수는 있지만, 그때는 실제 태그 기록과 나중에 추정한 배분을 구별해야 해요. 이름표를 붙여 두는 편이 나중에 그 근거를 다시 만드는 것보다 훨씬 간단해요.
3월에 자원에 붙이고 6월에 비용 배분을 활성화한 태그예요.
자원에 태그가 붙은 기간
없음2월
없음3월
있음4월
있음5월
있음6월
있음
비용 기록에 태그 값 표시
없음2월
없음3월
없음4월
없음5월
없음6월
표시
자원에 태그가 붙은 기간
없음2월
없음3월
있음4월
있음5월
있음6월
있음
비용 기록에 태그 값 표시
없음2월
없음3월
표시4월
표시5월
표시6월
표시
비용 배분 활성화는 소급할 수 있지만 자원에 태그가 없던 시기의 값까지 생기지는 않아요.
6월부터 비용에 태그 값이 보여요. 자원 자체에는 3월부터 태그가 있었어요.
현재 관리 계정의 최대 12개월 backfill 범위 안에 있는 가상의 월들이에요. 요청이 처리되고 비용 데이터에 반영되는 대기는 생략해요.
나눠 봐도 줄지 않는 것
같은 문서군에는 기대를 정확히 눌러 주는 문장이 하나 더 있어요. 이름표로 어떤 자원이 사용량과 비용에 기여하는지 볼 수 있지만, 그 자원을 지우거나 끈다고 해서 비용이 항상 줄어드는 것은 아니라는 것이에요.
앞 시리즈에서 청구서를 다루며 적은 것과 같은 구조예요. 켜 둔 시간에 붙는 값과 옮긴 바이트에 붙는 값은 성격이 달라서, 자원을 지운다고 이미 나간 트래픽 값이 사라지지 않아요. 이름표는 어디를 볼지 알려 주지 무엇을 지울지 알려 주지 않아요.
저는 무엇을 늦게 붙였나
제가 만드는 앱은 자원이 많지 않아 청구서를 갈래별로 나눌 필요가 크지 않았어요. 그런데 AI 계산과 앱을 서로 다른 곳에 두면서 “이 달에 늘어난 것이 어느 쪽인가”를 묻게 됐고, 그때 답할 수 없다는 것을 알았어요.
지금은 새로 만드는 것에는 규칙을 정해 붙이고 있어요. 다만 그 전에 만들어 둔 것들의 지난 기록은 되살리지 못했어요. 되돌아보면 아쉬운 것은 늦게 켠 것이 아니라 늦게 붙인 것이었어요. 켠 것은 소급으로 만회할 수 있었지만 붙이지 않은 구간은 방법이 없었어요.
이름표는 비용을 줄이는 도구가 아니라 질문할 자격을 만드는 도구였어요. 붙여 두지 않으면 나중에 물어볼 수조차 없다는 점에서, 앞 글의 감사 기록과 성격이 같았어요.