AWS 청구서 분석기

AWS Cost Explorer CSV를 브라우저에서 분석합니다. 서비스 / 리전 / 태그별 분해, 상위 지출 항목, 전월 대비 변동, 자연어 요약을 표시합니다. 파일은 서버로 전송되지 않습니다.

Loading…

모든 처리는 브라우저 내부에서 실행됩니다 — 파일·입력은 서버로 전송되지 않습니다.

사용법

AWS 청구 콘솔(Cost Explorer → "Save report as CSV")에서 **Cost Explorer CSV**를 내보내고 본 페이지에 드래그합니다. Cost Explorer는 일별 또는 월별 단위에 대응하며 서비스·리전·연결 계정·태그·과금 유형·인스턴스 유형 등 임의의 그룹화 차원을 지원합니다. 본 분석기는 파일의 기간 간격에서 단위를 자동 감지하고, 기간 간격이 모호한 단일 기간 내보내기에는 수동 전환을 제공합니다. 상위 10 항목, 다기간 CSV의 전월 대비 변동, 자연어 요약(페이지 로케일에 따른 en/ja/ko)이 즉시 생성됩니다. 이해관계자 공유용 구조화된 PDF 보고서 다운로드도 가능합니다.

파서는 **브라우저 안에서 완결**됩니다. Cost Explorer 내보내기에는 계정 ID, 리소스 식별자, 태그 값(고객명이나 사내 프로젝트명을 포함하는 경우가 많음)이 들어 있으므로 본 도구는 의도적으로 네트워크 왕복을 피합니다. 구현은 순수 TypeScript로 작성된 스트리밍 CSV 파서와 집계 로직이며, PDF 내보내기는 CJK 대응 폰트 번들이 포함된 pdf-lib를 사용해 다운로드된 보고서에서도 일본어·한국어 라벨이 정확하게 렌더링됩니다. 비용 수치는 CSV의 원본 통화로 표시됩니다(일본인·한국인 결제자도 USD로 청구되어 신용카드 명세서에서 현지 통화로 환산되는 것이 일반적). 본 도구는 환율 변환을 *하지 않습니다*. 지원 CSV 변형: 표준 Cost Explorer 내보내기(2018년 이후 형식), Cost & Usage Reports(CUR)의 기본 Athena 내보내기, 레거시 "AWS Detailed Billing Report"(2018년 이전) — 파서가 헤더 행에서 형식을 자동 감지합니다.

예제

월별 서비스 분해 — 전형적인 SaaS 스타트업

입력
CSV:           cost-explorer-2026-04.csv
periods:       3 months (2026-02, 2026-03, 2026-04)
groupBy:       Service
rows:          ~40 services with non-zero usage
total April:   $4,820
출력
Top line items (April):
  1. EC2-Other (NAT Gateway data + EBS): $1,140  +18% MoM
  2. RDS (Aurora MySQL):                  $890   +3% MoM
  3. EC2 instances (t3.large × 4):        $740   flat
  4. CloudFront:                          $410   −12% MoM
  5. S3 Standard:                         $280   +44% MoM ⚠
  6. CloudWatch Logs:                     $260   +9% MoM
  7. Lambda:                              $190   +2% MoM
  ...

Narrative: April spend grew $310 (+6.9%) over March, driven primarily by
NAT Gateway data egress and S3 Standard storage. S3 is up 44% over two
months — worth checking for runaway log dumps or test buckets.

소규모 팀의 일상적인 월별 검토입니다. 자동 생성 요약은 S3의 44% 성장을 강조 표시합니다. 절댓값($280)은 작지만 성장 속도가 현재 수준보다 더 중요하기 때문입니다. 월 44% 증가는 연간 800%로 복리화됩니다. NAT Gateway는 자체 항목이 아닌 "EC2-Other" 아래에 나타나며, 이는 RDS나 DocumentDB를 프라이빗 서브넷에 두고 OS 패키지 업데이트를 위해 NAT로 라우팅하는 팀에서 비용 충격의 빈번한 원인입니다. 본 도구는 groupBy=UsageType으로 원시 NAT Gateway 차원을 노출하므로 급증이 데이터 전송 때문인지 유휴 게이트웨이 시간 때문인지 확인할 수 있습니다.

리전 이상 탐색 — 멀티리전 운영

입력
CSV:        cost-explorer-2026-05-daily.csv
granularity: daily
period:      30 days
groupBy:     Region
rows:        9 regions in active use
출력
Top regions (May, 30-day total):
  ap-northeast-1 (Tokyo):  $6,420  78% of total
  us-east-1   (Virginia):  $1,140  14% — control plane + Route53
  ap-northeast-2 (Seoul):   $620    7% — DR region
  global region (CloudFront): $80    1%
  eu-west-1 (Ireland):       $20    0% ⚠ unexpected

