DynamoDB bulk put items loads a live table from S3 without touching its throughput

November 5, 2026. AWS announces general availability of bulk put items for Amazon DynamoDB. A managed job. That is what loading data from S3 into an already-serving table now becomes. No throughput impact. The writes run on dedicated system capacity that does not count toward your CloudWatch metrics or your auto scaling rules. Why it matters: most teams still load enrichment files through home-grown pipelines — Glue, EMR, Lambda — that compete with application traffic on the very same table.

What bulk put items replaces

DynamoDB built its reputation on single-digit-millisecond latency at any scale. That same quality is what made bulk loading historically delicate. An import is a bursty workload arriving on top of a table that is serving real traffic. The standard answer used to be a purpose-built pipeline — AWS Glue, Amazon EMR, or a chain of Lambda functions — plus careful capacity management so the import writes did not choke the application writes.

Bulk put items removes that layer. You point it at an S3 location containing files written as line-delimited DynamoDB JSON or Amazon Ion, optionally compressed with gzip or zstd. The service reads the objects, validates each record, and writes the items in the background. Anything that does not land is recorded in a report delivered to an S3 bucket you choose.

Two details change the operational story. First, the writes use dedicated system capacity: they do not count toward your read and write CloudWatch metrics, so your alarms and auto scaling rules keep working unchanged. Second, the load is cross-account: a data team can produce and import the files from one account and land the data in a production table owned by another.

Conditions that travel with the record

This is where custom pipeline code used to pile up. With bulk put items, conflict handling is expressed in the data itself. Each line carries the item and, optionally, its own condition expression, using the same grammar as PutItem.

{"Item": {"Artist": {"S": "No One You Know"}, "SongTitle": {"S": "Call Me Today"}}}
{"Item": {"Artist": {"S": "Acme Band"}, "SongTitle": {"S": "Happy Day"}, "Origin": {"S": "import"}}, "ConditionExpression": "attribute_not_exists(Artist)"}
{"Item": {"Artist": {"S": "The Ternaries"}, "SongTitle": {"S": "Blue"}, "Version": {"N": "12"}}, "ConditionExpression": "#v < :v", "ExpressionAttributeNames": {"#v": "Version"}, "ExpressionAttributeValues": {":v": {"N": "12"}}}

An attribute_not_exists(Artist) condition yields an insert-only write that never touches existing data. A condition comparing a version attribute writes only when the incoming copy is newer than the one already in the table — so an export file cannot overwrite items the application has updated since the export was taken. Because the condition travels with the record, a single file can mix unconditional, insert-only, and version-guarded writes. An item skipped by its condition is not a failure: it counts toward the processed total and shows up in the report.

Standard or Accelerated: picking a tier

Every operation runs on one of two performance tiers, chosen at launch time.

• Standard — the more cost-effective tier, right for most loads: periodic enrichment, background population, recurring backfills. Its throughput depends on the number of items, their size, and how many global secondary indexes each write propagates to.
• Accelerated — targets higher throughput for deadline-bound work: migrations, recovery scenarios with an RTO, recurring loads in a fixed window. The database blog post cites a time under one hour for 100 million items of 1 KB each.

You pay per the tier you select, and AWS flags one thing teams must know before launching: cancelling an operation does not roll back items already written. The load is idempotent per record — via conditions — not transactional as a whole.

What it changes for ingestion pipelines

The canonical use case is not a from-zero migration but continuous enrichment. Machine-learning insights, product catalog updates, attribute backfills: data produced outside DynamoDB arrives as files in S3 and must land in a table that is already serving traffic.

Bulk put items reduces that loop to three decisions: where the files are, which tier, and which conditions. It does not replace AWS Glue or EMR for transformation — you still have to produce conformant files — but it replaces the write orchestration part, which was the fragile one.

The remaining watch-item is the same as with any bulk load: the rejection report. Items rejected by validation or skipped by a condition are recorded, not rewritten. A team that does not read that report believes it loaded a catalog when part of it was silently dropped.

Verdict

If you regularly load S3 files — enrichments, catalogs, backfills — into a production DynamoDB table, switch to bulk put items and delete the home-grown write pipeline: the Standard tier is enough, and the dedicated capacity spares you from retuning auto scaling before every import. Put an attribute_not_exists or a version comparison on every record to make the load idempotent, and alarm on the rejection report. Reserve the Accelerated tier for migrations and RTO-bounded windows, where completion time is worth the premium — and remember that cancelling does not rewind writes that already went through.

References

• AWS Database Blog — “Introducing bulk put items for Amazon DynamoDB: Load data from Amazon S3 into existing tables at scale” (Lee Hannigan and Anugrah Prakash, November 5, 2026)
• AWS News Blog — “AWS Weekly Roundup: AgentCore Runtime V2, Amazon DynamoDB bulk put items, and more” (Daniel Abib, November 9, 2026)
• ETTAYEB — our analysis of the Hive-to-Iceberg migration in S3 Tables