Cost Explorer와 Billing으로 DynamoDB Provisioned 테이블 범위를 좁히는 방법

2026. 6. 4.

Issue

2026.03부터 DynamoDB의 RCU 관련 비용이 계속 높게 나왔다.

우리 팀은 매월 DynamoDB의 RCU와 WCU를 보고 미리 capacity를 구매할지 판단하는데, 2026.03부터 2026.05까지 3개월 연속으로 RCU가 높게 유지됐다.

문제는 우리 팀이 사용하는 DynamoDB 테이블이 환경별로 60~70개 정도로 꽤나 많아 하나하나 확인하기가 어려웠다. 바로 특정 테이블을 뒤지기보다, 먼저 어떤 부류의 테이블부터 봐야 하는지 범위를 줄이는 것이 필요했다.

이번에 바로 찾고 싶었던 것은 “RCU가 높아진 정확한 테이블”이 아니라, 어떤 테이블 집합부터 봐야 하는지였다.

우선 AWS Cost Explorer에서 2026.03 ~ 2026.05 비용이 높게 나온 사실을 확인했고, 전후 비교를 위해 더 과거 기간까지 포함해서 DynamoDB 비용 항목 추세를 함께 봤다.

여기서 ReadCapacityUnit-Hrs 항목이 2026.02에 비해 2026.03이 약 400달러 이상 오른 것을 확인할 수 있었다.

그리고 Billing에서도 같은 기간의 DynamoDB 항목을 비교해 보니, Provisioned Read Units covered with DBSP 항목도 함께 약 2배 이상 올라 있었다.

이 두 가지 지표를 통해 아래와 같은 판단을 내렸다.

이 판단을 바탕으로 수십 개의 테이블 전체가 아니라, Provisioned 모드 테이블만 먼저 확인했다.

우리 환경에서 Provisioned 모드 테이블은 10개가 되지 않았기 때문에, 여기까지 범위를 줄인 뒤에는 원인 테이블을 찾는 속도가 훨씬 빨라졌다.

그 다음에는 CloudWatch 메트릭에서 ProvisionedReadCapacity를 기준으로 각 테이블과 GSI를 확인했고, 실제로 어느 테이블에서 변화가 있었는지 금방 특정할 수 있었다.

정리하면 이번에 효과적이었던 흐름은 아래였다.

최근 3개월(2026.03 ~ 2026.05) 동안 RCU 비용이 높게 나온 사실을 확인한다.
ReadCapacityUnit-Hrs, Provisioned Read Units covered with DBSP 같은 비용 항목을 보고 Provisioned 모드부터 먼저 의심한다.
전체 DynamoDB 테이블이 아니라 Provisioned 테이블 집합으로 범위를 줄인다.
마지막으로 CloudWatch ProvisionedReadCapacity에서 실제 원인 테이블과 GSI를 찾는다.

이번 작업의 핵심은 비용 항목만으로 Provisioned 테이블 범위를 먼저 좁히는 데 활용했다는 점이다.
DynamoDB 테이블 수가 많을 때는 처음부터 모든 테이블을 보지 말고, 요금 항목으로 테이블 집합을 먼저 줄인 뒤 CloudWatch에서 확인하는 편이 원인 테이블을 특정하기 쉬웠다.