Introduction

Amazon DynamoDB now has a built-in export path to Amazon S3, and for most large-table exports that is the feature you should reach for first. According to AWS documentation, DynamoDB exports to S3 are asynchronous, require point-in-time recovery on the table, and do not consume read capacity units during the export.

The Modern Default: Export to S3

The managed export flow is designed for analytics, backup-style exports, and large table snapshots. The basic CLI shape is:

1aws dynamodb export-table-to-point-in-time \
2  --table-arn arn:aws:dynamodb:us-east-1:123456789012:table/MyTable \
3  --s3-bucket my-export-bucket \
4  --s3-prefix exports/my-table \
5  --export-format DYNAMODB_JSON

AWS supports both DYNAMODB_JSON and ION export formats. The export runs asynchronously, and DynamoDB writes the output into the S3 bucket you specify.

The important prerequisite is that point-in-time recovery must already be enabled on the table.

Why Export to S3 Is Better Than a Full Table Scan for Large Exports

The managed S3 export has several advantages:

• no table read capacity is consumed during export
• no application code has to paginate the entire table
• exports can target a specific point in time within the PITR window
• AWS handles the snapshotting and file generation for you

That makes it the right answer when you need a large, durable table export rather than a custom application-side transformation.

Small or Custom Exports: Scan with Boto3

If you need a custom format, selective projection, or an application-driven export for a smaller workload, you can still read the table with the SDK and write the results wherever you need.

Example:

1import boto3
2import json
3
4dynamodb = boto3.resource("dynamodb")
5table = dynamodb.Table("MyTable")
6
7items = []
8response = table.scan()
9items.extend(response["Items"])
10
11while "LastEvaluatedKey" in response:
12    response = table.scan(ExclusiveStartKey=response["LastEvaluatedKey"])
13    items.extend(response["Items"])
14
15with open("export.json", "w", encoding="utf-8") as f:
16    json.dump(items, f, ensure_ascii=False, indent=2, default=str)

This gives you control, but it also means you are responsible for pagination, throughput impact, retries, and output formatting.

Know the Tradeoff Between the Two Approaches

Use managed export to S3 when:

• the table is large
• you want a point-in-time export
• you do not want export traffic to consume table read capacity
• the S3 output format is acceptable

Use a scan-based export when:

• you need only a subset of items or attributes
• you need a custom output schema
• you are building an application-specific data transfer step

These are different tools for different goals.

Exporting Incremental Changes

AWS documentation also supports incremental exports to S3. That is useful when you want changes over a time range rather than a full table snapshot.

For many data-lake workflows, that can be a better fit than repeatedly scanning the table or rerunning full exports unnecessarily.

Common Pitfalls

The biggest mistake is assuming table export and table scan are interchangeable. A scan reads live table data through the API, while Export to S3 is a managed snapshot-oriented workflow.

Another common issue is forgetting the PITR requirement. If point-in-time recovery is not enabled, the managed export request fails.

It is also easy to underestimate the cost and performance impact of scanning a large table from application code. For large exports, the managed S3 export path is usually safer and simpler.

Summary

• The modern default for large DynamoDB exports is the built-in Export to S3 feature.
• Managed exports require point-in-time recovery on the source table.
• Export to S3 is asynchronous and does not consume table read capacity.
• Use scan-based SDK exports only when you need custom application-level control.
• Choose the export method based on whether you need scale and snapshots or custom filtering and formatting.