AWS 청구서가 매달 조용히 늘어나는데 어디부터 손대야 할지 막막한 상황입니다. 미사용 리소스와 데이터 전송비를 방치하면 1년이면 수백 달러가 새 나갑니다.
풀스택으로 웹·앱 인프라까지 챙기는 관점에서, AWS 공식 단가 기준으로 절감 수단을 효과 순으로 추렸습니다. 이 순서대로 가면 어디부터 손대야 비용이 줄어드는지 우선순위가 정리됩니다.

먼저 숫자로 — 청구서가 새는 5곳
AWS 비용 절감은 "어디서 새는지"부터 봐야 합니다. Cost Explorer를 서비스별로 정렬하면 보통 아래 다섯 군데에서 돈이 빠져나갑니다. 순서는 한국 스타트업·중소 규모에서 자주 보이는 패턴 기준이고, 워크로드에 따라 순위는 바뀝니다.
| 새는 곳 | 자주 보이는 원인 | 1차 점검 |
|---|---|---|
| EC2 컴퓨팅 | 온디맨드 그대로 장기 운영 | Savings Plans·Graviton 검토 |
| 데이터 전송 | NAT·CloudFront 아웃·리전 간 전송 | VPC 엔드포인트·CDN 캐싱 |
| 스토리지 | S3 Standard에 콜드 데이터 방치 | Intelligent-Tiering·Glacier |
| 미사용 리소스 | 분리된 EBS·미연결 EIP·놀고 있는 IPv4 | 정기 청소 |
| 데이터베이스 | 과대 사양 RDS, 온디맨드 인스턴스 | 라이트사이징·Graviton |
대부분은 "한 번 켜두고 잊은 것"이 누적된 결과입니다. 새 인스턴스를 줄이는 것보다 이미 켜져 있는 걸 끄거나 약정으로 바꾸는 것이 효과가 빠릅니다. 한 스타트업 사례에서는 라이트사이징과 약정 조정으로 월 300만 원대 청구서를 30만 원대까지 줄였다고 공유했는데(인프랩 tech.inflab.com), 이건 그 환경의 결과지 모든 곳에 일반화되는 수치는 아닙니다. 본인 청구서에서 위 다섯 곳의 비중부터 확인하는 게 먼저입니다.
절감 10가지 한눈에 — 효과·난이도·리스크 매트릭스
아래는 이 글에서 다루는 10가지를 절감폭·난이도·리스크로 정리한 표입니다. 절감폭은 전부 AWS 공식 "최대(up-to)" 기준이라, 실제 절감은 워크로드와 약정 조건에 따라 이보다 작습니다.
| # | 수단 | 최대 절감폭 | 난이도 | 적용 시간 | 리스크 |
|---|---|---|---|---|---|
| 1 | Compute Savings Plans | 온디맨드 대비 최대 66% | 낮음 | 즉시 | 1·3년 약정 |
| 2 | EC2 SP / Reserved Instance | 최대 72% (Convertible RI 최대 54%) | 낮음 | 즉시 | 인스턴스 고정 |
| 3 | Spot Instances | 최대 90% | 중간 | 워크로드 분리 필요 | 2분 통보 중단 |
| 4 | Graviton 전환 | x86 대비 최대 20% 저렴 | 중간 | 테스트 필요 | ARM 호환성 |
| 5 | S3 Intelligent-Tiering | Deep Archive 계층 최대 95% | 낮음 | 즉시 | 검색 지연(아카이브) |
| 6 | S3 Glacier Deep Archive | $0.00099/GB·월 | 낮음 | 즉시 | 복원 시간·비용 |
| 7 | CloudFront 캐싱 | 오리진 전송량 감소 | 중간 | 설정 필요 | 캐시 무효화 관리 |
| 8 | NAT 데이터비 절감 | VPC 엔드포인트로 우회 | 중간 | 설계 검토 | 엔드포인트 비용 |
| 9 | 미사용 리소스 청소 | 누수분 전액 제거 | 낮음 | 즉시 | 삭제 전 확인 |
| 10 | 비용 가시화·라이트사이징 | 과대 사양 축소 | 낮음 | 지속 | 성능 여유 확인 |