Narrative: 99% of spend is in your primary region (Tokyo) and DR
region (Seoul) as expected. Notable: $20 in eu-west-1 was incurred on
May 12 — possibly a leftover test resource. Check the EC2 console
for running instances in that region.

리전별 보기는 잊혀진 테스트 리소스를 찾는 가장 좋은 방법입니다. AWS 리소스는 리전 스코프이므로 6개월 전 튜토리얼을 읽으며 `eu-west-1`에 테스트 스택을 띄운 개발자가 그것을 무기한 가동 상태로 남길 수 있습니다. 일별 비용은 작아서 청구 알림을 트리거하지 않지만 누적되어 월별 내보내기에 유령 리전으로 나타납니다. 같은 패턴은 잊혀진 EBS 스냅샷, 유휴 NAT 게이트웨이, 미할당 Elastic IP에도 적용됩니다. 본 도구의 요약은 총지출의 0~2%를 차지하는 리전을 "조사할 가치 있음"으로 명시적으로 표시합니다. 그 대역에 잔여물이 모이기 때문입니다.

태그 기반 사내 차지백 — 어느 팀이 얼마를 썼는가

입력
CSV:        cost-explorer-2026-04-by-team-tag.csv
groupBy:    Tag: team
period:     April 2026
activation: cost allocation tag "team" enabled for >30 days
출력
By team tag (April):
  team:platform      $2,820  58% — RDS + EC2 + NAT
  team:billing       $890    18% — RDS + Lambda + S3
  team:analytics     $560    12% — Athena + S3 + Glue
  team:onboarding    $310     6% — CloudFront + Lambda
  (untagged)         $240     5% ⚠

Narrative: 95% of April spend is tagged, leaving $240 (5%) untagged.
The untagged share is high enough to indicate either a missing
tag-enforcement policy or recently-created resources predating
the tag-activation date.

비용 할당 태그는 AWS가 공식적으로 지원하는 차지백 메커니즘입니다. 사용법: (1) 태그 키를 결정(`team`, `project`, `cost-center`), (2) 리소스 전반에 일관되게 적용, (3) 청구 콘솔 → "Cost allocation tags"에서 태그를 활성화 — 이것이 대부분의 팀이 놓치는 단계입니다. 활성화된 태그는 24시간 후 Cost Explorer에 나타나지만 데이터는 활성화 날짜 이후에만 소급 집계되므로 과거 데이터는 태그가 없는 채로 남습니다. "(untagged)" 버킷은 현실적이고 반복되는 차지백 분쟁입니다. 아무도 소유하지 않는 리소스의 비용은 누가 내는가? 표준적인 답은 공유 "플랫폼"이나 "운영" 코스트 센터에 청구하는 것이며, 이는 시간이 지나며 태그 위생에 인센티브를 제공합니다.

자주 묻는 질문

Cost Explorer에서 CSV를 내보내려면?

**AWS 청구 콘솔**에 로그인 → **Cost Explorer** → 기간, 단위(Daily / Monthly), Group By 차원(Service가 가장 유용한 기본값)을 설정합니다. **Save**(우측 상단) → **Save report**로 보기를 즐겨찾기하거나 **Download CSV**로 원시 데이터를 가져옵니다. CSV 형식은 2018년 이후 안정적입니다. 그 이전 내보내기는 다른 레이아웃을 사용하며 본 도구도 이를 자동 감지합니다. Cost Explorer는 유료 기능입니다. 프로그램 API 액세스는 **1,000 요청당 $0.01**이지만 콘솔 기반 CSV 내보내기는 무료입니다. 무인 자동화가 필요하다면 **Cost & Usage Reports(CUR)**를 S3에 전달하는 것이 옳은 경로지만 CUR은 대부분의 분석이 필요로 하는 것보다 훨씬 크고 상세한 형식입니다.

Cost Explorer·CUR·Billing Dashboard의 차이는?

