Amazon DynamoDB insights

High traffic concentration on a small set of partition keys causes throttling even when overall table capacity appears sufficient. This manifests as KeyRangeThroughputExceeded errors indicating per-partition throughput limits are exceeded.

Insufficient write capacity or low-cardinality partition keys on a Global Secondary Index causes asynchronous index updates to lag, triggering throttling on base table writes even when the table itself has adequate capacity.

Unpredictable or bursty workloads on on-demand capacity mode result in significantly higher costs and inconsistent latency compared to provisioned mode with auto-scaling for predictable high-volume workloads.

Provisioned capacity auto-scaling responds too slowly to sudden traffic bursts, causing temporary throttling during the scaling period before capacity adjustments take effect.

DynamoDB throttles requests when a single partition exceeds 3,000 RCU/s or 1,000 WCU/s, even when table-level capacity is sufficient. This indicates access pattern skew requiring key distribution redesign.

Insufficient write capacity on a Global Secondary Index causes all writes to the base table to throttle, even when the table itself has adequate capacity. This cross-resource dependency often goes undiagnosed.

On-demand tables hit soft limits of 40,000 RCU/s and 40,000 WCU/s per resource, causing RequestLimitExceeded or AccountLimitExceeded exceptions even during normal scaling operations.

Hidden Throttling from Insufficient CloudWatch Visibility

Throttled requests may occur without obvious logging, especially when layers of abstraction hide SDK-level exceptions. Operators lack visibility into why requests fail despite adequate provisioned capacity.

Applications performing Scan operations instead of Query with key conditions consume excessive capacity and exhibit 50-1000x higher latency compared to targeted queries, causing throttling and slow response times.

Lambda Stream Processing Lag from DynamoDB Streams

DynamoDB Streams event source mapping to Lambda experiences high IteratorAge or failed invocations, causing delayed event processing and potential data inconsistency in downstream systems.

High rates of conditional write failures in write-heavy or transactional workloads indicate optimistic locking contention, leading to application retry storms and increased latency.

Global Secondary Indexes use eventually consistent reads by default, causing applications to receive stale data during high write throughput periods when GSI updates lag behind base table writes.

Items approaching the 400KB size limit consume multiple capacity units per operation and significantly increase read/write latency compared to smaller items, especially noticeable when p50 latency is elevated.

Inefficient Scan operations consume up to 1,000x more capacity than Query operations. Combined with over-provisioned capacity or lack of auto-scaling, this causes unexpectedly high costs.

Vague IAM permission errors cause data access failures without clear indication of which specific permission is missing, delaying diagnosis and creating false alerts for application-level issues.

When SystemErrors metric exceeds 1% of total requests over 15 minutes, it indicates underlying infrastructure issues requiring AWS Support escalation rather than application-level tuning.