위 차트는 절감 수단별 최대 할인율(온디맨드 대비, AWS 공식 up-to 기준)을 한눈에 본 것입니다. Graviton의 40%는 가격 절감이 아니라 가격 대비 성능(price-performance) 기준이고, 단순 단가는 x86 대비 최대 20% 저렴이라는 점을 구분해야 합니다. 차트 숫자는 어디까지나 천장값이라, "이만큼 확정으로 줄어든다"가 아니라 "최대 이 정도까지 가능"으로 읽어야 AWS 비용 절감 계획을 현실적으로 세울 수 있습니다.
표를 보면 알 수 있듯 난이도 낮음 + 즉시 적용 가능한 1·2·5·6·9·10번이 가성비가 가장 좋은 항목입니다. 약정만 걸거나 미사용 리소스를 지우는 일은 코드 변경이 없어서 리스크가 작습니다. 반대로 3·4번은 효과는 크지만 워크로드 분리나 호환성 테스트가 필요해서, 검증 없이 운영에 바로 넣으면 오히려 장애 비용이 더 큽니다.
컴퓨팅부터 — Savings Plans·Spot·Graviton
청구서에서 EC2 비중이 가장 크다면 컴퓨팅부터 손대는 게 효과가 큽니다. AWS 비용 절감에서 가장 큰 덩어리는 보통 컴퓨팅, 여기서 줄이면 체감이 빠릅니다. 순서는 약정 → Graviton → Spot입니다.
Savings Plans는 온디맨드 대비 최대 66%(Compute SP), EC2 인스턴스 SP나 Reserved Instance는 최대 72%까지 내려갑니다. AWS는 인스턴스 종류를 바꿔도 할인이 유지되는 Savings Plans를 더 유연한 선택지로 안내합니다. RI는 인스턴스 패밀리가 고정되는 대신, 변경 가능한 Convertible RI도 최대 54% 수준입니다. 1년 내 사양을 바꿀 가능성이 있으면 SP가 마음이 편합니다.
Graviton(ARM) 전환은 x86 대비 최대 20% 저렴하고, AWS는 가격 대비 성능을 최대 40%까지 본다고 안내합니다. 관리형 서비스(RDS·Aurora 등)는 인스턴스 클래스만 Graviton 계열로 바꾸면 코드 변경 없이 전환되는 경우가 많습니다. 다만 직접 빌드하는 애플리케이션은 ARM 재빌드가 필요할 수 있어서, 운영 반영 전 스테이징에서 반드시 테스트해야 합니다. 여기서 한 번 데인 적이 있는데, 네이티브 의존성이 있는 패키지가 ARM 휠을 안 줘서 빌드가 깨진 경우가 있었습니다. 순수 런타임 기반이면 대체로 무난하지만, C 확장이 섞이면 미리 확인하는 게 안전합니다.
Spot Instances는 온디맨드 대비 최대 90%까지 저렴한 대신 변동성이 큽니다. AWS가 용량을 회수하면 2분 전 통보 후 중단되기 때문에, 상태를 저장하지 않는 배치·CI/CD·렌더링 같은 내결함성 워크로드에만 써야 합니다. 운영 DB나 세션을 들고 있는 서버에 Spot을 쓰면 갑자기 꺼져서 장애로 직결됩니다. "싸니까 다 Spot으로" 같은 결정이 제일 위험한 선택이죠.
스토리지·데이터 전송 — S3 클래스·CloudFront·NAT
컴퓨팅 다음으로 새는 곳이 스토리지와 데이터 전송입니다. 둘 다 "방치된 데이터"와 "잘못 흐르는 트래픽"이 핵심이라, AWS 비용 절감에서 의외로 놓치기 쉬운 영역입니다.
S3 Intelligent-Tiering은 접근 빈도에 따라 자동으로 계층을 옮겨줍니다. 자주 안 쓰는 데이터는 IA 계층으로, 거의 안 쓰는 건 Archive Instant나 Deep Archive 계층으로 내려가면서 단가가 떨어집니다. 가장 저렴한 Glacier Deep Archive는 GB당 월 $0.00099(약 $1/TB·월) 수준이라, 백업·로그처럼 거의 안 꺼내는 콜드 데이터를 Standard에 그대로 두는 건 돈을 흘리는 셈입니다. 단, 아카이브 계층은 복원에 시간과 비용이 들어서 자주 꺼내는 데이터엔 부적합합니다.
데이터 전송에서 가장 많이 놓치는 게 NAT Gateway입니다. NAT는 시간당 $0.045 + 데이터 처리 $0.045/GB가 붙는데, 프라이빗 서브넷에서 S3·DynamoDB 같은 AWS 서비스로 나가는 트래픽까지 전부 NAT를 거치면 데이터 처리비가 계속 쌓입니다. VPC 엔드포인트(게이트웨이/인터페이스)를 쓰면 이 트래픽이 NAT를 안 거쳐서 데이터비를 줄일 수 있습니다. 인터넷으로 나가는 트래픽은 CloudFront로 캐싱하면 오리진(EC2·S3)에서 직접 나가는 전송량이 줄어, CloudFront 아웃(초과 구간 약 $0.09/GB)으로 묶으면서 오리진 부하도 같이 내려갑니다.
이 영역은 Docker 이미지 크기를 최대 99%까지 줄이는 방법에서 다룬 것과 결이 비슷합니다. 이미지 용량이든 전송 트래픽이든, "필요 없는 걸 안 흘려보내는 것"이 가장 확실한 절감이라는 점은 똑같습니다.
미사용 리소스 청소 + 비용 가시화
AWS 비용 절감 중 가장 빠르고 안전한 건 놀고 있는 리소스를 지우는 것입니다. 코드 변경도, 약정도 필요 없습니다.

