AWS 비용 예상보다 많이 나왔을 때 원인 찾고 대처한 경험담

AWS 인프라 세팅 하다가 비용이 생각보다 훨씬 많이 나와서 깜짝 놀란 적이 있었어요. 처음엔 어디서 과금이 터졌는지 감도 안 잡히고, 그냥 대충 눈치로만 살펴보다가 결국 몇 번씩 설정과 사용 기록을 뒤져야 했거든요. 이 글은 제가 직접 AWS 비용 폭탄 맞고 고생하면서 원인 찾은 경험과 구체적인 대처법을 적은 거예요.

당연히 단순히 비용 확인하는 방법부터, 예상치 못한 리소스 과다 사용 추적, 그리고 잘못된 설정을 발견하는 법까지 상세히 다뤄볼게요. 제가 겪은 문제 상황과 AWS 콘솔 명령어, CLI 명령어까지 공유하니 똑같은 문제 겪는 분들은 한 번에 해결할 수 있을 거예요.

처음엔 왜 비용이 폭탄인지 몰랐어요

사실 AWS 비용이 갑자기 많이 나왔을 때 가장 당황스러운 점은 어디서 문제가 생겼는지 전혀 모른다는 거였어요. 저도 처음엔 빌링 대시보드만 얼른 봤는데, 비용 항목이 너무 세분화되어 있어서 직관적으로 잘 안 보이더라고요.

그래서 저는 먼저 AWS Cost Explorer를 적극 활용했는데, 이 툴은 사용량과 비용을 서비스별, 날짜별로 쪼개서 보여줘서 어느 부분에서 비용이 급증했는지 알 수 있어요. 하지만 설정 안 해두면 데이터가 늦게 반영되기도 하고, 특정 자원별 비용까지 쪼개기가 까다로워서 몇 번을 다시 봤던 기억이 납니다.

비용 확인하며 꼼꼼히 확인한 명령어들

AWS CLI에서도 비용 관련 정보를 확인할 수 있는데, 저는 특히 aws ce get-cost-and-usage 명령어를 자주 썼어요. 예를 들어 아래처럼, 특정 기간 동안 서비스별 비용을 확인하는데요.

aws ce get-cost-and-usage \
  --time-period Start=2024-05-01,End=2024-05-15 \
  --granularity DAILY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE

이 명령어 결과로 정확히 어떤 서비스가 비용을 주도하는지 볼 수 있어서, 갑작스럽게 비용이 증가한 EC2 인스턴스나 S3 요청 수 등을 빠르게 알 수 있었어요.

숨은 과금 원인은 예상치 못한 리소스

그런데 여기서 많이들 틀리는 게, 예를 들어 EC2 인스턴스만 주시하다가 실제로 비용 폭탄은 다른 서비스에서 발생하는 경우가 많다는 점이에요. 저도 이걸 몰라서 처음엔 EC2만 엄청 체크했는데, 몇 번이나 다시 봐야 했어요.

저 같은 경우는 CloudWatch 지표를 너무 많이 수집하는 설정 때문에 비용이 많이 나왔더라고요. CloudWatch는 지표와 로그를 저장하는 데 비용이 붙는데, 기본 모니터링 외에 커스텀 지표나 알람이 많으면 비용이 크게 늘 수 있어요.

제가 확인했던 명령어는 아래와 같아요. CloudWatch 지표별 사용량과 비용을 체크할 때 유용했어요.

aws cloudwatch list-metrics --namespace AWS/EC2

aws cloudwatch describe-alarms

원래 기본 지표 정도면 큰 비용 안 나는데, 저는 CPU, 디스크, 네트워크 지표 외에 커스텀 모니터링을 많이 만들어서 몰랐던 과금이 붙었더라고요.

잘못된 설정 때문에 돈 나간 사례

그다음은 인스턴스 스팟이나 예약 인스턴스, 프리티어 한도를 넘어서 사용한 경우였어요. 저는 스팟 인스턴스를 자동으로 종료하는 스케줄 설정을 잊어서 필요 없는 인스턴스가 한동안 계속 돈을 썼더라고요.

