DynamoDB Contributor Insights 요금: 실제로 내는 비용은?

출처: Dev.to

$0.50 / 규칙 / 월. $0.03 / 백만 이벤트. 단일 DynamoDB 테이블에 Contributor Insights를 활성화하면 자동으로 네 개의 규칙이 생성되므로, 이벤트가 하나도 기록되지 않아도 최소 $2.00 / 월이 청구됩니다.
500 백만 이벤트 / 월이면 $17.00 / 월, 5 억 이벤트 / 월이면 $152.00 / 월이 됩니다.
이 비용이 정당한지는 트래픽 양, 핫키 패턴 존재 여부, 그리고 이미 발생하고 있는 프로비저닝된 처리량 낭비에 따른 스로틀링 비용에 따라 달라집니다.

Contributor Insights for DynamoDB는 CloudWatch 모니터링 기능으로, 코드 수준의 계측이나 사용자 정의 로깅 없이도 테이블에서 읽기·쓰기 트래픽을 유발하는 상위 파티션 키를 식별합니다.
실시간에 가까운 수준으로 요청 트래픽을 분석하고 결과를 CloudWatch 그래프로 제공합니다. 파티션 키가 편중된 테이블에 대해, FinOps 엔지니어가 궁금해 하는 “어떤 파티션 키가 스로틀링을 일으키고 있나요?” 라는 질문에 답을 줍니다.

두 가지 요금 구성 요소

Contributor Insights 청구서에는 정확히 두 개의 항목이 있습니다.

• 규칙 요금: $0.50 / 규칙 / 월 (트래픽과 무관하게 고정)
• 이벤트 요금: $0.03 / 백만 DynamoDB 읽기/쓰기 이벤트 (규칙에 매치된 경우)

한 테이블이 생성하는 규칙 수

단일 테이블에 활성화하면 자동으로 네 개의 규칙이 생성됩니다.

1. 기본 테이블에서 가장 많이 접근된 파티션 키
2. 기본 테이블에서 오류를 일으키는 가장 많이 접근된 파티션 키
3. 각 GSI에서 가장 많이 접근된 파티션 키
4. 각 GSI에서 오류를 일으키는 가장 많이 접근된 파티션 키

규칙 수 공식: 2 + (2 × GSI 수)

• GSI가 없는 테이블 → 규칙 요금 $2.00 / 월
• GSI가 3개인 테이블 → 규칙 요금 $4.00 / 월 (이벤트 요금은 별도)

“이벤트”란 무엇인가?

모든 읽기·쓰기 작업이 이벤트에 포함됩니다.

• GetItem, PutItem, UpdateItem, DeleteItem
• BatchGetItem, BatchWriteItem (각 아이템 별)
• Query, Scan (반환·검사된 각 아이템)
• 트랜잭션 읽기·쓰기
• GSI 작업은 해당 규칙이 활성화된 경우 별도로 카운트됩니다.

요금 예시

대부분 워크로드에서 변동 비용은 이벤트 요금이며, 규칙 요금은 고정된 오버헤드입니다.

2025년 8월부터 AWS는 스루틀 전용 모드를 추가했습니다. 이 모드에서는 규칙이 프로비저닝된 용량이나 온디맨드 버스트 한도를 초과한 스로틀링 요청에 대해서만 활성화됩니다.

규칙 요금($0.50/규칙/월)은 그대로 부과하지만, 이벤트 요금은 크게 감소합니다. 예를 들어, 월 20 억 이벤트를 처리하는 잘 프로비저닝된 테이블에서 스로틀링 비율이 0.1%라면 약 2 백만 건의 스로틀링 이벤트만 매치되어 $0.06/월 정도가 됩니다(전체 $60.00 대비).

스루틀 전용 모드 사용 시점

• 스로틀링을 일으키는 키만 파악하고 싶고, 가장 인기 있는 키는 필요 없을 때
• 현재 테이블이 정상이며, 거의 비용이 들지 않는 수동 모니터링을 원할 때
• 월 10 억 건 이상의 고볼륨 테이블에서 전체 모드 사용 시 $30 이상이 청구될 경우

전체 모드 사용 시점

• 핫키 패턴을 적극적으로 조사하고 싶을 때
• 트래픽 분포를 지속적으로 가시화하고 싶을 때
• 파티션 키 스키마 재구성을 검토 중일 때

