
AWS 비용 관리 완전 정복: 깜짝 청구서를 막는 실전 가이드
학습용 EC2를 켜놓고 잊었다가 100만원 청구서를 받은 적 있는가? AWS 요금 구조부터 Free Tier 함정, Cost Explorer 활용법, 예산 알림 설정, 그리고 FinOps 문화까지 — 클라우드 비용을 완전히 통제하는 실전 가이드.

학습용 EC2를 켜놓고 잊었다가 100만원 청구서를 받은 적 있는가? AWS 요금 구조부터 Free Tier 함정, Cost Explorer 활용법, 예산 알림 설정, 그리고 FinOps 문화까지 — 클라우드 비용을 완전히 통제하는 실전 가이드.

개발자 커뮤니티에서 매달 반복되는 사연이 있다.
"AWS 공부하려고 EC2 하나 띄워놨는데, 한 달 뒤에 청구서 보니까 87만원..."
"프리 티어라서 무료인 줄 알았는데 NAT Gateway 요금이 따로 나왔습니다"
"팀 프로젝트 끝나고 리소스 정리를 까먹었더니 3개월째 요금이..."
이건 드문 사고가 아니다. AWS를 처음 접하는 사람이라면 거의 대부분 한 번쯤 경험하는 통과의례에 가깝다. 문제는 AWS의 요금 체계가 직관적이지 않다는 것이다. "사용한 만큼만 낸다"는 원칙은 단순해 보이지만, 무엇을 사용하고 있는지 정확히 파악하지 못하면 예상치 못한 청구서가 날아온다.
이 글은 AWS를 처음 시작하거나, 이미 한 번 깜짝 청구서를 맞은 20대 개발자를 위한 실전 비용 관리 가이드다. 요금이 어떻게 계산되는지, 어디서 돈이 새는지, 그리고 어떻게 막는지를 하나하나 짚어본다.
AWS 요금 체계의 핵심은 세 가지 원칙으로 요약된다.
EC2 인스턴스를 예로 들어보자. t3.medium 인스턴스의 서울 리전(ap-northeast-2) 온디맨드 요금은 시간당 약 $0.052다. 얼핏 보면 아무것도 아닌 금액이다.
하지만 이걸 한 달로 환산하면?
"학습용으로 잠깐" 켜놨을 뿐인데, 끄는 걸 잊으면 1년에 60만원이다. 여기에 EBS 볼륨, 탄력적 IP, 데이터 전송 비용까지 더하면 금액은 더 늘어난다.
AWS 비용의 진짜 무서운 점은 자신이 모르는 사이에 과금되는 항목이 있다는 것이다.
| 항목 | 발생 조건 | 흔한 실수 |
|---|---|---|
| 탄력적 IP (EIP) | EC2에 연결하지 않고 방치 | 인스턴스 삭제 후 EIP 해제 안 함 |
| EBS 스냅샷 | 스냅샷 저장 용량에 비례 | 오래된 스냅샷 수십 개 방치 |
| NAT Gateway | 시간당 + 데이터 처리량 | 프라이빗 서브넷에서 외부 통신 시 자동 과금 |
| 데이터 전송 | AWS → 인터넷 아웃바운드 | S3에서 대용량 파일 다운로드 반복 |
| CloudWatch 로그 | 로그 수집 및 저장 용량 | 디버그 레벨 로그를 프로덕션에서 방치 |