또 AWS S3의 버전 관리 기능을 켜서 삭제해도 버전들이 계속 쌓이고 있었는데, 이걸 모르고 그냥 버전 삭제 안 하고 방치했거든요. 결과적으로 저장 용량이 크게 늘어서 S3 비용 폭탄이 발생했어요.

저는 S3 버전별 용량과 객체 수를 CLI로 이렇게 확인했는데요, 꽤 오래된 객체들도 챙겨서 삭제해야 비용을 줄일 수 있더라고요.

aws s3api list-object-versions --bucket my-bucket --output json --query '{Versions: Versions[].{Key:Key,Size:Size}}'

버전 관리 기능은 편리하긴 한데, 주기적으로 오래된 버전을 지우는 스크립트를 돌리거나 수명주기 정책을 반드시 설정해야 한다는 걸 뼈저리게 느꼈어요.

제가 한 대처법과 스크립트 공유

상황을 빠르게 파악하기 위해 비용 탐색기에서 급격히 증가한 서비스부터 찾아서, CLI로 관련 리소스를 상세히 확인했어요. 그리고 오래된 S3 버전을 삭제하는 간단한 스크립트를 만들어 돌렸는데, 이 정도면 비용이 어느 정도 정상화되더라고요.

# 오래된 S3 객체 버전 삭제 (30일 이상)

BUCKET_NAME="my-bucket"

aws s3api list-object-versions --bucket $BUCKET_NAME --query 'Versions[?LastModified<=`2024-04-15`].{Key:Key,VersionId:VersionId}' --output json | \
  jq -c '.[]' | while read obj; do
    KEY=$(echo $obj | jq -r '.Key')
    VERSION_ID=$(echo $obj | jq -r '.VersionId')
    echo "Deleting $KEY (version $VERSION_ID)"
    aws s3api delete-object --bucket $BUCKET_NAME --key "$KEY" --version-id "$VERSION_ID"
  done

이 스크립트를 주기적 배치 작업으로 돌리니 S3 비용 증가를 막을 수 있었어요. 또한 CloudWatch 알람 중 필요 없는 항목은 과감히 삭제하고, 메트릭 수집 간격도 늘려서 비용을 효율적으로 관리했습니다.

자주 헷갈리는 부분과 해결법

Q. 비용이 갑자기 늘었는데, 어떤 서비스부터 확인하나요?

A. Cost Explorer에서 날짜별, 서비스별 비용 추이를 먼저 보고, 가장 많은 비용이 발생한 서비스부터 들어가 보세요. EC2, S3, CloudWatch 순으로 체크하는 걸 추천합니다.

Q. 모르고 너무 많은 CloudWatch 지표를 생성했어요. 바로 삭제해도 되나요?

A. 네, 불필요한 커스텀 지표나 알람은 즉시 삭제하는 게 좋습니다. 하지만 삭제 전 대시보드나 알람 의존성을 꼭 확인하세요. 삭제 방법은 콘솔이나 aws cloudwatch delete-alarms --alarm-names 명령어로 처리할 수 있어요.

Q. S3 버전 관리 계속 켜뒀는데 비용 부담 완화방법?

A. 수명주기 정책을 통해 일정 기간 지난 버전을 자동 삭제 또는 글래시어 등 저렴한 스토리지 클래스로 이전하는 게 필수입니다. 콘솔에서 생명주기 규칙을 쉽게 설정할 수 있으니 꼭 활용하세요.

이렇게 저도 직접 겪으면서 하나씩 문제점을 찾고 고쳐나가다 보니, 갑작스러운 AWS 비용 폭탄 문제를 어느 정도 예측하고 대처할 수 있게 됐어요. AWS 리소스는 편리하지만 관리와 모니터링 없이는 뜻밖의 요금이 발생할 수 있으니 여러분도 꼼꼼히 챙기시길 바랍니다.