DynamoDB LimitExceededException

TL;DR — You issued too many control-plane operations at once (or hit a table/account limit). Up to 500 tables and indexes may be in CREATING/UPDATING/DELETING state across your account at a time, and mutable control-plane calls are rate-limited. Serialize your table operations, wait for ACTIVE, and retry with backoff.

What it means

LimitExceededException: Subscriber limit exceeded: There are too many concurrent control plane operations.
LimitExceededException: Too many operations for a given tableName.

This is a control-plane error — it comes from CreateTable, UpdateTable, DeleteTable, index creation, or resource-policy calls, not from GetItem/PutItem/Query. DynamoDB is telling you you've exceeded a concurrency or account limit. It's an HTTP 400 but is effectively retryable after a wait — the condition clears as in-flight operations finish.

Why it happens

• Too many concurrent table/index operations — the cumulative number of tables and indexes in CREATING, UPDATING, or DELETING state cannot exceed 500 per account/region.
• Too many operations on one table — you tried to run several UpdateTable/index changes on the same table before the previous one reached ACTIVE. A table allows only one such operation in flight.
• Bulk stack deploys — CloudFormation/CDK/Terraform creating or tearing down many tables (or many GSIs) simultaneously overruns the concurrency budget.
• Rapid mutable control-plane calls — creating/deleting tables in a tight loop exceeds the mutable control-plane request-rate limit.
• Account resource quotas — hitting the tables-per-account (or import-jobs) service quota.

How to fix it

1. Serialize control-plane operations — wait for a table (and each GSI) to become ACTIVE before issuing the next change to it. Poll DescribeTable and gate on TableStatus === 'ACTIVE'.
2. Retry with exponential backoff — the limit is transient; a backed-off retry usually succeeds once in-flight operations drain.
3. Throttle bulk deploys — split a large stack so you're not creating hundreds of tables/GSIs at once, or add explicit DependsOn ordering so they don't all fire together.
4. Check your service quotas — if you're near the tables-per-account limit, request a quota increase in Service Quotas rather than retrying forever.
5. Add GSIs one at a time — creating multiple secondary indexes on one table concurrently is a common trigger.

FAQ

How do I fix LimitExceededException in DynamoDB? Stop issuing control-plane operations (CreateTable/UpdateTable/DeleteTable/index changes) in parallel. Wait for each table and index to reach ACTIVE before the next change, keep the count of tables in CREATING/UPDATING/DELETING under the account cap, and retry with exponential backoff.

Is LimitExceededException a throttling error? It's a control-plane concurrency/limit error, not data-plane throttling. Data-plane throttling surfaces as ProvisionedThroughputExceededException, ThrottlingException, or RequestLimitExceeded instead.

Related errors

• ResourceInUseException — an operation on a table that's already being modified or already exists.
• ThrottlingException — data/control-plane rate limiting.
• RequestLimitExceeded — account request-rate limit.