AWS 해부 (6) 비용과 운영: Budgets, CloudWatch

AWS 해부 시리즈의 6편입니다. 전체 목차는 0편에 있습니다.

Budgets 알람이 첫날 할 일

AWS 요금은 월말 청구서에서 처음 확인하면 늦습니다. Budgets는 월 예산을 정해 두면 실제 사용액과 예측 사용액이 임계값을 넘을 때 이메일을 보내는 서비스입니다.

콘솔의 Billing and Cost Management에서 월 예산(예: 10 USD)을 만들고, 실제 사용액 기준 50%와 80%, 예측 사용액 기준 100% 알림을 겁니다. 예산 자체는 지출을 막지 않고 알리기만 하지만, “모르는 새 쌓이는” 상황은 이것으로 끊어집니다. 이 시리즈에서 순서를 바꾸지 말라고 한 설정이 2편의 IAM과 이 알람입니다.

요금이 새는 다섯 자리

과금 사고의 대부분은 “쓰고 있다고 생각하지 않는 리소스”에서 납니다.

자리	이유
중지된 instance의 EBS volume	중지는 EC2 과금만 멈춥니다. 디스크 용량 과금은 계속됩니다
Elastic IP와 public IPv4	고정 IP는 잡아 두는 것 자체가 시간 과금입니다
NAT Gateway	트래픽이 없어도 시간당 과금됩니다. 실습 계정에서 모르고 만든 경우가 많습니다
outbound 데이터 전송	S3에서 로컬로 대용량을 반복해서 받으면 전송 요금이 쌓입니다
스냅샷과 AMI	instance를 지워도 그 전에 만든 스냅샷은 남아서 용량 과금됩니다

공통 패턴은 “삭제했다고 생각한 것의 부속이 남는 것”입니다. 아래의 삭제 확인 목록이 이 패턴에 대한 대책입니다.

태그와 Cost Explorer

Cost Explorer는 기간별, 서비스별 지출을 보여주는 콘솔 화면입니다. 서비스 단위 분해까지는 그냥 되지만, “이 지출이 어느 프로젝트 것인가”는 태그를 붙여야 나뉩니다.

리소스를 만들 때마다 project: taxi-mlops 같은 태그를 붙이고, Billing 설정에서 해당 태그를 cost allocation tag로 활성화하면 Cost Explorer에서 태그 기준으로 지출을 나눠 볼 수 있습니다. 리소스가 열 개를 넘기 전에 태그 규칙을 정하는 것이 소급 정리보다 쌉니다.

CloudWatch 최소한

CloudWatch는 AWS 리소스의 지표(metric) 수집과 알람 서비스입니다. 이 시리즈 범위에서는 두 가지만 씁니다.

• 지표 확인: EC2 instance의 CPU 사용률은 자동으로 수집됩니다. 학습 작업이 CPU를 다 쓰고 있는지, t 패밀리의 버스트 크레딧이 바닥났는지를 여기서 봅니다. 메모리 사용률은 기본 수집에 없어서 CloudWatch agent를 설치해야 합니다
• 알람: CPU 사용률이 일정 시간 임계값을 넘으면 이메일을 보내는 알람을 겁니다. 서빙 서버가 죽어 있는 것을 알림으로 아는 최소한의 장치입니다

애플리케이션 수준의 모니터링(머신러닝 실전 워크플로 12편)과는 층이 다릅니다. CloudWatch는 머신과 서비스 층, drift 감지는 데이터와 모델 층입니다.

리소스를 지울 때의 확인 목록

실습을 마칠 때 instance 종료(terminate)만으로 끝내지 말고 다음을 순서대로 확인합니다.

1. EC2: instance 종료 후, EBS volume 목록에 남은 volume이 없는지
2. Elastic IP: 잡아 둔 주소를 해제(release)했는지
3. 스냅샷과 AMI: 만든 적이 있다면 삭제했는지
4. S3: 남겨 둘 데이터가 아니면 bucket을 비우고 삭제했는지 (3편의 versioning 주의 포함)
5. ECR: 이미지가 남아 있으면 용량 과금되므로 필요 없는 repository를 삭제했는지
6. 다른 region: 1편의 region 혼동으로 만들어진 리소스가 없는지. Cost Explorer에서 region별로 확인하는 것이 빠릅니다

며칠 뒤 Cost Explorer를 한 번 더 열어 지출이 0으로 떨어졌는지 확인하면 정리가 끝난 것입니다.

다음 편은 마지막으로, 이 시리즈 전체를 NYC 택시 스택의 AWS 이전 하나로 잇습니다.

다음 글: AWS 해부 (7) 응용: NYC 택시 스택을 AWS로