AWS Free Tier는 클라우드 입문자에게 강력한 학습 도구다. 하지만 무엇이 무료이고 무엇이 아닌지를 정확히 알아야 한다. Free Tier는 세 가지 유형으로 나뉜다.
| 유형 | 기간 | 대표 서비스 | 주의사항 |
|---|---|---|---|
| 12개월 무료 | 계정 생성 후 12개월 | EC2 t2.micro, S3 5GB, RDS t2.micro | 12개월 지나면 자동으로 온디맨드 요금 부과 |
| 항상 무료 | 기간 제한 없음 | Lambda 100만 요청/월, DynamoDB 25GB | 무료 한도 초과 시 과금 |
| 단기 평가판 | 특정 기간 또는 횟수 | SageMaker, Redshift, Inspector | 서비스마다 조건이 다름 |
가장 많이 사용하는 12개월 무료 항목을 정리하면 이렇다.
여기서 가장 흔한 실수 두 가지를 짚자.
실수 1: "t2.micro 750시간이면 한 달 내내 돌릴 수 있다"
맞다. 한 달은 약 720~744시간이니까 t2.micro 1대를 24시간 돌리면 무료 범위 안이다. 그런데 2대를 동시에 돌리면? 750시간을 반으로 나눠야 하니까 약 15일 만에 무료 한도를 초과한다.
실수 2: "12개월 지나면 알아서 멈추겠지"
절대 아니다. 12개월 무료 기간이 끝나면 리소스가 자동으로 중지되거나 삭제되지 않는다. 그냥 온디맨드 요금이 부과되기 시작한다. 이게 바로 "깜짝 청구서"의 가장 흔한 원인이다.
기간 제한 없이 영구적으로 무료인 서비스도 있다. 사이드 프로젝트에 특히 유용한 항목들이다.
| 서비스 | 무료 한도 | 활용 시나리오 |
|---|---|---|
| Lambda | 100만 요청 + 40만 GB-초/월 | API 백엔드, 크론 작업, 이벤트 처리 |
| DynamoDB | 25GB + 읽기/쓰기 각 25 유닛 | 사용자 데이터, 세션 저장, 간단한 CRUD |
| SNS | 100만 푸시 알림/월 | 알림 시스템, 이벤트 브로커 |
| SQS | 100만 요청/월 | 메시지 큐, 비동기 처리 |
| CloudWatch | 기본 모니터링 + 로그 5GB | 리소스 모니터링, 로그 수집 |
| API Gateway | 100만 REST API 호출/월 (12개월) | 서버리스 API 엔드포인트 |
AWS 요금 청구서에서 가장 큰 비중을 차지하는 서비스들을 살펴보자. 이 다섯 가지만 잘 관리해도 전체 비용의 70~80%를 통제할 수 있다.
대부분의 AWS 비용에서 가장 큰 비중을 차지한다. 인스턴스 유형과 리전에 따라 요금 차이가 크다.
핵심 관리 포인트:
t3/t4g 버스터블 인스턴스는 CPU 크레딧 고갈 시 Unlimited 모드로 전환되면서 추가 과금 발생 가능RDS는 EC2 못지않게 비용이 큰 서비스다. 특히 Multi-AZ 배포를 활성화하면 비용이 2배가 된다.
NAT Gateway는 AWS 비용 관리에서 가장 과소평가되는 항목이다. VPC 안에서 프라이빗 서브넷의 리소스가 인터넷에 접근할 때 필요한데, 요금이 이중으로 부과된다.
NAT Gateway를 하나만 띄워놓고 데이터를 하나도 전송하지 않아도 월 약 100 이상이 쉽게 된다.
대안:
AWS의 데이터 전송 요금 체계는 비대칭이다.
| 방향 | 요금 | 설명 |
|---|---|---|
| 인터넷 → AWS (인바운드) | 무료 | 데이터를 넣는 건 공짜 |
| AWS → 인터넷 (아웃바운드) | $0.126/GB~ | 데이터를 빼는 건 유료 (서울 리전) |
| 같은 AZ 내 통신 | 무료 | 같은 가용 영역 안에서는 무료 |
| 다른 AZ 간 통신 | $0.01/GB | 작아 보이지만 대량 트래픽 시 누적됨 |
| 다른 리전 간 통신 | $0.08/GB~ | 멀티 리전 구성 시 주의 |
EBS 스냅샷은 볼륨의 백업인데, 증분 방식으로 저장된다. 처음에는 전체 볼륨을 복사하고, 이후에는 변경된 부분만 저장한다.
문제는 스냅샷을 수동으로 만들어놓거나, 자동 백업 정책이 오래된 스냅샷을 정리하지 않을 때 발생한다. 스냅샷 요금은 GB당 월 $0.05로 저렴해 보이지만, 수십 개의 스냅샷이 수개월간 쌓이면 무시할 수 없는 금액이 된다.
100GB 볼륨의 스냅샷이 20개 있다면? 단순 계산으로 월 $100이다. (실제로는 증분이라 이보다 적지만, 변경이 많을수록 비용이 늘어난다.)
요금 관리의 시작은 현재 얼마를 쓰고 있는지 아는 것이다. AWS Cost Explorer는 이를 위한 기본 도구다.
Cost Explorer는 AWS 계정에서 별도로 활성화해야 한다. 첫 활성화 후 데이터가 보이기까지 약 24시간이 걸린다.
1) 서비스별 비용 분석 (Daily, Monthly)
가장 기본적인 뷰다. "이번 달에 어떤 서비스에 돈을 가장 많이 썼는가?"를 한눈에 보여준다. 그래프 형태로 일별/월별 추이를 확인할 수 있어서, 비용이 갑자기 튀는 날을 빠르게 포착할 수 있다.
2) 리전별 비용 분석
같은 서비스라도 리전에 따라 요금이 다르다. 서울 리전(ap-northeast-2)은 미국 동부(us-east-1)보다 10~30% 비싸다. 지연 시간에 민감하지 않은 배치 작업이나 백업은 미국 리전에서 처리하는 것도 비용 절감 전략이다.
3) 미래 비용 예측 (Forecast)
Cost Explorer는 과거 사용 패턴을 기반으로 이번 달 말까지의 예상 비용을 자동으로 계산해준다. 이 예측값이 예산을 초과한다면, 지금 당장 리소스를 점검해야 한다는 신호다.
Cost Explorer는 강력한 도구이지만 사후 분석 도구다. "이미 발생한 비용"을 보여줄 뿐, 비용이 발생하기 전에 막아주지는 못한다. 그래서 AWS Budgets가 필요하다.
AWS Budgets는 "이 금액을 넘으면 알려줘"를 설정하는 서비스다. Cost Explorer가 백미러라면, Budgets는 전방 경고 시스템이다.
학습용 계정이라면 다음과 같이 설정하는 것을 권장한다.
| 알림 단계 | 임계값 | 의미 | 행동 |
|---|---|---|---|
| 1단계 | 실제 비용 $0.01 | 무료 구간을 벗어남 | 어떤 서비스에서 과금됐는지 확인 |
| 2단계 | 실제 비용 50% | 예산의 절반 소진 | Cost Explorer에서 항목 점검 |
| 3단계 | 예측 비용 100% | 월말에 예산 초과 예상 | 불필요한 리소스 즉시 정리 |
| 4단계 | 실제 비용 100% | 예산 초과 | 긴급 리소스 점검 및 중지 |
Budgets와 별도로, Billing 기본 설정에서도 이메일 알림을 켤 수 있다.
AWS 콘솔 → Billing → 기본 설정(Preferences) → "청구 알림 수신"을 활성화하면, Free Tier 사용량이 한도의 85%에 도달할 때 자동으로 이메일을 보내준다.
온디맨드 요금은 가장 유연하지만 가장 비싸다. 워크로드의 특성에 따라 최대 72%까지 할인받을 수 있는 세 가지 옵션이 있다.
| 항목 | Reserved Instances (RI) | Savings Plans (SP) | Spot Instances |
|---|---|---|---|
| 할인율 | 최대 72% | 최대 66% | 최대 90% |
| 약정 기간 | 1년 또는 3년 | 1년 또는 3년 | 없음 |
| 유연성 | 인스턴스 유형에 고정 | 인스턴스 유형 변경 가능 | 자유롭게 선택 가능 |
| 안정성 | 보장됨 | 보장됨 | 2분 전 통보로 회수 가능 |
| 적합한 워크로드 | 패턴이 예측 가능한 프로덕션 | EC2 + Lambda + Fargate 혼합 | 배치 처리, CI/CD, 내결함성 작업 |
동일한 워크로드를 1년간 운영할 때의 비용을 비교하면 차이가 극적이다. m5.large(서울 리전) 기준:
처음 AWS를 사용한다면 세 가지 모두 아직 필요하지 않다. 온디맨드로 시작하고, 사용 패턴이 안정화된 후에 할인 모델을 고려하자.
다만 한 가지 팁: Spot Instance는 학습 환경에서도 유용하다. 개인 프로젝트에서 배치 작업을 돌리거나, 짧은 시간 동안 큰 인스턴스가 필요할 때 Spot을 쓰면 최대 90% 할인된 가격으로 이용할 수 있다. 중간에 중단되어도 상관없는 작업에만 사용하면 된다.