대표적인 누수 항목은 다음 순서로 점검합니다.
1. 분리된 EBS 볼륨 → 미사용도 $0.10/GB·월 (gp2 기준) 계속 과금
2. 미연결 Elastic IP → 인스턴스에 안 붙은 EIP 과금
3. 유휴 Public IPv4 → 2024-02부터 모든 Public IPv4에 $0.005/IP·시간 과금
4. 중단된 인스턴스의 잔여 스토리지·스냅샷
5. 놀고 있는 로드밸런서·NAT (트래픽 없는데 시간당 과금)
Public IPv4 과금은 2024년 2월부터 전면 적용됐는데, 이걸 모르고 안 쓰는 IP를 그대로 들고 있는 경우가 많습니다. IP 하나당 시간당 $0.005면 작아 보여도, 개수가 쌓이고 1년이 지나면 무시 못 할 금액이 됩니다.
청소와 동시에 비용 가시화를 붙여야 다시 안 샙니다. Cost Explorer로 서비스별 추세를 보고, Compute Optimizer로 과대 사양 EC2·EBS를 찾아 라이트사이징하고, Budgets로 임계치 알림을 걸어둡니다. 라이트사이징의 절감폭은 환경마다 달라서 "몇 % 줄어든다"고 단정할 수 없지만, 추천만 따라가도 과대 사양은 거의 잡힙니다. 이 부분은 Sentry vs Datadog vs New Relic 모니터링 비교 2026에서 정리한 "비용 가시화" 관점과도 통합니다. 안 보이면 못 줄입니다.
함정 박스 — 프리티어·EIP·NAT 데이터비
⚠️ 프리티어가 끝나는 순간이 가장 위험합니다.
처음 인프라를 올릴 때 프리티어만 믿고 ALB·NAT Gateway를 켜뒀다가, 막상 청구서를 보고 놀란 적이 있습니다. ALB와 NAT Gateway는 프리티어 대상이 아닙니다. 트래픽이 없어도 시간당 과금이 계속 붙습니다. 프리티어 12개월이 끝나면 EC2·RDS·Public IPv4가 정상 과금으로 전환되는데, 이걸 캘린더에 안 적어두면 그달 청구서가 갑자기 뜁니다.
세 가지 함정을 따로 짚습니다.
- 프리티어 만료: 12개월 후 EC2·RDS·Public IPv4가 정상 과금. ALB·NAT는 처음부터 프리티어 없음. 가입일 기준으로 만료일을 미리 메모해 두는 게 안전합니다.
- 미연결 EIP·유휴 IPv4: 안 붙은 EIP, 안 쓰는 Public IPv4도 과금됩니다. 정기적으로 콘솔에서 미연결 상태를 확인하세요.
- NAT 데이터 처리비: 시간당 요금보다 데이터 처리 $0.045/GB가 더 무서울 때가 있습니다. AWS 서비스로 가는 트래픽은 VPC 엔드포인트로 빼서 NAT를 안 거치게 하는 게 핵심입니다.
정답은 하나로 정해져 있지 않습니다. 트래픽이 적고 가변적이면 Spot·서버리스가 낫고, 부하가 일정하고 장기로 돌릴 거면 Savings Plans 약정이 낫습니다. 본인 청구서에서 비중이 큰 곳부터 위 표의 난이도 낮은 항목으로 시작하면, 리스크 없이 줄일 수 있는 부분이 먼저 잡힙니다.
Q&A — 자주 보는 질문 5개
Q. AWS 비용이 갑자기 늘었는데 어디부터 봐야 하나요?
A. Cost Explorer를 서비스별로 정렬해서 비중이 큰 순서대로 봅니다. 보통 EC2·데이터 전송·NAT Gateway·미사용 EBS 순으로 새는 경우가 많습니다. 전월 대비 급증한 서비스를 먼저 클릭해 들어가면 원인이 빨리 보입니다.
Q. 프리티어가 만료되면 비용이 얼마나 늘어나나요?
A. 가입 12개월 후 EC2·RDS·Public IPv4가 정상 과금으로 전환됩니다. 금액은 인스턴스 사양과 사용량에 따라 달라 단정할 수 없습니다. 다만 ALB와 NAT Gateway는 처음부터 프리티어 대상이 아니라 트래픽이 없어도 시간당 과금이 붙는다는 점을 기억하세요.
Q. Savings Plans와 Reserved Instance 중 뭘 골라야 하나요?
A. AWS는 인스턴스 종류를 바꿔도 할인이 유지되는 Savings Plans를 더 유연한 선택지로 안내합니다. 최대 절감폭은 양쪽 다 최대 72% 수준으로 비슷합니다. 1년 안에 사양을 바꿀 가능성이 있으면 SP, 인스턴스가 확실히 고정이면 RI도 괜찮습니다.
Q. Graviton으로 바꾸면 코드를 다시 짜야 하나요?
A. Graviton은 ARM 기반이라 직접 빌드하는 애플리케이션은 재빌드가 필요할 수 있습니다. 반면 RDS·Aurora 같은 관리형 서비스는 인스턴스 클래스만 바꾸면 코드 변경 없이 전환되는 경우가 많습니다. 어느 쪽이든 운영에 넣기 전 스테이징 테스트는 필수입니다.
Q. Spot Instance가 갑자기 꺼지면 어떻게 되나요?
A. AWS가 용량을 회수하면 2분 전 통보 후 중단됩니다. 그래서 상태를 저장하지 않는 배치·CI/CD·렌더링 같은 내결함성 워크로드에만 적합합니다. 운영 DB나 세션을 들고 있는 서버에는 부적합하니 온디맨드나 약정으로 두세요.
같은 환경이면 위 우선순위대로 따라가도 무리 없습니다. 청구서에서 비중이 큰 곳부터, 난이도 낮은 항목으로 시작하세요. 블로그의 다른 글도 한번 둘러봐 주세요.
기준: us-east-1 온디맨드 단가, AWS 공식 발표(up-to) 기준 · 선별 기준일 2026-06-24 · 실제 절감폭은 워크로드별로 상이
'IT > Information' 카테고리의 다른 글
| JWT·OAuth2·세션 + 인증 SaaS 비교 — 백엔드 인증 방식 선택 기준 (1) | 2026.07.01 |
|---|---|
| 개발팀 SaaS 도구 12가지 — 5인 팀 실비용 매트릭스 (무료 조합) (0) | 2026.06.28 |
| yarn vs npm vs pnpm — 설치 속도·디스크·monorepo 실측 비교 (0) | 2026.06.23 |
| 도메인 종류 가이드 — .com·.net·.co.kr·.io·.ai·.dev 차이와 선택법 (0) | 2026.06.19 |
| Sentry vs Datadog vs New Relic — 한국 스타트업 모니터링 도구 비교 2026 (0) | 2026.06.15 |
IT 기술과 개발 내용을 포스팅하는 블로그
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!