When several customers share a DynamoDB table, recovering one tenant raises a practical question: how do you retrieve its data from before an incident without restoring everyone else? Reading the current items cannot answer that question, while restoring unrelated tenants expands the work.

Filtered export to S3, announced on October 1, 2026, changes how that data can be retrieved. It lets you select historical items and attributes, but deciding which exported data should go back into production remains a separate task.

Separating the read scope, the historical state, and the write-back scope makes the feature easier to reason about. Tenant recovery also reveals which parts carry over to sharing and relocation—and which responsibilities stay with the application.

PITR backups make historical tenant exports possible

DynamoDB export to S3 arrived in 2020, followed by incremental export in 2023. The new addition is FilterSpecification on the existing ExportTableToPointInTime request. It selects items and attributes for both full and incremental exports and is available in all commercial Regions at launch.

Exports read PITR backups rather than the live table, so they consume no table read capacity. Whereas Query retrieves current items, a full export retrieves their state at a chosen point within the PITR window.

“Full” now makes sense as a snapshot of the selected scope. With filtering, that scope can be all items belonging to one tenant.

PITR must be enabled. Export is also asynchronous, with no SLA guaranteeing its completion time. A recovery workflow therefore should not depend on a fixed export duration. These operational properties are documented in the existing export behavior.

Key conditions reduce processing; filters and projections narrow output

The three expressions in FilterSpecification act at different stages. That distinction affects both the data produced and the cost of producing it.

If the tenant ID is the table partition key, a key condition can select one tenant. Filtering an ordinary tenant-ID attribute does not provide the same reduction in reads. The partition key condition uses equality for one value; it is not a mechanism for listing arbitrary tenants. Secondary indexes are unsupported at launch.

The following sharing example assumes TenantId is the partition key and WorkOrderId is the sort key. Names and values are illustrative, and this is only a request fragment.

{
  "FilterSpecification": {
    "KeyConditionExpression": "#tenant = :tenant",
    "ProjectionExpression": "#tenant, #order, #status",
    "ExpressionAttributeNames": {
      "#tenant": "TenantId",
      "#order": "WorkOrderId",
      "#status": "Status"
    },
    "ExpressionAttributeValues": {
      ":tenant": { "S": "tenant-example" }
    }
  }
}

The key condition selects the tenant, while projection limits output to three attributes. ExpressionAttributeNames supplies aliases and ExpressionAttributeValues supplies value placeholders. Aliases also handle reserved words such as Status.

Filtering has no additional premium: existing per-GB rates for full and incremental exports apply. However, a proportional reduction in output size does not necessarily mean the same reduction in export charges. Distinguish key conditions that reduce reads from filters applied afterward, and include PITR and S3 storage and request charges in the estimate.

An incremental old image is not a record of every update before an incident

A full export suits recovery of a tenant snapshot. An incremental export suits examining items changed during an incident window. Incremental windows range from 15 minutes to 24 hours; NEW_AND_OLD_IMAGES includes the state before the window and the state at its end for changed items.

Consider an item that starts in a valid state, receives a legitimate update, and then receives a corrupt update within the same window. Its old image represents the state before the window, not necessarily the valid state immediately before corruption.

That difference determines what a rollback would preserve.

The incremental output specification describes inserts with a new image and deletions with an old image. An item inserted and deleted within the window produces no output. This data compares states across a window; it is not an audit log for replaying every intermediate write.

For recovery, retain complete items and identify the corruption pattern before selecting records to restore. Writing an old image with PutItem replaces the entire item, so conditional writes must protect legitimate changes made after the incident. If timestamps or version attributes drive those conditions, every write path must maintain them.

Export avoids table reads, but writing recovered items back uses ordinary writes. Recovery load and concurrent updates need their own design. Export is also not transaction-aware, so exported data alone should not be treated as a guarantee of business consistency across multiple items.

Use different attribute selections for sharing and recovery

Recovery needs complete items, while sharing often calls for fewer attributes. ProjectionExpression lists attributes to include, allowing customer email addresses and phone numbers to stay out of the export. The earlier JSON fragment follows this sharing pattern.

Projection does not inspect values. If a selected free-text field contains personal information, that information is exported too. The service does not decide whether the contents of an attribute are appropriate to share.

A practical approach is to define the attributes the recipient needs and maintain that list as the projection. Even for the same tenant, a projected sharing export and a complete recovery export serve different purposes. Their S3 destinations should make that distinction clear.

Region relocation still needs a plan for writes after the snapshot

The same selection mechanism can help move one tenant to another Region. Export a full snapshot to the destination S3 bucket, then import it into DynamoDB. Cross-account and cross-Region export destinations are supported.

However, import from S3 creates a new table. It does not append data to an existing shared table. An existing destination table requires a separate write path.

The application must also account for changes between the snapshot time and traffic cutover. Decide whether to pause writes or capture and apply subsequent changes; producing the export alone does not complete the move. Items in the source table are not automatically deleted.

Filtered export reduces the work of retrieving data for tenant recovery or relocation. Correct restoration and cutover still require protecting changes that happen afterward. Start by checking whether your table can identify a tenant through a key condition: that reveals where this feature can fit into your workflow.

Source

• Title: Introducing filtered export from Amazon DynamoDB to Amazon S3
• URL: https://aws.amazon.com/blogs/database/introducing-filtered-export-from-amazon-dynamodb-to-amazon-s3/