0617 AWS 운영 실무 기초 (8/N): 비용 관리와 리소스 최적화
✅ 1. AWS 비용 관리란 무엇인가?
- AWS 비용 관리란 AWS에서 사용 중인 리소스의 비용을 확인하고, 불필요한 과금을 줄이며, 서비스 규모에 맞게 리소스를 최적화하는 작업입니다.
- AWS는 대부분 사용한 만큼 비용이 발생하는 구조입니다.
- 서버를 하나 만들고 잊어버리거나, 테스트용 DB를 방치하거나, 로그를 무제한으로 쌓아두면 예상보다 큰 비용이 나올 수 있습니다.
- 개발자는 기능 개발뿐 아니라 운영 비용이 어디서 발생하는지 이해하고 관리하는 능력도 필요합니다.
➕ 1-1. AWS 비용 관리가 중요한 이유
-
예상치 못한 과금 방지
- 작은 실수로도 비용이 크게 늘어날 수 있습니다.
-
서비스 수익성 유지
- 운영 비용이 너무 높으면 매출이 있어도 실제 이익이 줄어듭니다.
-
불필요한 리소스 정리
- 사용하지 않는 EC2, RDS, EBS, 스냅샷, Elastic IP를 정리할 수 있습니다.
-
성능과 비용 균형
- 무조건 비싼 인스턴스를 쓰는 것이 답이 아닙니다.
- 현재 트래픽에 맞게 적절한 크기로 운영해야 합니다.
✅ 2. AWS 비용이 발생하는 기본 구조
- AWS는 서비스별로 비용 계산 방식이 다릅니다.
- 어떤 서비스는 실행 시간 기준, 어떤 서비스는 저장 용량 기준, 어떤 서비스는 요청 수나 트래픽 기준으로 비용이 발생합니다.
| 서비스 | 주요 비용 기준 |
|---|---|
| EC2 | 인스턴스 실행 시간, 인스턴스 타입, EBS |
| RDS | DB 인스턴스 실행 시간, 스토리지, 백업 |
| S3 | 저장 용량, 요청 수, 데이터 전송 |
| CloudFront | 데이터 전송량, 요청 수, Invalidation |
| CloudWatch | 로그 저장량, 지표, 알람 |
| Route 53 | Hosted Zone, DNS Query |
| NAT Gateway | 실행 시간, 데이터 처리량 |
| EBS | 볼륨 용량, 스냅샷 |
| Elastic IP | 미연결 또는 비효율 사용 시 비용 |
✅ 3. Cost Explorer
- Cost Explorer는 AWS 비용과 사용량을 시각적으로 확인할 수 있는 도구입니다.
- 월별 비용, 서비스별 비용, 일별 비용 추이, 특정 리소스 비용 증가를 확인할 수 있습니다.
➕ 3-1. Cost Explorer에서 확인할 것
- 이번 달 예상 비용
- 지난달 대비 증가한 비용
- 서비스별 비용 비중
- 특정 날짜에 비용이 급증했는지
- 사용하지 않는 리소스 비용이 발생하는지
- EC2, RDS, S3, CloudWatch 중 어디서 비용이 큰지
예시:
이번 달 AWS 비용이 갑자기 증가
↓
Cost Explorer에서 서비스별 비용 확인
↓
CloudWatch Logs 비용 증가 발견
↓
로그 보관 기간과 로그 출력량 조정➕ 3-2. 실무에서 자주 보는 기준
Group by: Service
Group by: Usage Type
Group by: Region
기간: 이번 달 / 지난 3개월 / 지난 6개월- 서비스별로 보면 어떤 AWS 서비스가 비용을 많이 쓰는지 알 수 있습니다.
- Usage Type까지 보면 같은 EC2라도 인스턴스 비용인지, 데이터 전송 비용인지, EBS 비용인지 구분할 수 있습니다.
✅ 4. AWS Budgets
- AWS Budgets는 비용이 특정 금액을 넘거나 넘을 것으로 예상될 때 알림을 받을 수 있는 기능입니다.
- 1인 개발자나 작은 회사에서는 반드시 설정하는 것이 좋습니다.
➕ 4-1. 비용 알림 예시
월 예상 비용 5만원 초과 시 알림
월 예상 비용 10만원 초과 시 알림
월 실제 비용 15만원 초과 시 알림➕ 4-2. 알림 기준 추천
| 상황 | 추천 기준 |
|---|---|
| 개인 테스트 계정 | 1만원, 3만원, 5만원 |
| 소규모 운영 서비스 | 5만원, 10만원, 20만원 |
| 광고 유입 서비스 | 평소 비용 대비 150%, 200% |
| 회사 운영 계정 | 예산별 단계 알림 |
- 비용 알림은 너무 늦게 오면 의미가 없습니다.
- “이미 큰 비용이 나온 뒤”가 아니라 “증가하기 시작할 때” 알 수 있게 설정하는 것이 좋습니다.
✅ 5. EC2 비용 관리
- EC2는 실행 중인 시간과 인스턴스 타입에 따라 비용이 발생합니다.
- 서버를 켜두면 트래픽이 없어도 비용이 계속 나갑니다.
➕ 5-1. EC2 비용이 늘어나는 원인
- 사용하지 않는 인스턴스 방치
- 테스트 서버를 끄지 않음
- 인스턴스 타입을 과하게 크게 설정
- Auto Scaling 설정 오류
- EBS 볼륨을 크게 잡음
- Elastic IP를 연결하지 않고 방치
- 데이터 전송량 증가
➕ 5-2. EC2 최적화 기준
- CPU 사용률이 너무 낮은 인스턴스는 작은 타입으로 낮출 수 있는지 검토한다.
- CPU가 계속 80% 이상이면 코드, DB, 캐싱 문제를 먼저 확인한다.
- 테스트 서버는 사용하지 않을 때 중지한다.
- 운영 서버는 t 계열 burst credit 상태도 확인한다.
- 로그와 빌드 파일이 디스크를 차지하지 않는지 확인한다.
좋지 않은 운영:
t3.large를 만들고 CPU 3%로 계속 운영
더 나은 운영:
t3.small 또는 t3.medium으로 낮추고 지표를 보면서 조정✅ 6. RDS 비용 관리
- RDS는 운영 안정성에는 좋지만 비용이 꽤 크게 느껴질 수 있는 서비스입니다.
- 인스턴스를 실행하는 시간, 인스턴스 클래스, 스토리지, 백업, Multi-AZ 여부에 따라 비용이 달라집니다.
➕ 6-1. RDS 비용이 늘어나는 원인
- 테스트용 RDS 방치
- 인스턴스 타입 과다 설정
- Multi-AZ 사용
- 스토리지 과다 설정
- 오래된 스냅샷 누적
- 백업 보존 기간 과다
- 읽기 복제본 방치
- Enhanced Monitoring 설정 비용
➕ 6-2. RDS 최적화 기준
- 테스트 DB는 사용하지 않을 때 중지한다.
- 운영 DB는 무조건 작은 타입만 고집하지 않는다.
- CPU, Memory, Connection, Storage를 보면서 조정한다.
- 오래된 수동 스냅샷을 정리한다.
- 백업 보존 기간을 서비스 중요도에 맞게 설정한다.
- Multi-AZ는 비용과 안정성을 비교해 결정한다.
주의:
운영 DB 비용을 줄이겠다고 백업을 꺼버리는 것은 위험함
더 나은 방식:
백업은 유지하되 보존 기간과 스냅샷 정리 기준을 관리✅ 7. S3 비용 관리
- S3는 저렴한 편이지만 파일이 계속 쌓이면 비용이 증가합니다.
- 특히 이미지, 백업, 로그, 임시 파일이 계속 누적되면 관리가 필요합니다.
➕ 7-1. S3 비용 요소
- 저장 용량
- 업로드/다운로드 요청 수
- 데이터 전송량
- 스토리지 클래스
- Lifecycle 이동 비용
- 오래된 백업 파일
- 사용하지 않는 업로드 파일
➕ 7-2. S3 최적화 방법
- 오래된 임시 파일은 Lifecycle로 삭제한다.
- DB 백업 파일은 보관 기간을 정한다.
- 이미지 원본과 최적화본 보관 기준을 정한다.
- 사용하지 않는 파일을 주기적으로 정리한다.
- 공개 파일과 비공개 파일 경로를 분리한다.
- 자주 접근하지 않는 파일은 저렴한 스토리지 클래스를 검토한다.
예시:
tmp/uploads/ → 7일 후 삭제
backups/db/ → 90일 후 Glacier 이동
logs/ → 30일 후 삭제✅ 8. CloudFront 비용 관리
- CloudFront는 CDN으로 성능을 개선하지만 요청 수와 데이터 전송량에 따라 비용이 발생합니다.
- 이미지가 많거나 광고 유입이 많은 서비스에서는 CloudFront 비용을 주기적으로 봐야 합니다.
➕ 8-1. CloudFront 비용이 늘어나는 원인
- 대용량 이미지 제공
- 이미지 최적화 미흡
- 캐시 적중률이 낮음
- 같은 파일을 자주 Invalidation
- 트래픽 급증
- 잘못된 봇 트래픽
- 동영상 같은 대용량 파일 제공
➕ 8-2. CloudFront 최적화 방법
- 이미지 WebP/AVIF 변환
- 모바일/PC 이미지 크기 분리
- 파일명에 해시나 UUID 사용
- 정적 파일에 장기 캐싱 적용
index.html은 짧게 캐싱- 불필요한 전체 Invalidation 줄이기
- 4xx/5xx 에러율 확인
좋지 않은 방식:
이미지 파일명을 그대로 유지하고 매번 /*
전체 캐시 무효화
더 나은 방식:
파일명에 UUID를 붙이고 변경된 파일만 새 URL로 제공✅ 9. CloudWatch 비용 관리
- CloudWatch는 모니터링에 필수지만, 로그를 많이 쌓거나 보관 기간을 무제한으로 두면 비용이 증가할 수 있습니다.
➕ 9-1. CloudWatch 비용이 늘어나는 원인
- 로그 보관 기간 미설정
- debug 로그 과다 출력
- 요청마다 너무 많은 로그 기록
- 대용량 JSON 로그 저장
- 불필요한 커스텀 메트릭 생성
- 알람 과다 생성
- 여러 서버의 로그 무제한 수집
➕ 9-2. 최적화 방법
- 로그 그룹별 보관 기간을 설정한다.
- 운영에서는 debug 로그를 줄인다.
- 개인정보와 불필요한 요청 body를 로그에 남기지 않는다.
- 에러 로그와 일반 로그를 구분한다.
- 오래된 로그는 S3로 아카이브하거나 삭제한다.
- 알람은 실제 대응이 필요한 지표 중심으로 설정한다.
예시:
개발 로그: 7일 보관
운영 API 로그: 30일 보관
에러 로그: 90일 보관
보안 감사 로그: 장기 보관✅ 10. EBS와 스냅샷 비용
- EBS는 EC2에 붙는 디스크입니다.
- EC2를 중지해도 EBS 볼륨은 남아 있으면 비용이 발생할 수 있습니다.
- 스냅샷도 저장 비용이 발생합니다.
➕ 10-1. 비용이 새는 흔한 상황
EC2는 삭제했는데 EBS 볼륨은 남아 있음
오래된 스냅샷이 계속 쌓임
테스트 서버 디스크를 크게 만들어둠
로그 파일 때문에 디스크를 계속 확장함➕ 10-2. 점검 기준
- 사용하지 않는 EBS 볼륨이 있는가?
- 오래된 스냅샷이 필요한가?
- 스냅샷 이름과 용도가 문서화되어 있는가?
- EC2 삭제 시 연결된 볼륨도 함께 삭제되는가?
- 디스크 부족 원인이 로그 누적인가, 실제 데이터 증가인가?
✅ 11. Elastic IP 비용
- Elastic IP는 EC2에 고정 IP를 부여할 때 사용합니다.
- 운영 서버에는 필요하지만, 사용하지 않는 Elastic IP를 방치하면 비용이 발생할 수 있습니다.
➕ 11-1. 점검할 것
- Elastic IP가 EC2에 연결되어 있는가?
- 중지된 인스턴스에 연결되어 있지는 않은가?
- 사용하지 않는 Elastic IP가 남아 있지는 않은가?
- 테스트 서버용 Elastic IP를 방치하지 않았는가?
운영 서버:
Elastic IP 필요
테스트 후 남은 Elastic IP:
삭제 검토✅ 12. NAT Gateway 비용 주의
- NAT Gateway는 Private Subnet의 서버가 인터넷으로 나갈 수 있게 해주는 서비스입니다.
- 편리하지만 비용이 생각보다 크게 나올 수 있는 서비스입니다.
➕ 12-1. NAT Gateway 비용이 커지는 이유
- 실행 시간 비용 발생
- 데이터 처리량 비용 발생
- 대량 트래픽이 NAT Gateway를 지나감
- 구조를 모르고 기본 구성으로 만든 뒤 방치
➕ 12-2. 주의할 상황
Private Subnet에 있는 서버가 외부 API를 자주 호출
Private Subnet에서 대용량 파일 다운로드
NAT Gateway를 여러 AZ에 생성
테스트 VPC에 NAT Gateway 방치- 작은 서비스에서는 처음부터 복잡한 VPC 구조와 NAT Gateway를 쓰기보다 비용을 이해하고 도입해야 합니다.
- 운영 안정성에는 도움이 되지만, 비용이 목적보다 커질 수 있습니다.
✅ 13. 비용 최적화와 성능 저하의 균형
- 비용을 줄이는 것은 중요하지만, 무작정 줄이면 서비스 안정성이 떨어질 수 있습니다.
- 특히 DB, 백업, 모니터링 비용을 무리하게 줄이면 장애 대응 능력이 떨어집니다.
➕ 13-1. 줄여도 되는 비용 후보
- 사용하지 않는 테스트 서버
- 오래된 스냅샷
- 불필요한 로그 장기 보관
- 과하게 큰 인스턴스
- 미사용 Elastic IP
- 중복 백업 파일
- 오래된 임시 파일
➕ 13-2. 함부로 줄이면 위험한 비용
- 운영 DB 백업
- 최소한의 모니터링 알람
- SSL/도메인 운영
- 보안 관련 로그
- 운영 서버 기본 성능
- RDS 스토리지 여유 공간
좋은 비용 절감:
사용하지 않는 리소스를 삭제
나쁜 비용 절감:
운영 DB 백업을 꺼서 비용 절감✅ 14. 태그 관리
- AWS 리소스에 Tag를 붙이면 리소스의 용도와 비용을 관리하기 쉬워집니다.
- 여러 프로젝트나 환경을 운영할 때 태그는 매우 중요합니다.
➕ 14-1. 태그 예시
Project: togethermall
Environment: production
Owner: dongjun
Service: api
CostCenter: web➕ 14-2. 태그를 쓰는 이유
- 어떤 리소스가 어떤 프로젝트용인지 알 수 있습니다.
- 운영/개발 리소스를 구분할 수 있습니다.
- 비용 분석에서 프로젝트별 비용을 볼 수 있습니다.
- 삭제해도 되는 테스트 리소스를 찾기 쉽습니다.
- 외주나 팀 작업 시 책임 범위를 구분할 수 있습니다.
태그 없는 리소스:
이게 지워도 되는 건지 판단하기 어려움
태그 있는 리소스:
Project, Env, Owner 기준으로 용도 판단 가능✅ 15. 1인 개발자 기준 AWS 비용 관리 루틴
- 1인 개발자는 비용 관리 담당자가 따로 없기 때문에 직접 루틴을 만들어야 합니다.
➕ 15-1. 매일 확인
- AWS 비용이 평소보다 급증하지 않았는가?
- CloudWatch 알람이 발생하지 않았는가?
- EC2/RDS 상태가 정상인가?
- 로그가 비정상적으로 많이 쌓이지 않는가?
➕ 15-2. 매주 확인
- 사용하지 않는 EC2가 있는가?
- 테스트 RDS가 켜져 있지 않은가?
- 오래된 스냅샷이 쌓여 있지 않은가?
- S3 임시 파일이 정리되고 있는가?
- CloudWatch 로그 보관 기간이 적절한가?
- CloudFront 트래픽이 평소와 비슷한가?
➕ 15-3. 매월 확인
- Cost Explorer에서 서비스별 비용을 확인한다.
- 지난달 대비 증가한 서비스가 있는지 본다.
- 예산 알림 기준이 적절한지 조정한다.
- 인스턴스 타입을 낮추거나 올릴 필요가 있는지 검토한다.
- 사용하지 않는 IAM Access Key, Elastic IP, EBS를 정리한다.
- 백업 보존 정책과 실제 비용을 비교한다.
✅ 16. 비용 사고 예시
➕ 16-1. 테스트 RDS 방치
테스트용 RDS 생성
↓
작업 끝났는데 삭제하지 않음
↓
한 달 내내 비용 발생- RDS는 트래픽이 없어도 실행 중이면 비용이 발생합니다.
➕ 16-2. CloudWatch 로그 무제한 보관
API 요청 로그를 전부 CloudWatch에 저장
↓
보관 기간 설정 안 함
↓
로그가 계속 누적
↓
CloudWatch 비용 증가- 로그는 필요하지만, 보관 기간과 로그 수준을 관리해야 합니다.
➕ 16-3. 대용량 이미지 원본 제공
상품 이미지 원본 5MB 그대로 업로드
↓
CloudFront로 사용자에게 그대로 제공
↓
모바일 로딩 느림
↓
트래픽 비용 증가- 이미지 최적화는 성능뿐 아니라 비용에도 영향을 줍니다.
➕ 16-4. NAT Gateway 방치
테스트 VPC 생성
↓
NAT Gateway 생성
↓
테스트 종료 후 삭제 안 함
↓
계속 비용 발생- NAT Gateway는 작은 서비스에서 비용 사고가 나기 쉬운 항목 중 하나입니다.
✅ 17. 비용 절감보다 먼저 해야 할 것
- 비용을 줄이기 전에 현재 비용 구조를 정확히 파악해야 합니다.
- 어디서 비용이 나오는지 모른 채 줄이면 중요한 리소스를 건드릴 수 있습니다.
➕ 17-1. 순서
1. Cost Explorer로 서비스별 비용 확인
2. 비용이 큰 서비스부터 원인 분석
3. 사용하지 않는 리소스 정리
4. 과하게 큰 리소스 조정
5. 로그/백업 보관 정책 조정
6. 캐싱/이미지 최적화로 트래픽 비용 절감
7. 예산 알림 설정- 가장 먼저 할 일은 삭제가 아니라 확인입니다.
- 확인 없이 삭제하면 장애나 데이터 손실이 발생할 수 있습니다.
✅ 18. 실무 체크리스트
➕ 18-1. 비용 알림 체크리스트
- AWS Budgets를 설정했는가?
- 예상 비용 기준 알림을 설정했는가?
- 실제 비용 기준 알림도 설정했는가?
- 알림 이메일을 실제로 확인할 수 있는가?
- 비용이 급증했을 때 확인할 순서를 알고 있는가?
➕ 18-2. 리소스 정리 체크리스트
- 사용하지 않는 EC2가 없는가?
- 중지된 EC2에 불필요한 EBS가 남아 있지 않은가?
- 테스트 RDS가 방치되어 있지 않은가?
- 오래된 RDS 스냅샷이 필요한가?
- 미사용 Elastic IP가 없는가?
- S3 임시 파일이 정리되고 있는가?
- CloudWatch Logs 보관 기간이 설정되어 있는가?
- NAT Gateway를 만들었다면 실제로 필요한가?
➕ 18-3. 최적화 체크리스트
- EC2/RDS 인스턴스 크기가 현재 트래픽에 맞는가?
- 이미지가 WebP/AVIF 등으로 최적화되어 있는가?
- CloudFront 캐시 정책이 적절한가?
- S3 Lifecycle 정책이 적용되어 있는가?
- 로그 레벨이 운영 환경에 맞게 조정되어 있는가?
- 태그로 프로젝트/환경/소유자가 구분되어 있는가?
✅ 19. AI를 활용해 AWS 비용을 점검할 때 질문법
- 비용 문제를 AI에게 물어볼 때는 “총액”만 말하면 원인을 찾기 어렵습니다.
- 서비스별 비용, 최근 변경사항, 사용 중인 리소스 구조를 함께 알려줘야 합니다.
➕ 19-1. 좋은 질문 예시
AWS 비용이 이번 달 갑자기 늘었어.
상황:
1. React + NestJS + PostgreSQL 서비스를 운영 중
2. EC2 1대, RDS 1대, S3, CloudFront, CloudWatch 사용
3. 지난달보다 비용이 2배 증가
4. Cost Explorer에서 CloudWatch Logs와 CloudFront 비용이 증가한 것으로 보임
5. 최근 배너 이미지를 많이 업로드했고, API 로그도 자세히 남기도록 바꿨음
어떤 순서로 비용 원인을 확인해야 할지 알려줘.
CloudWatch 로그 보관, 이미지 최적화, CloudFront 캐시, S3 Lifecycle 기준으로 설명해줘.➕ 19-2. AI 답변 검증 기준
- 무조건 서버를 줄이라고 하지 않는가?
- Cost Explorer에서 서비스별 비용부터 확인하라고 하는가?
- CloudWatch Logs 보관 기간을 확인하는가?
- CloudFront 트래픽과 이미지 용량을 확인하는가?
- 사용하지 않는 리소스 정리를 안내하는가?
- 운영 DB 백업을 함부로 끄라고 하지 않는가?
- 비용 알림과 태그 관리를 함께 설명하는가?
📌 요약
- AWS 비용 관리는 사용 중인 리소스의 비용을 파악하고, 불필요한 과금을 줄이며, 성능과 비용의 균형을 맞추는 운영 작업입니다.
- Cost Explorer로 서비스별 비용을 확인하고, AWS Budgets로 비용 알림을 설정해야 합니다.
- EC2와 RDS는 실행 시간과 인스턴스 타입에 따라 비용이 발생하므로 사용하지 않는 테스트 리소스를 방치하면 안 됩니다.
- S3, CloudFront, CloudWatch는 저장 용량, 트래픽, 요청 수, 로그 보관 기간에 따라 비용이 증가할 수 있습니다.
- 오래된 EBS 볼륨, 스냅샷, 미사용 Elastic IP, 테스트 RDS, NAT Gateway는 비용이 새기 쉬운 대표 항목입니다.
- 비용을 줄일 때 운영 DB 백업, 최소 모니터링, SSL, 보안 로그처럼 안정성에 필요한 부분을 함부로 줄이면 안 됩니다.
- 1인 개발자는 매일/매주/매월 비용 확인 루틴을 만들어야 합니다.
- 리소스에 Project, Environment, Owner 같은 태그를 붙이면 비용 분석과 정리가 쉬워집니다.
