Your DynamoDB export cost has always been tied to the size of the whole table, even when the business question was about one customer. On October 1, 2026, AWS added filtered exports to DynamoDB, and that link finally breaks: you can now export just one tenant, one date range or one set of columns straight to S3. For SaaS companies, regulated shops and anyone with a nightly analytics dump, this is a quiet but real budget and risk change.
The old way was expensive and fragile
Before this, teams answering a “give me everything you have on customer X” request had two bad options. Option one: export the entire table to S3 and filter it afterward in Athena or Spark, paying to read, store and query data that had nothing to do with the request. Option two: write a custom Scan or Query job in Lambda or Step Functions, which consumes production read capacity, needs pagination and retry logic, and becomes someone’s on-call problem forever.
Neither option is fast, either. A full export of a large table can take hours, and the custom job tends to break the one week nobody who wrote it is around. Meanwhile the clock on a contractual or regulatory deadline keeps running.
Both options scale with table size, not request size. That is the wrong shape for a multi-tenant product where your biggest table holds thousands of customers and the request is about one.
What filtered export changes
The DynamoDB export to S3 feature already ran off point-in-time recovery data, so it never touched live read capacity. Filtered export adds a selection step on top. Engineers can tell the export which items to include and which attributes to keep, using the same expression language they already use for queries. It works for full snapshots and for incremental exports covering a time window.
The first independent hands-on test, published by Classmethod a few days after launch, confirmed the basics: a key-based filter returned exactly the items a direct query did, and column-pruned exports dropped the excluded attributes cleanly.
How the DynamoDB export cost actually works now
This is the detail that should shape every decision your team makes with the feature. Exports are billed on the amount of data DynamoDB reads, at the same rate as regular exports, with a 10 MB minimum per export. Rates vary by Region, so pull them from the DynamoDB pricing page for your own modeling.
There are two kinds of filters, and only one of them saves you export money:
- Key-based selection (for example “everything under tenant Acme”) narrows what DynamoDB reads. Smaller read, smaller bill. This is where the savings are.
- Attribute filters and column selection are applied after the data is read. They shrink what lands in S3, which lowers storage, transfer and downstream query costs, but the export charge itself does not drop.
In plain terms: if your table is designed so that a tenant or a time range is a key, filtered export is a direct cost cut. If it is not, you still save on everything downstream, but the export line item stays roughly where it was. The 10 MB minimum also means a thousand tiny per-tenant exports cost more than you would guess, so batch the small fry.
Three places it pays off immediately
Tenant offboarding and data subject requests
When a customer leaves, or an individual files a data access or portability request, you need a clean, complete copy of their records. A key-based filtered export produces exactly that, from a consistent point in time, without touching production capacity and without a custom job. That is a faster answer to legal, a cleaner audit trail (the filter used is recorded on the export), and one less script to maintain.
Compliance snapshots of the regulated subset
Many tables mix regulated and unregulated data. Snapshotting the whole thing into a long-retention archive means you are now retaining, encrypting and protecting data you never needed to keep. Exporting only the regulated slice, with only the required attributes, shrinks the blast radius of the archive and the retention bill at the same time. Less data held is less data to explain in an incident review.
Analytics feeds that stop shipping the whole table
The nightly “dump everything to the lake” job is a classic slow leak. Incremental exports already helped by shipping only what changed. Filtered incremental exports go further: ship only the changes for the entities and columns analysts actually use. Your S3, Glue and Athena spend follows.
Risks and fine print to brief your team on
- PITR is mandatory. Exports require point-in-time recovery on the table. If you disabled it to save money, re-run that math; it is also your best defense against accidental deletes.
- Incremental semantics are subtle. Filters on incremental exports are evaluated against the latest version of an item. If a record changes status mid-window and no longer matches, it drops out of that export. Filtering on stable identifiers avoids surprises.
- Not in GovCloud. Available in all commercial Regions, but GovCloud workloads stay on the old approach for now.
- Data model matters. The savings depend on keys. Tables keyed by tenant or date get the full benefit; tables designed around a single random ID mostly get downstream savings only.
What to do this quarter
Ask three questions. First, which recurring jobs export or scan entire DynamoDB tables today, and what share of that data is actually used? Second, which of those selections map to a partition key? Those are your immediate wins. Third, how many custom Lambda or Step Functions export jobs exist only to filter data before it hits S3? Each one is a retirement candidate, and retiring code is the cheapest maintenance there is.
AWS rarely ships a feature that lowers the bill, reduces risk and deletes code in the same release. This one does, provided your keys cooperate. If they do not, that is worth knowing too, because it tells you where your data model is taxing every future request. The request documentation is a good handoff link for the engineer who gets this ticket.
At Enkompass (enkompass.net), this is our home turf. We help SaaS teams model DynamoDB around tenants so offboarding, compliance archives and analytics exports cost a fraction of a full-table dump. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.