비용을 줄이라는 요청을 받았는데 지금 무엇이 있는지부터 알 수 없었다. 서버가 몇 대이고 저장소가 몇 개이며 안 쓰는 것이 있는지를 아무도 답하지 못했다.
Table of contents
Open Table of contents
조사 — 종류별 전수 집계
콘솔은 화면이 여러 개로 나뉘어 있어서 aws ec2 describe-* 계열로 종류별로 조회해 INVENTORY.md 목록부터 만들었다. 인스턴스와 RDS 와 S3 버킷과 EBS 볼륨과 스냅숏과 Elastic IP 와 ALB 를 하나씩 셌다.
그 결과 스냅숏이 백 개 넘게 있었는데 그 숫자를 아무도 알지 못했다. 무엇이 있는지 모르면 무엇을 줄일지도 정할 수 없으므로 목록이 첫 산출물이었다.
안 쓰는 것의 발견
describe-volumes --filters Name=status,Values=available 로 어디에도 붙어 있지 않은 볼륨을 조회하니 몇 개에 테라바이트 단위였고 인스턴스를 지울 때 볼륨이 남은 것이었다. 어디에도 안 붙은 Elastic IP 도 셋이 요금만 내고 있었는데 AWS 공식 문서대로 Elastic IP 는 쓰든 안 쓰든 전부 과금된다.
두 가지 방법이 있었는데 안 붙은 것을 바로 지우는 것과 종류마다 되살릴 길을 두고 지우는 것이다. 뒤쪽을 골랐다. 이유는 볼륨 하나가 누군가의 유일한 데이터일 수 있어서다. 대신 스냅숏 요금이 한동안 남는 것을 감수했다. 볼륨은 create-snapshot 을 뜨고 지웠고 주소는 다시 못 받을 수 있으니 정말 안 쓰는지 확인했으며 스냅숏은 최근 것을 남겼다.
조치 — 정책으로 바꾼 관리
백 개 넘는 스냅숏은 대부분 자동으로 생성된 것인데 정작 지우는 쪽이 없었다. Data Lifecycle Manager 로 일 단위와 주 단위와 월 단위 보관 개수를 정하고 자동으로 지우게 하니 수십 개로 줄었다.
목록도 한 번 만들고 끝내지 않고 매일 뽑아 파일로 남겼다. diff 로 어제 것과 비교하면 새로 생긴 것과 없어진 것이 보이고 한 달 사이 스냅숏이 수십 개 늘었다는 사실이 정책을 만든 근거가 됐다.
주의 — 다른 계정까지의 범위
여기까지는 한 계정만 보고 있었는데 organizations list-accounts 로 물어보니 계정이 둘 더 있었다. 하나는 시험용 계정이고 다른 하나는 예전에 쓰던 계정이었다.
옛 계정에 자원이 아직 돌고 있었고 그만큼 요금도 계속 나오고 있었다. 정리하고 계정을 닫는 것만으로 매달 십몇만 원이 줄었다. 한 계정만 보면 다른 계정 것을 못 보므로 계정 목록부터 확인해야 했다.
사람과 키까지 센 결과
이 조사에서 자원만 센 것이 아니라 IAM 사용자도 함께 셌다. credential report 에서 90일 이상 안 쓴 사용자가 넷이었고 그중 둘은 이미 퇴사한 사람이었다.
get-access-key-last-used 가 비어 있는 접근 키도 여럿 남아 있었다. 안 쓰는 계정과 키는 그 자체가 위험이므로 자원 정리와 같이 처리했다. 결과적으로 비용을 줄이려고 시작한 일이 접근 정리로 이어졌다. 줄인 결과는 무엇을 줄여서 얼마가 줄었는지까지 항목별로 적었다. 다음에 다시 요청받으면 그 표에서 시작하게 했다.
정리
- 무엇이 있는지 모르면 무엇을 줄일지도 못 정한다
- 종류별로 전부 세면 아무도 모르던 것이 나온다
status=available볼륨처럼 안 붙은 자원을 찾는다- 지우기 전에 각각 어떻게 할지 정하고 되살릴 수 있게 둔다
- 자동으로 생기는 것에 보관 정책을 정한다
- 목록을 매일 뽑아
diff로 어제와 비교한다 - 한 계정만 보면 다른 계정 것을 못 본다
- 무엇을 줄여서 얼마인지 항목별로 적는다