DynamoDB backup limits expose the need for granular recovery

At a glance

What this is: This is an analysis of why DynamoDB’s native backup and restore model struggles with real-world recovery needs, especially for partition-level corruption.

Why it matters: It matters because recovery scope, blast radius, and operational complexity all affect how security and platform teams govern data protection, resilience, and access to production recovery paths.

By the numbers:

• One prominent customer in the online learning space slashed DynamoDB backup spending by over 70% by switching to Clumio, while also improving its security posture.
• The process begins by restoring the entire table to a new, temporary one, which means provisioning and paying for another 100 TB of storage and waiting hours or even days for the data to be copied.

👉 Read Commvault's analysis of DynamoDB backup limits and partition recovery

Context

DynamoDB is often treated as a simple durability problem, but the real issue is recovery scope. Native options can protect a table and still leave teams with a brittle restore process when only a few partitions are corrupted, deleted, or overwritten.

For IAM and cloud security teams, the important question is not whether backups exist. It is whether recovery can be executed with the right granularity, under the right account boundaries, and without turning a routine incident into a multi-day operational event.

Key questions

Q: How should security teams govern DynamoDB recovery for multi-tenant workloads?

A: Security teams should align recovery design to the actual tenancy model of the application, not the database table alone. If one table carries many tenants, restore controls need partition-level precision, reviewable privilege boundaries, and a clear rule for who can recover which data without exposing the full table to unnecessary handling.

Q: Why do table-level backups fail to solve real recovery problems in DynamoDB?

A: Table-level backups can preserve data and still fail operationally because they treat the whole table as the recovery unit. When only a few partitions are affected, teams must restore more data than necessary, increase cost, and introduce manual steps that create room for mistakes and slower incident recovery.

Q: What do teams get wrong about backup separation in cloud data protection?

A: Teams often assume that a logically separate backup is enough, even when it remains inside the same cloud security sphere as production. True resilience depends on whether the backup can survive account compromise, destructive deletion, and the same administrative failure domain as the source system.

Q: Who should be allowed to perform production restores from backup copies?

A: Only tightly controlled operators should be able to trigger production restores, because the restore process itself is a privileged action with real blast radius. Teams should require approval, logging, and cleanup ownership for any workflow that copies recovery data back into live systems.

Technical breakdown

Why DynamoDB point-in-time recovery becomes brittle at scale

Point-in-Time Recovery gives AWS customers a way to restore a table to an earlier state, but the restore object remains coupled to the source table. That coupling matters because the backup lifecycle is not independent of the original data plane. If the table is deleted or the account is compromised, the restore path is constrained. In large, shared tables, the architectural unit of recovery is also too coarse when only a narrow subset of data is affected. The result is a protection control that looks complete on paper but fails under partition-level corruption or destructive actions.

Practical implication: treat table-level recovery as insufficient when application tenancy or blast radius is smaller than the whole table.

Why full-table restore creates hidden operational risk

AWS Backup solves some separation issues by keeping copies logically distinct, but repeated full backups and restore workflows still introduce cost and toil. When a single restore requires rebuilding a massive temporary table, teams inherit storage overhead, slow recovery time, and error-prone manual extraction. That operational model is especially risky when engineers must write scripts to pull only the affected records and then clean up temporary resources correctly. In identity terms, this is not just a backup problem. It is a recovery access problem, because the privilege to restore production data needs strict process control.

Practical implication: constrain who can trigger large restores and require reviewed procedures for extracting production data from recovery copies.

What surgical, in-place recovery changes about resilience

Granular recovery changes the recovery object from the whole table to the affected partition keys and the exact point in time. In-place recovery removes the need for a temporary table and manual data transfer, which reduces both exposure and engineering error. That matters because the recovery workflow itself becomes part of the control surface. The more steps needed to repair data, the more chance there is for over-restoration, stale data reinsertion, or accidental cost blowouts. Surgical recovery is therefore a resilience design choice, not just a storage feature.

Practical implication: design recovery workflows so the smallest recoverable unit matches the smallest realistic failure domain.

NHI Mgmt Group analysis

Recovery granularity is now a governance requirement, not a convenience feature. DynamoDB protection breaks down when the recovery unit is the entire table but the incident affects only a few partitions. That mismatch creates a governance gap between durability and operability, because the control can exist while the practical restore path still fails the business. The implication is that recovery design must be judged by failure domain, not by backup presence alone.

Air-gapped backup storage changes the failure model for cloud data protection. When backups remain tied to the same enterprise security sphere as primary data, a wider cloud incident can still put restoration assets at risk. A logically or physically separate backup plane reduces that shared fate problem and narrows the blast radius of account compromise, deletion, or destructive misuse. Practitioners should evaluate whether their recovery copies are truly independent or only separately labelled.