3개의 별도 AWS 청구 화면이며 목적은 겹치지만 다릅니다. **Billing Dashboard**는 고수준의 "이번 달 현재까지 + 지난달" 요약으로 무료·읽기 전용입니다. 한눈에 보는 헬스 체크에 유용합니다. **Cost Explorer**는 인터랙티브 분석 도구로 서비스·리전·태그로 필터링, 기간 비교, 차원 그룹화가 가능합니다. 대부분의 엔지니어와 재무팀이 일상적으로 실제로 사용하는 것이며 본 분석기도 이를 중심으로 만들어졌습니다. **Cost & Usage Reports(CUR)**는 파이어호스로 모든 라인 아이템, 모든 리소스, 모든 시간이 gzip 압축된 CSV/Parquet으로 S3 버킷에 전달됩니다. CUR은 FinOps 자동화, QuickSight나 Athena를 통한 커스텀 대시보드, 청구 라인 아이템과의 대조를 위한 진실의 원천이지만 효과적으로 사용하려면 Athena/Spark 수준의 도구가 필요합니다. 대략적으로: 대시보드는 모니터링, Cost Explorer는 분석, CUR은 FinOps 엔지니어링. 본 도구는 Cost Explorer 내보내기와 부분적인 CUR 내보내기를 읽습니다.

NAT Gateway가 항상 상위 비용 항목에 드는 이유는?

NAT Gateway 가격 체계에는 2가지 놀라움이 있습니다. 첫째, **트래픽이 0이어도 게이트웨이당 시간 $0.045 × 24시간 × 30일 = 월 $32의 시간 요금**이 발생합니다. AWS 문서는 이를 명시하지만 엔지니어는 보통 데이터 처리 요금에 주목하고 시간 요금을 잊습니다. AZ로 곱하면(HA를 위한 모범 사례는 AZ당 1개 NAT) 트래픽 발생 전에 월 $100을 쉽게 넘습니다. 둘째, **$0.045/GB의 데이터 처리 요금은 게이트웨이를 통과하는 *모든* 트래픽에 적용**됩니다. 여기에는 프라이빗 서브넷 → 퍼블릭 인터넷(명백한 경우)*과* 프라이빗 서브넷 → 퍼블릭 엔드포인트를 통한 AWS 서비스(예: ECR 풀, VPC 엔드포인트 미사용 시 S3, 패키지 관리자, OS 업데이트)가 포함됩니다. 수정은 **VPC 엔드포인트**입니다. S3 게이트웨이 엔드포인트는 무료이고 다른 서비스용 인터페이스 엔드포인트는 시간 $0.01지만 해당 서비스에 대해서는 NAT 게이트웨이를 완전히 우회합니다. 인터페이스 엔드포인트와 NAT 데이터 요금의 손익분기점은 엔드포인트당 약 월 5 GB입니다.

멀티 계정·Organization 레벨 CSV를 지원하나요?

네 — AWS Organization의 **결제 계정**의 Cost Explorer는 "Linked account" 차원으로 통합 청구를 표시합니다. Linked Account로 그룹화하면 계정별 합계가 보입니다. 결과 CSV는 본 도구에서 단일 계정 CSV와 동일하게 동작합니다. **수백 개 계정의 AWS Organization**에서는 Cost Explorer의 내장 UI가 비좁아집니다. 상위 10 리스트가 금세 동나며, CUR 위의 QuickSight 대시보드로 이전하고 싶어질 수 있습니다. 본 도구는 중소 규모 사례용입니다. 1~20개 계정, 1~50개의 서로 다른 비용 귀속 차원. 그 이상이 되면 병목은 더 이상 파싱이나 시각화가 아니라 예산표를 응시하는 인간의 인지 한계입니다.

Cost Explorer 수치는 얼마나 정확한가요? 최종 청구서와 일치하나요?

**약 1% 이내지만 바이트 단위로 동일하지는 않습니다.** Cost Explorer 수치는 *적용된* 비용입니다. 예약 인스턴스·Savings Plan 할인, 크레딧, 할인 적용 후 실제로 지불하는 금액이지만 최종 청구서의 라인 아이템과 약간 다른 반올림을 합니다. 월말 청구서는 월 마감 후 3~5일 후에 생성되고 Cost Explorer는 최대 24시간 지연으로 매일 업데이트됩니다. 엣지 케이스: 프리 티어 크레딧은 Cost Explorer에 적용된 달의 "Refund" 행으로 나타납니다(크레딧 부여 후 몇 달일 수도 있음). 일부 마켓플레이스 요금(Bedrock·서드파티 AMI)은 지연된 대조를 거칩니다. AWS 지원 요금은 플랜에 따라 총지출의 3% / 5% / 10%로 월별 청구되며 별도 차원으로 표시됩니다. 회계 수준 정확성에는 청구 콘솔의 **PDF 청구서**를 사용하세요. 엔지니어링 수준 귀속(어느 워크로드가 어느 지출을 일으켰는지)에는 Cost Explorer가 옳은 화면입니다.

Cost Explorer와 병행해 사용해야 할 다른 도구는?

