Provisioned throughput decreases are limited within a given day

요약 — DynamoDB는 단일 UTC 하루에 테이블(또는 GSI)의 프로비저닝된 읽기/쓰기 용량을 낮출 수 있는 횟수를 제한합니다. 허용치를 사용했으므로 UpdateTable이 거부됩니다. 시간당 리필을 기다리거나, 감소를 더 적은 큰 단계로 묶거나, 테이블을 온디맨드로 전환해 감소 관리를 완전히 중단하세요.

무엇을 의미하는가

LimitExceededException: Subscriber limit exceeded: Provisioned throughput
decreases are limited within a given UTC day

각 테이블은 UTC 하루를 작은 용량 감소 예산으로 시작합니다(증가는 계정 할당량과 DynamoDB가 너무 빠르게 램프업하지 못하게 하는 것에 따라 필요한 만큼 자주 할 수 있음). 하루를 4번의 감소가 가능한 상태로 시작하고, 매 시간마다 1번씩(언제든 최대 4번 가능) 더 얻으며 — 전체 24시간 하루에 걸쳐 최대 27번의 감소에 충분합니다. 이를 소진하면 예산이 리필될 때까지 추가 UpdateTable 감소 호출이 LimitExceededException(HTTP 400; 이 예외에 대한 개발자 가이드의 일반 메시지는 "Too many operations for a given subscriber.")으로 실패합니다. 할당량이므로 같은 창 내에서 무작정 재시도해도 도움이 되지 않습니다.

왜 발생하는가

  • 오토 스케일링 플래핑 — 스파이크가 있는 워크로드가 DynamoDB 오토 스케일링이 용량을 반복적으로 낮추게 해 감소 예산을 태웁니다.
  • 너무 자주 용량을 낮추는 스크립트 — 하나의 큰 감소 대신 많은 작은 감소.
  • 부하 테스트 중 수동 튜닝 — 트래픽이 줄어들 때 반복적으로 용량을 낮춤.
  • 인덱스별 예산 — 테이블과 GSI 감소 한도는 분리되어 있으므로 각 GSI가 자체 허용치를 가집니다. 여러 인덱스가 있는 테이블은 그중 하나에서 도달할 수 있습니다. 테이블과 GSI를 모두 감소하는 단일 UpdateTable 요청은 둘 중 하나가 현재 한도를 초과하면 전체가 거부됩니다.

어떻게 해결하는가

  1. 리필을 기다리세요. 매 시간 한 번의 감소가 가능해지고(언제든 최대 4번 가능), 새로운 4번 감소 예산이 매 UTC 하루 시작합니다.
  2. 더 적고 더 큰 감소를 하세요. 다섯 번의 160단위 단계 대신 한 단계로 1000 → 200으로 낮추세요.
  3. 오토 스케일링을 튜닝하세요 — 목표 사용률을 높이고 스케일인 쿨다운을 추가해 그렇게 공격적으로 감소하지 않도록 하세요.
  4. 워크로드가 버스트가 있거나 예측 불가능하면 온디맨드로 전환하세요:
    aws dynamodb update-table --table-name <Table> \
      --billing-mode PAY_PER_REQUEST
    온디맨드는 수동 용량 관리(와 그 감소 할당량)를 완전히 제거합니다.

관련 오류

참고 자료

공식 AWS 문서(위 링크)를 기준으로 2026-07-13에 마지막으로 검증되었습니다.

Console 없이 DynamoDB 작업하기

DynamoDB로는 실행할 수 없는 진짜 SQL(JOINs, GROUP BY, 집계)을 실행하는 빠른 DynamoDB 데스크톱 클라이언트. 시각적 편집과 여러분 자신의 Bedrock 키로 동작하는 AI 에이전트를 제공합니다.

30일 무료 체험, 신용카드 불필요 — 이후 기간 제한 없는 무료 요금제.