DynamoDB filtered export: What the New S3 Feature Changes

DynamoDB filtered export arrived on October 1, giving developers a way to send only selected items and attributes from a table to Amazon S3 instead of exporting the entire dataset. The change matters most for multi-tenant applications, incident recovery, data sharing, and analytics, where the useful dataset can be a tiny fraction of a much larger table. AWS says the feature works with both full and incremental exports and reads from point-in-time recovery data rather than consuming the production table's read capacity.

DynamoDB filtered export moves selection into the export itself

Before this feature, Amazon DynamoDB's export model treated the table as the unit of export, leaving applications to separate the required records afterward. A developer recovering one customer from a shared table could either query the customer's current records or export a much larger dataset and filter it elsewhere. Filtered export adds a FilterSpecification to the existing export request, allowing the selection to happen as part of the export operation. That means the S3 output can contain only the records and attributes the receiving workflow actually needs.

The distinction is especially useful for applications that store many customers in the same DynamoDB table. A tenant is a customer or organizational boundary within a shared application, so recovering one tenant does not normally require recovering every other tenant's data. AWS's own example uses a 4 TB table where roughly 2 GB belongs to the tenant being relocated, illustrating why exporting the whole table can create unnecessary storage, processing, and operational work. The new feature lets the export target that smaller slice directly rather than making the application extract it after a full export.

Three expressions control what reaches Amazon S3

The new export specification uses three important expression types. A key condition expression selects a partition key and can optionally constrain the sort key, a filter expression applies conditions to individual items, and a projection expression determines which attributes are written to the exported dataset. These are familiar concepts to DynamoDB developers because they use expression syntax already associated with database queries and scans. The practical result is that developers can control both which items are exported and which fields those items contain.

There is an important limitation hidden inside that flexibility: a filter expression does not necessarily reduce the amount of data DynamoDB processes. AWS explains that a key condition can restrict the partitions read, while a filter is applied to items after the read. Projection controls what gets written, so it can keep unwanted attributes out of the S3 output, but it should not be confused with a mechanism that automatically reduces all underlying processing. That distinction matters when developers estimate both performance and export cost.

The biggest practical change is tenant recovery

Disaster recovery is where the feature becomes more than a convenience. Imagine a shared DynamoDB table where a deployment accidentally changes records for one customer, while the rest of the table remains healthy. A traditional point-in-time restore can produce a complete historical copy that then has to be searched for the affected tenant, whereas an incremental filtered export can target the tenant and the period in which the bad writes occurred. AWS demonstrates this pattern with a 45-minute recovery window and a 4 TB source table, showing how the export can preserve the affected tenant's changed records without producing another copy of the entire table.

Incremental export is different from simply asking DynamoDB for the current contents of a partition. It represents changes during a specified time window and can include both the previous and newer state of an item. AWS says incremental exports support windows from 15 minutes to 24 hours, while full exports can select a point in time within the point-in-time recovery window, which extends to 35 days. That gives recovery tooling two useful dimensions: which data to select and when that data should represent.

Projection filtering also changes how teams share customer data

Data sharing creates a different problem from recovery because the goal is often to provide useful records without exposing fields that the recipient does not need. With projection expressions, an export can include selected attributes rather than copying every field in each DynamoDB item. AWS demonstrates this with a tenant-history sharing scenario where contact attributes can be excluded from the exported records. The feature therefore provides a technical boundary for the exported dataset, although developers still have to decide which attributes are safe and appropriate to share.

That last point deserves attention because projection is not a privacy scanner. It does not inspect free-text values and determine whether they contain personal or confidential information; it simply follows the attributes specified by the export request. A field left in the projection can therefore carry sensitive information even if its name looks harmless. Teams using filtered export for external sharing should treat the projection as an explicit allow-list and review the schema before creating a reusable export workflow.

Filtered export does not consume production table capacity

One of the more consequential implementation details is where DynamoDB obtains the data. AWS says the export reads from point-in-time recovery data rather than issuing ordinary reads against the production table, so the export does not consume the table's read capacity or compete with normal application traffic for throughput. That makes the feature particularly suitable for large exports from busy applications where running an equivalent read-and-upload process could interfere with production workloads. It also means developers do not have to build their own pagination and upload loop merely to move a selected historical dataset into S3.

This does not make exports free or eliminate the need for planning. Point-in-time recovery must be enabled, and the exported objects still incur Amazon S3 storage and request charges. AWS also says filtered export uses the same export pricing model as full and incremental export, with no separate premium for filtering, while a key condition can reduce the amount of data processed by limiting the partitions involved. A non-key filter can narrow the output without necessarily reducing the underlying data read for the export, so the expression chosen has a direct effect on how efficiently the operation works.

The feature works for relocation as well as recovery

Filtered export also gives multi-region applications a simpler way to move a subset of a shared table. AWS demonstrates a scenario where one tenant needs to move from one Region to another, while the other tenants remain in the original location. A point-in-time filtered export can write only that tenant's records to an S3 bucket in the destination Region, after which DynamoDB's import process can create a table from the exported data. The important part is that the export separates the tenant before the data leaves the source workflow, rather than requiring the application to copy the entire shared table and remove unrelated records later.

There is still application work around the move. Exporting a tenant does not automatically switch that tenant's live traffic to the new table, and writes that arrive between the export point and the final cutover have to be handled by the application's migration process. AWS's example explicitly leaves replaying or draining those writes to the application. That makes filtered export a useful data-movement primitive, not a complete tenant-migration system.

There are limits developers should check before relying on it

The first limitation is that filtered export depends on point-in-time recovery, so tables without that capability cannot use the feature as described. AWS also says filtered export does not support secondary indexes at launch, and the key-condition rules follow DynamoDB Query semantics rather than providing arbitrary conditions on partition keys. Those details can affect how an existing table design maps onto an export strategy. Developers should therefore test their actual key schema rather than assuming every query they use in application code can be transferred directly into an export condition.

Consistency is another consideration for recovery workflows. AWS notes that the export has the same consistency model as a full export and is not transaction-aware across partitions. In other words, filtered export can select a historical dataset, but it should not be treated as a transactional snapshot of a multi-item application operation. For ordinary analytics, sharing, or tenant-level recovery this may be acceptable, but systems that require strict transactional reconstruction still need application-level safeguards around the exported data.

What developers should change in existing export workflows

The most useful place to evaluate filtered export is in code that currently performs a full DynamoDB export and then filters the result in another system. Look for jobs that copy an entire table into S3 only to select one customer, one partition, a limited time window, or a small set of attributes afterward. Those workflows are the clearest candidates because the selection logic can now move into the export request itself, while the output remains available in S3 for analytics, recovery, sharing, or another downstream process.

A sensible migration starts with one non-critical export and compares its output with the existing pipeline. Verify the item count, projected attributes, historical timestamp, and treatment of updated and deleted records before replacing the old process. Pay particular attention to filter expressions that look like they reduce work but actually only reduce what gets written, because the key condition is the part that can restrict which partitions are processed. Once those checks match the application's requirements, filtered export can turn a large table-level data operation into a much more targeted software workflow.