Cloud Databases — Troubleshooting
DynamoDB throttling despite sufficient provisioned/on-demand capacity
If requests are being throttled even though total table-level capacity looks sufficient, the near-certain cause is a hot partition (covered on the Intermediate tab) — DynamoDB's capacity is distributed across partitions internally, and a partition key with low cardinality or an uneven access pattern concentrates traffic onto one partition regardless of the table's aggregate provisioned capacity. Check CloudWatch's per-partition metrics (not just table-level aggregates) to confirm this — if one partition shows a disproportionate share of ConsumedReadCapacityUnits/ConsumedWriteCapacityUnits, the fix is redesigning the partition key for better distribution (adding a randomized or time-bucketed suffix, as covered on Intermediate), not simply raising overall provisioned capacity, which doesn't address an uneven distribution problem.
Multi-AZ failover took much longer than expected
A Multi-AZ failover is typically under a minute, but a longer failover often traces to one of a few specific causes: a large number of open connections or in-flight transactions that need to be cleanly terminated before the standby can fully take over; DNS TTL/caching on the application side holding onto the old primary's endpoint longer than the actual failover took (the database failed over correctly, but the application's connection pool or DNS cache didn't pick up the change promptly); or, less commonly, a genuinely large amount of unreplicated write-ahead log that needed to be applied to the standby before it could safely become primary. Confirming which of these applies means checking the database's own failover event log/timeline against the application's actual reconnection timing — these are often two different durations that get conflated into one "failover was slow" observation.
Migrated data doesn't match between source and target
A row-count or checksum mismatch after a migration almost always traces to one of: ongoing writes to the source database during migration that weren't captured by the final sync (a common gap in a big-bang cutover where the "final sync" window was shorter than the actual write activity during it); a schema conversion that silently changed data (a type conversion that truncated precision, a character encoding mismatch); or a migration tool's own known limitation with a specific data type or feature not fully supported for automatic conversion. AWS DMS and similar tools provide built-in validation/comparison reports — running that validation as a required step before cutover, not just trusting the migration completed successfully because it reported no errors, is what catches this class of problem before it becomes a production data-integrity issue discovered after the old database has already been decommissioned.
Cost spiked unexpectedly after switching to on-demand DynamoDB pricing
On-demand pricing removes the capacity-planning burden but also removes the natural cost ceiling that provisioned capacity provides — a traffic spike (legitimate or from a bug causing excessive requests, like an accidental retry loop or a missing pagination limit) directly and immediately increases cost under on-demand, where the same spike under provisioned capacity would have simply caused throttling instead (a functional problem, but not a runaway cost one). Before assuming on-demand pricing itself was the wrong choice, check for a request-volume anomaly first (CloudWatch request metrics against the timeline of the cost spike) — a genuine application bug causing excessive requests is a more common actual cause of an unexpected on-demand cost spike than the pricing model itself being unsuitable for the workload.
A cross-region read replica shows significant, growing replication lag
Growing replication lag to a cross-region replica (versus a stable, small lag) points to the replica's apply rate falling behind the primary's write rate over time — common causes: the replica instance is under-sized relative to the primary (same compute class isn't automatically sufficient if the replica is also serving read query load competing with replication apply work), or cross-region network latency/bandwidth is a genuine bottleneck for the actual write volume being replicated. If this replica is intended as a DR target with a specific RPO commitment (covered on the Advanced tab), growing lag is a direct, active threat to that RPO and needs addressing before it's needed in an actual failover — checking replica lag is a metric worth actively monitoring and alerting on continuously, not something to discover only during an actual disaster recovery event when it's too late to fix.