Reserved Capacity와의 연계

1년·3년 약정 선택 전 Reserved Capacity를 도입하려는 경우, 상세 비교는 여기서 확인하세요: [How to Choose Between 1-Year and 3-Year AWS Commitments]

Contributor Insights 비용은 $2 ~ $62/월이며, 이를 사용하지 않을 경우 발생하는 비용은 매달 프로비저닝된 용량 청구서에 반영됩니다.

DynamoDB 프로비저닝 용량은 파티션별로 분배됩니다. 예를 들어, 테이블이 초당 10,000 RCU로 설정돼 있고 전체 읽기의 90%가 세 개의 파티션 키에 집중된다면, 나머지 파티션은 유휴 상태가 되면서 해당 세 키가 스로틀링됩니다.

흔히 발생하는 패턴

• 낮은 카디널리티 파티션 키 (예: user_type, region, status)
• 동시에 만료되는 캐시 아이템이 몰려 특정 키에 읽기 급증 발생
• “오늘” 혹은 “현재”와 같이 시간 기반 쿼리가 트래픽을 한 시점에 집중

구체적인 시나리오

초당 5,000 WCU로 프로비저닝된 테이블은 월 약 $2,847(aws.amazon.com/dynamodb/pricing 기준) 의 쓰기 용량 비용이 듭니다. 핫키 스로틀링으로 인해 30% 용량이 활용되지 못한다면, $854/월 정도를 쓸모없는 처리량에 지불하게 됩니다.

Contributor Insights에 $17/월을 투자해 재설계 대상 키를 찾아낸다면, 해당 월에 50:1의 ROI를 기대할 수 있습니다.

핫키와 Reserved Capacity 약정

핫키 탐지는 비용 최적화 전략과 직접 연결됩니다. DynamoDB Reserved Capacity는 프로비저닝된 처리량 대비 30–40% 절감 효과를 제공하지만, 이는 용량이 실제로 효율적으로 사용될 때만 적용됩니다.

핫키 패턴을 감지하지 못한 테이블은 두 가지 복합 문제를 야기합니다.

1. 팀이 스로틀링을 해소하기 위해 용량을 추가하면서 과다 프로비저닝이 발생
2. 과다 프로비저닝된 상태에서 Reserved Capacity를 약정하면 낭비된 용량이 고정됩니다

올바른 순서는 다음과 같습니다.

1. Contributor Insights로 핫키 식별 →
2. 파티션 키 스키마 수정 →
3. 적정 프로비저닝 용량으로 조정 →
4. 조정된 용량에 Reserved Capacity 적용

이렇게 하면 작은 약정에 높은 활용도를 달성하고, 기준선 대비 30–40% 절감 효과를 얻을 수 있습니다.

CloudWatch는 기본적으로 DynamoDB 메트릭을 무료로 제공하지만, 차이는 구체성에 있습니다.

• 일반 CloudWatch 메트릭: “이번 시간에 스로틀링 요청이 50,000건 발생했습니다.”
• Contributor Insights: “파티션 키 user#12345가 그 중 48,000건을 차지했습니다.”

활동적인 문제 해결이나 용량 계획에서는 이 차이가 추측과 실행을 가르는 결정적인 요소가 됩니다.

Contributor Insights 활성화 시점

• 표준 메트릭으로는 설명되지 않는 반복적인 스로틀링이 발생할 때
• 테이블 마이그레이션 혹은 파티션 키 스키마 재설계를 계획 중일 때
• 월 100 M+ 이벤트를 처리하지만 트래픽 분포를 파악하지 못하고 있을 때
• Reserved Capacity 약정을 고려 중이며 먼저 활용도를 검증하고 싶을 때

스루틀 전용 모드 사용 시점

• 거의 비용이 들지 않는 수동 모니터링을 원할 때
• 현재 테이블은 정상하지만 핫키가 발생할 경우를 대비해 조기 경고를 받고 싶을 때

완전 비활성화 시점

• 매우 높은 카디널리티 파티션 키(예: UUID 기반)이며 편중 현상이 없을 때
• 온디맨드 용량 모드에서 트래픽이 고르게 분포된 것이 확인된 경우
• 비프로덕션 테이블이며 Reserved Capacity 약정이 없을 때

사전 요구 사항

• cloudwatch:EnableInsightRules 및 dynamodb:DescribeTable 권한
• 전체