DynamoDB Bulk Put Items: Loading S3 Files Into Existing Tables, and When to Use It

Since November 5, 2026, DynamoDB can write data from files in S3 into a table that already exists, with a condition per item, billed by the gigabyte written rather than by write requests. How it compares with Import from S3 (new tables only) and with BatchWriteItem from your own code, what AWS has and hasn't said about capacity, and what to test before a production backfill.

Until this month, getting a large file into an existing DynamoDB table meant writing your own loader: a Lambda, a Glue job or a script calling BatchWriteItem, with retries, throttling and a record of what failed. Import from S3 existed, but only into a new table. Bulk put items is the managed version for tables already in use.

Good uses

• Daily or weekly refreshes from a data pipeline into a serving table.

• Backfilling a new attribute or a new index's keys across existing items.

• Migrations where the target table is already live, using insert-only conditions so newer writes from the application aren't overwritten.

• Large catalog or reference-data updates.

Check before a production run

• Capacity: the announcement doesn't say whether bulk put draws on the table's throughput or how it interacts with live traffic. Run it against a copy at production size and watch latency and throttling.

• Indexes: billing counts bytes written to secondary indexes too, so a table with three indexes that project everything costs roughly four times the data size.

• Small items: with a 1 KB minimum, a million 200-byte items bill as a gigabyte.

• Failures: find out how failed items and failed conditions are reported, and keep the run idempotent so it can be repeated.

• Price: compare the per-GB rate on the pricing page with what the same writes cost as write requests; for many small items on-demand writes may be close.