AWS의 상세 비용 데이터를 새로 받으려면, 기존 CUR 설명보다 Data Exports에서 CUR 2.0 표준 내보내기를 먼저 검토하는 편이 맞습니다. AWS는 CUR 2.0을 상세 비용·사용량 데이터를 받는 새롭고 권장되는 방식으로 안내합니다. 다만 모든 열과 리소스 ID를 무조건 켜면 파일과 처리량이 커질 수 있으므로, 보고 목적을 정한 뒤 필요한 범위만 선택하세요.
이 글은 2025년의 기존 CUR 개요를 현재 절차로 갱신한 것입니다. 공식 문서 확인일은 2026년 9월 9일이며, 실제 계정의 비용·권한·S3 정책은 확인하지 않은 일반 안내입니다.
CUR·CUR 2.0·Data Exports를 먼저 구분하기
| 질문 | 현재 선택 | 확인할 점 |
|---|---|---|
| 새 상세 비용 내보내기를 만들까? | Data Exports의 CUR 2.0 표준 내보내기 | AWS가 새롭고 권장되는 방식으로 안내 |
| 기존 파이프라인이 Legacy CUR만 읽는가? | 기존 CUR를 바로 삭제하지 말고 별도 전환 계획 | 스키마·경로·쿼리 호환성을 실제로 검증 |
| 서비스별 비용 증가 원인을 빨리 볼까? | Cost Explorer부터 조사 | CUR 2.0은 장기 원천 분석·재현용 데이터 |
| 공용 ECS/EKS 비용을 자세히 나눌까? | Split cost allocation data 여부 검토 | 행 수가 크게 늘 수 있음 |
Data Exports는 콘솔뿐 아니라 AWS CLI·SDK에서도 만들 수 있고, SQL로 열을 고르거나 행을 걸러 출력 스키마를 제어할 수 있습니다. 이 글의 콘솔 절차는 첫 설정을 위한 안내이며, 조직의 데이터 최소화·보존 규칙은 별도로 적용하세요.
시작 전 4가지 결정
- 사용 목적: 월간 경영 보고, 태그 품질 점검, 비용 급증 재현 중 하나를 먼저 적습니다.
- 비용 기준과 범위: 비교 기간, 계정 범위, 통화·할인 포함 여부를 보고서마다 고정합니다.
- 소비자: Athena로 조회할 팀인지, Redshift로 적재할 팀인지 정합니다. 설정 형식과 파일 관리 방식이 달라질 수 있습니다.
- 검증 담당자: 첫 파일이 도착한 뒤 S3 경로·갱신 시각·행 수·대표 계정/서비스 열을 확인할 담당자를 지정합니다.
Data Exports에서 CUR 2.0 만드는 순서
- Billing and Cost Management 콘솔의 Data Exports에서 Create export를 선택합니다.
- Standard data export와 CUR 2.0 테이블을 선택합니다.
- 청구 보기(Billing view)를 쓰는 조직이면 Type과 View가 보고 범위와 맞는지 확인합니다. 보기를 쓰지 않는 계정은 임의의 값을 추정해 넣지 마세요.
- 시간 단위는 시간·일·월 중 분석 질문에 맞게 선택합니다. 세밀한 단위일수록 데이터 크기와 후속 쿼리 비용을 함께 검토합니다.
- 필요한 열만 고릅니다. 리소스 ID를 포함하면 개별 리소스 행이 생성되고, 사용자·계정·Cost Category·리소스 정보를 담는 Tag 열도 추가될 수 있어 파일 크기가 늘 수 있습니다.
- ECS task 또는 EKS pod 수준의 공유 리소스 원가가 꼭 필요한 경우에만 Split cost allocation data를 선택합니다. 이 옵션도 개별 행을 늘릴 수 있습니다.
- S3 버킷과 고유한 경로 접두사를 정하고, 표시되는 버킷 정책을 검토합니다. 기존 버킷을 선택하면 AWS가 해당 정책을 덮어쓸 수 있다는 안내가 있으므로 정책 변경 권한과 영향을 먼저 확인하세요.
- Athena를 쓸 경우 AWS가 안내하는 Parquet·기존 파일 덮어쓰기 통합 옵션을 검토합니다. 변경 이력 보존이 목적이면 새 버전 파일을 만드는 방식과 저장 비용의 균형을 문서화하세요.
첫 배송 뒤 확인할 체크리스트
- 내보내기 이름·S3 버킷·경로 접두사가 팀의 데이터 목록에 기록되어 있는가
- CUR 2.0 테이블과 선택한 시간 단위·열·리소스 ID·공유 비용 옵션이 의도와 같은가
- 첫 파일이 도착했는가. AWS는 새 Legacy CUR 보고서의 첫 배송에 최대 24시간이 걸릴 수 있다고 안내하며, Data Exports의 청구·비용 데이터는 하루 최대 한 번 갱신됩니다.
- 대표 계정·서비스·기간으로 표본 조회했을 때, 콘솔에서 비교한 범위와 같은 질문을 하고 있는가
- 파일 크기·Athena 스캔량·권한 오류를 월간 비용 보고서에 별도로 기록했는가
가상 검증 예시: ‘2026년 9월 A 계정의 특정 서비스 비용’을 점검한다면, 내보내기 경로·갱신 시각·해당 계정/서비스 열이 존재하는지를 먼저 확인한 뒤 Cost Explorer의 같은 기간·같은 비용 기준과 비교합니다. 두 숫자가 다르면 오류라고 단정하지 말고 시간 단위, 할인·크레딧 반영, 데이터 갱신 시점, 필터를 한 항목씩 대조하세요. 이는 실제 계정 결과가 아닌 검증 절차 예시입니다.
자주 생기는 혼동
- ‘CUR은 사용량 데이터일 뿐’이라는 설명: 비용과 사용량을 함께 분석하는 원천 데이터이므로, 비용 기준·기간·필터를 같이 기록해야 재현할 수 있습니다.
- Cost Categories의 split charge와 CUR 2.0을 같은 것으로 보는 경우: Cost Categories 화면의 공용비용 배부 결과가 CUR·Cost Explorer 원천 값을 자동으로 바꾸지는 않습니다. 경영 배부표와 원천 데이터 분석을 섞지 마세요.
- 리소스 ID를 항상 켜는 경우: 필요한 분석에는 유용하지만 행과 파일 크기를 키울 수 있습니다. 데이터 최소화와 비용을 함께 검토하세요.
- 새 CUR 2.0을 만들며 Legacy CUR를 즉시 중단하는 경우: 기존 Athena 테이블·ETL·대시보드가 새 스키마와 경로에서 동작하는지 병행 검증 후 전환합니다.
다음 작업으로 연결하기
당장 비용이 증가한 이유를 좁힐 때는 Cost Explorer와 Amazon Q 비용 조사 가이드에서 비교 조건을 먼저 맞추세요. 팀별 공용비용 설명은 Cost Categories 공용비용 배부 가이드에서 원천 데이터와의 차이를 확인할 수 있습니다. AI 호출 주체별 비용은 Bedrock IAM 기준 비용 추적 가이드, 전체 운영 순서는 AWS 비용 관리 시작하기로 이어집니다.
공식 출처와 확인일
- AWS Data Exports: What is AWS Data Exports? — 문서 내 발행·수정일 미표시, 확인 2026-09-09
- AWS Data Exports: Creating a standard export — 문서 내 발행·수정일 미표시, 확인 2026-09-09
- AWS Data Exports: Data query—SQL query and table configurations — 문서 내 발행·수정일 미표시, 확인 2026-09-09
- AWS Data Exports: Creating reports (Legacy CUR) — 문서 내 발행·수정일 미표시, 확인 2026-09-09
기능·열·청구 보기·S3 정책·지원 범위는 바뀔 수 있으므로 설정 직전에 위 AWS 원문을 다시 확인하세요. 이 글은 세무·결산·계약상 비용 배부 기준을 정하는 조언이 아닙니다.
답글 남기기