이제 구체적인 비용 절감 전략을 살펴보자. 난이도가 낮은 것부터 높은 것까지 정리했다.
가장 기본이면서도 가장 효과적인 전략이다. CPU 사용률이 평균 10% 미만인 인스턴스는 오버프로비저닝된 것이다.
AWS는 Compute Optimizer라는 서비스를 무료로 제공한다. 현재 인스턴스의 사용 패턴을 분석해서 "이 인스턴스는 t3.small로 줄여도 됩니다" 같은 구체적인 추천을 해준다.
개발/테스트 환경은 업무 시간에만 필요하다. 주 5일, 하루 10시간만 가동해도 비용이 약 70% 절감된다.
자동화 방법:
auto-stop: 19:00, auto-start: 09:00 태그를 달고 Lambda가 읽어서 처리정기적으로 다음 항목들을 점검하자.
| 점검 대상 | 확인 방법 | 정리 효과 |
|---|---|---|
| 연결 안 된 EBS 볼륨 | EC2 → Volumes → "available" 상태 필터 | GB당 $0.10/월 절감 |
| 연결 안 된 탄력적 IP | EC2 → Elastic IPs → 인스턴스 미연결 확인 | 시간당 $0.005 절감 |
| 오래된 스냅샷 | EC2 → Snapshots → 생성일 기준 정렬 | GB당 $0.05/월 절감 |
| 미사용 로드밸런서 | EC2 → Load Balancers → 대상 그룹 확인 | ALB 기본 $16/월 절감 |
| 미사용 NAT Gateway | VPC → NAT Gateways → 트래픽 확인 | 최소 $43/월 절감 |
S3에 데이터를 저장할 때 접근 빈도에 따라 스토리지 클래스를 다르게 설정하면 비용을 크게 줄일 수 있다.
S3 Intelligent-Tiering을 사용하면 AWS가 자동으로 접근 빈도를 분석해서 데이터를 적절한 스토리지 클래스로 이동시켜준다. 모니터링 비용(객체 1,000개당 $0.0025/월)이 발생하지만, 수동 관리의 번거로움 없이 비용을 최적화할 수 있다.
AWS가 자체 설계한 Graviton 프로세서 기반 인스턴스는 동급 Intel/AMD 인스턴스 대비 약 20% 저렴하면서 성능은 비슷하거나 더 낫다.
t4g, m7g, c7g, r7g 시리즈가 Graviton 기반리전에 따라 요금 차이가 크다. 한국 사용자만 대상으로 하는 서비스가 아니라면, 더 저렴한 리전을 고려하자.
서울 리전은 버지니아(us-east-1) 대비 약 25% 비싸다. 지연 시간에 민감하지 않은 작업(데이터 분석, ML 학습, CI/CD 파이프라인)은 미국 리전에서 실행하는 것이 경제적이다.
모든 리소스에 일관된 태그를 붙여야 "어떤 프로젝트", "어떤 환경", "누가" 비용을 발생시키는지 추적할 수 있다.
Project: my-side-project
Environment: dev | staging | prod
Owner: kim@example.com
CostCenter: learning | team-a | team-b
AutoStop: true | false
Cost Explorer에서 태그별로 필터링하면, "내 사이드 프로젝트에 이번 달 얼마를 썼는지"를 바로 확인할 수 있다. 태그 없이는 수십 개의 리소스 중 어떤 것이 어떤 프로젝트용인지 구분이 불가능해진다.
AWS Trusted Advisor는 계정의 리소스를 자동으로 스캔해서 비용 절감 기회를 알려준다.
무료 플랜(Basic/Developer Support)에서도 확인할 수 있는 핵심 항목:
Business Support 이상에서는 더 상세한 분석을 제공한다:
FinOps는 Financial Operations의 줄임말로, 클라우드 비용을 조직의 핵심 엔지니어링 지표로 다루는 문화와 방법론이다.
FinOps는 대기업의 전유물이 아니다. 개인이나 소규모 팀도 핵심 원칙을 적용할 수 있다.
| FinOps 원칙 | 대기업 적용 | 개인/소규모 적용 |
|---|---|---|
| 가시성 | CUR + Athena 분석 파이프라인 | Cost Explorer + 월간 스프레드시트 |
| 예산 관리 | 부서/팀별 AWS 계정 분리 | AWS Budgets에 $10~50 설정 |
| 최적화 | RI/SP 포트폴리오 관리 | Spot Instance + 스케줄링 |
| 자동화 | 자체 FinOps 플랫폼 구축 | Lambda로 리소스 자동 정리 |
| 문화 | 비용 리뷰 미팅 | 매주 1회 Cost Explorer 확인 습관 |
핵심은 비용을 의식하는 습관이다. 코드를 작성할 때 "이 아키텍처가 월 얼마짜리인지"를 자연스럽게 떠올릴 수 있다면, 이미 FinOps를 실천하고 있는 것이다.
FinOps에서 가장 중요한 개념 중 하나는 단위 비용(Unit Cost)이다. 단순히 "이번 달 AWS 비용이 50만원"이 중요한 게 아니라, "사용자 1명당 인프라 비용이 얼마인가"가 중요하다.
AWS 계정을 처음 만든 순간부터 따라야 할 비용 안전 체크리스트다. 10분이면 완료할 수 있고, 이 10가지만 해두면 깜짝 청구서를 대부분 예방할 수 있다.
매월 1일에 다음을 확인하는 습관을 들이면 비용 관리가 자연스러워진다.
| 순서 | 점검 항목 | 소요 시간 |
|---|---|---|
| 1 | Cost Explorer에서 지난 달 비용 확인 + 전월 대비 비교 | 2분 |
| 2 | 비정상적으로 증가한 서비스 항목 확인 | 3분 |
| 3 | 미사용 리소스 정리 (EBS, EIP, 스냅샷) | 5분 |
| 4 | Budgets 알림 설정이 정상인지 확인 | 1분 |
| 5 | 다음 달 예상 비용 확인 (Forecast) | 1분 |
총 12분이면 된다. 커피 한 잔 마시면서 하기 딱 좋은 분량이다.
가능하다. AWS Support에 문의하면 첫 번째 실수에 대해서는 상당히 관대하게 환불해주는 경우가 많다. 특히 학습 목적으로 Free Tier를 사용하다가 발생한 비용은 높은 확률로 환불된다. Support 콘솔에서 "Billing" 카테고리로 케이스를 열면 된다.
단, 이건 선의에 기반한 정책이므로 반복적으로 기대해서는 안 된다. 예방이 최선이다.
아니다. AWS는 기본적으로 비용 상한을 설정하는 기능이 없다. 예산을 넘겨도 서비스는 계속 돌아간다. AWS Budgets Actions를 설정하면 특정 조건에서 자동 조치(예: 인스턴스 중지)를 취할 수 있지만, 설정하지 않으면 아무 일도 일어나지 않는다.
세 가지 방법이 있다.
AWS Organizations를 사용하면 팀원별로 별도 계정을 만들고, 통합 청구서로 관리할 수 있다. 각 계정의 비용을 독립적으로 추적하면서도, 전체 사용량을 합산해서 볼륨 할인 혜택을 받을 수 있다.
소규모 팀이라면 단일 계정에서 태그 기반으로 비용을 추적하는 것이 더 간단하다. 각 팀원이 자신의 이름을 Owner 태그에 넣으면 된다.
AWS 비용 관리는 "절약 정신"의 문제가 아니라 엔지니어링 역량의 문제다. 코드를 잘 짜는 것만큼 인프라 비용을 효율적으로 관리하는 것도 중요한 기술이다.
이 글의 핵심을 세 문장으로 요약하면 이렇다.
깜짝 청구서는 무지에서 온다. 그리고 무지는 정보로 해결할 수 있다. 이 글에서 다룬 내용을 하나씩 실행해보면, AWS 비용은 더 이상 두려움의 대상이 아니라 완전히 통제 가능한 변수가 될 것이다.
처음 시작하는 지금, 딱 10분만 투자해서 Budgets 알림부터 설정하자. 그 10분이 100만원짜리 청구서를 막아줄 것이다.