Partition-level restore exposes the hidden cost of table-centric thinking. Modern SaaS applications often distribute many tenants across a single table, which means the recovery problem is rarely aligned to the storage object. Table-centric restore processes force teams into expensive over-recovery, manual filtering, and high-risk cleanup. The result is a resilience model that optimises for backup completeness while ignoring operational precision. Practitioners need recovery methods that match the tenancy model of the application.

In-place recovery is a control over operational error, not just a speed improvement. The removal of temporary tables and custom ETL scripts eliminates several failure points where data can be miscopied, overlaid, or left behind. That matters because restoration workflows themselves can create secondary incidents if they rely on brittle human execution. The broader lesson is that recovery controls should reduce not only downtime, but also the number of privileged steps needed to complete recovery.

Identity blast radius: Recovery operations become a privileged workflow with its own blast radius when production data must be copied, filtered, and cleaned manually. That blast radius is often invisible until an incident forces engineers to act under pressure. The practitioner takeaway is to treat restore privileges, recovery copy handling, and cleanup authority as governed identity events, not just storage administration.

From our research:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to The 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
• For a broader view of how recovery and privilege design intersect, see Guide to the Secret Sprawl Challenge for the control failures created by exposed credentials and operational sprawl.

What this signals

Recovery precision is becoming part of identity governance because restore rights are privileged actions with production impact. As more platform operations are automated, the boundary between backup administration and access governance narrows. Organisations that cannot distinguish routine restore access from high-risk production write authority will keep treating recovery as a storage issue when it is really a privilege-control problem.

With 53% of security leaders expecting AI to run major portions of infrastructure autonomously within three years, the wider lesson is that operational recovery will increasingly be executed by systems that need scoped authority and clear guardrails, not just by humans following runbooks. That makes restoration workflows a test of whether governance can keep pace with machine-timed action.

Identity blast radius: the next maturity step is not merely keeping backups offline, but limiting how far any restore process can move data, privileges, and mistakes. Teams should review restoration paths alongside privileged access reviews and treat recovery tooling as part of the control plane, not a sidecar capability.

For practitioners

• Map recovery granularity to application tenancy Identify where a single DynamoDB table contains multiple tenants or domains, then document the smallest realistic recovery unit for each workload. Use that mapping to decide where table-level restore is too coarse and where partition-key recovery is required.
• Separate backup assets from primary cloud failure domains Verify whether recovery copies are isolated from the source AWS environment and from the same administrative boundary. If backups can be lost with the table or account, the recovery design is still exposed to the same compromise path.
• Restrict and review restore privileges Treat production restore permissions as privileged access, not routine storage administration. Require explicit approval paths for large restores, recovery copy access, and manual data handling so engineers cannot improvise under incident pressure.
• Eliminate manual extraction from recovery workflows Replace scripts that sift through temporary tables with recovery processes that restore the affected data directly into the target environment. The goal is to remove error-prone steps that increase the chance of data loss or cost overrun.

Key takeaways

• DynamoDB backup strategy fails when recovery is measured by table availability instead of application failure domains.
• The operational evidence points to costly over-restoration, manual extraction, and avoidable privileged handling during incident recovery.
• Granular, in-place recovery changes resilience from a storage problem into a governed access and blast-radius problem.

Key terms

• Partition-level recovery: Partition-level recovery restores only the affected subset of data within a larger table or dataset. In DynamoDB, this matters when one tenant or key range is corrupted while the rest of the table remains valid, because full-table restore wastes time, money, and operational control.
• Recovery blast radius: Recovery blast radius is the amount of data, privilege, and operational risk exposed when a restore must be executed. The larger the restore unit, the more likely teams will over-copy data, touch unaffected records, or create secondary incidents during remediation.
• Air-gapped backup protection: Air-gapped backup protection keeps recovery copies isolated from the primary production environment so a compromise in one plane does not automatically endanger the other. In cloud settings, the key question is whether that separation is truly independent or only organisationally distinct.
• In-place recovery: In-place recovery writes corrected data back into the live production system without forcing teams to rebuild temporary copies first. It reduces manual handling, shortens restore time, and lowers the risk of copy errors, stale data reinsertion, and cleanup mistakes.

What's in the full article

Commvault's full article covers the operational detail this post intentionally leaves for the source:

• The full restore workflow comparison between DynamoDB PITR, AWS Backup, SecureVault, and Backtrack for different failure scenarios.
• The step-by-step partition recovery process for targeted restore operations and in-place data replacement.
• The storage and cost model behind incremental backups versus repeated full backups in DynamoDB environments.
• The product-level explanation of how recovery precision maps to operational simplicity in large SaaS tables.

👉 Commvault's full article covers the restore workflow, recovery granularity, and cost model in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.