지속적인 FinOps 작업에는 Cost Explorer를 보완하는 3가지 도구가 유용합니다. **AWS Budgets**는 임계값 초과 시 이메일로 알림을 보냅니다. 월 목표의 80%에 1개 예산, 120%("뭔가 잘못된" 티어)에 1개 예산을 설정합니다. **AWS Compute Optimizer**는 CloudWatch 메트릭의 머신러닝 분석으로 언더사이즈·오버사이즈 EC2·EBS·Lambda·ECS 워크로드를 식별합니다. 안정적인 워크로드에서는 권장 사항이 보통 정확합니다. **AWS Cost Anomaly Detection**은 일반적인 지출을 학습하고 서비스가 훈련된 기준선에서 40% 이상 벗어났을 때 이메일을 보내는 무료 서비스로, 잊혀진 리소스나 폭주한 테스트 환경 포착에 유용합니다. AWS 외에는 **Vantage**·**CloudZero**·**Datadog Cloud Cost Management**가 크로스 클라우드 통합과 더 깊은 귀속을 제공합니다. **Infracost**는 배포 전에 Terraform 변경의 비용 영향을 추정해 청구 시점이 아닌 PR 리뷰 시점에 고비용 리소스를 포착합니다.

관련 개념

**FinOps**(Financial Operations)는 2018년경 대규모 AWS·Azure·GCP 환경을 운영하는 회사들에서 출현한 클라우드 비용 관리 규율입니다. **FinOps Foundation**(현재 Linux Foundation의 일부)은 3단계 프레임워크를 유지합니다. *Inform*(비용 가시화), *Optimize*(라이트사이징과 약정을 통한 비용 절감), *Operate*(가용성이나 지연 시간 같은 지속적 엔지니어링 지표로서의 비용). 본 도구는 Inform 단계의 한가운데에 위치합니다. CSV 내보내기를 소화하기 쉬운 스냅샷으로 변환합니다. 이 위의 성숙도 사다리는 서비스별 비용 귀속 대시보드(Optimize)와 PR별 비용 영향 게이트(Operate)입니다. AWS에서 연 $10M 이상을 쓰는 회사는 전담 FinOps 팀을 두는 것이 일반적이고, 더 작은 조직은 SRE와 재무에 작업을 분산합니다.

AWS의 **비용 데이터 모델**에는 3개의 청구 화면 모두(Dashboard·Cost Explorer·CUR)에 등장하는 흥미로운 4가지 차원이 있습니다. **Service**는 명백한 것(EC2·S3·RDS)이지만 서비스에는 하위 범주가 있습니다. "EC2-Other"는 구체적으로 NAT Gateway·EBS·데이터 전송 요금을 EC2 컴퓨트 서비스 자체와 별도로 버킷화합니다. **Usage type**은 가장 미세한 단위입니다(예: `BoxUsage:t3.large` 대 `EBS:VolumeUsage.gp3`). 여기서 *실제로* 지출을 일으키는 것을 찾을 수 있습니다. **비용 할당 태그**는 사용자 정의이며 청구 콘솔에서 명시적 활성화 후에만 데이터가 들어옵니다. 팀별·프로젝트별 차지백을 가능하게 합니다. **Charge type**은 Usage·Tax·Credit·Refund·정기 예약 인스턴스·Savings Plan 상각을 구분합니다. 회계팀은 이 차원에 크게 신경 쓰고 엔지니어는 덜합니다. 어느 차원이 어느 질문에 답하는지 이해하는 것이 효과적인 비용 분석의 절반입니다.

3가지 **클라우드 비용 인접 개념**이 AWS 청구 분석과 교차합니다. **예약 인스턴스(RI)와 Savings Plan**은 약정 기반 할인입니다. 1년 또는 3년 사용에 선불 지불하고 온디맨드 요금에서 30~60% 할인. 절감액은 Cost Explorer에 음수 라인 아이템으로 소급 표시됩니다. **스팟 인스턴스**는 50~90% 할인으로 이용 가능한 미사용 EC2 용량이지만 2분 종료 통지의 대상입니다. 배치 워크로드에는 훌륭하고 스테이트풀 서비스에는 최악입니다. **멀티클라우드 비용 정규화**는 AWS의 라인 아이템 형식을 Azure의 "Cost Management" 내보내기와 GCP의 "Billing" 내보내기와 비교하는 운영상의 악몽입니다. 차원은 유사하지만 경계(무엇이 "컴퓨트"·"스토리지"·"네트워크"로 계산되는가)는 집계 대시보드에 수동 정규화를 요구할 만큼 다릅니다. Vantage나 CloudZero 같은 도구가 존재하는 이유는 주로 이 정규화가 운영상 고통스러워 회사가 월 수천 달러를 지불해 외주를 줄 가치가 있기 때문입니다.

관련 글

관련 도구