AWS Makes DynamoDB Bulk Put Items Generally Available: S3 Files Load Into Existing Tables on Separate Capacity From $0.10 per GB in US East, but Records Without a Condition Overwrite, Stream Consumers Still See the Writes and Global Tables Are Not Supported

On November 5, 2026, AWS announced general availability of bulk put items for Amazon DynamoDB. It is a managed feature that writes data from Amazon S3 into an existing table. Before this, loading files produced by other systems into a live table usually meant a custom pipeline, a job in AWS Glue or Amazon EMR, and careful management of table capacity. With bulk put items, you point DynamoDB at the S3 location of your input files, name an output location for a report, and choose a tier. The announcement says the writes do not affect the existing workload, and the launch blog and developer guide say they use separate capacity and consume none of the table's read or write capacity.

Input files are line-delimited DynamoDB JSON or Amazon Ion, optionally compressed with gzip or zstd. Each record can carry its own condition expression, written in the same syntax as PutItem. A condition such as attribute_not_exists on the partition key gives insert-only writes, and a comparison on a version attribute writes an item only when the incoming copy is newer. One file can mix unconditional, insert-only and version-guarded records. Two details deserve attention. A record with no condition is written unconditionally and overwrites any existing item with the same key. And if every item must enforce the same condition, the condition has to be repeated on every record in the files. An item skipped by its condition is not a failure: it counts as processed and appears in the report if you ask for condition check failures.

The operation is asynchronous. The start call returns an operation ARN, carries a client token so that a retried start does not launch a duplicate, and the first minutes are spent provisioning, so counters can read zero early on. The identity that starts it needs account-scoped and table-scoped permissions, read access to the input bucket, write access to the report bucket and the relevant AWS KMS keys. An operation ends as COMPLETED, COMPLETED_WITH_ERRORS, FAILED or CANCELLED. Cancelling does not roll back items already written, so a cancelled import leaves the table partly updated. The report lists records that were not written, with the source object, the position in that object, and the reason. For a failed condition it shows both the new item and the existing item. The blog advises treating COMPLETED_WITH_ERRORS as a normal path, correcting the error records and re-importing only those.

There are two tiers. Standard is the default and the cheaper one, meant for flexible-timing work such as periodic enrichment and backfills. Accelerated aims for higher throughput for deadline work such as migrations and recovery. AWS gives estimates for Accelerated on a well-scaled table with a high-cardinality partition-key space distributed evenly, input split across multiple similarly sized S3 objects and no global secondary index replication: under 10 minutes for 10 million 1 KB items, under 1 hour for 100 million, and 2 to 4 hours for 1 billion. AWS calls these illustrative starting points. It also warns that early runs may outpace table scaling and that completion times may only settle after three to five runs of the same file shape.

Pricing is byte-based. In US East (N. Virginia) the blog lists $0.10 per GB for Standard and $0.20 per GB for Accelerated, with a 1 KB minimum per item, applied separately to the table and to each index. A condition check that fails is still billed, and items rejected by validation are not. The same post gives a worked example of 100 million 1 KB items at $10.00 on Standard and $20.00 on Accelerated. We repeat these figures only for that Region; the announcement refers to pricing pages for other Regions.

The limits are specific. One bulk put items operation can run per table at a time, and not while an index is being created. Each account can have up to five Standard and five Accelerated operations in flight. An operation can cover up to 100 GB on Standard and up to 1 TB on Accelerated, and the target table must be active. Global tables are not supported at launch, and a replica cannot be added while an operation runs. On tables with a vector index only Standard is supported. The feature writes whole items and does not update single attributes, so UpdateItem remains the tool for that. Standard is available in all commercial Regions and the AWS GovCloud (US) Regions, while Accelerated is available only in the Regions listed on a separate page, so Standard availability should not be read as Accelerated availability.

Our reading: the headline of no impact is true for table capacity and for application read and write metrics, but the blog itself lists effects elsewhere. Imported items appear in DynamoDB Streams and Kinesis output as if they were application writes, so a large import can overload stream consumers unless they are sized for the extra throughput or the operation's write rate is capped with MaxWriteRequestUnits. The blog warns that a low cap can stretch the run past its time limit and make it fail, but none of the pages we saved states what that time limit is. An in-flight transaction on an item takes precedence over the import. Because bulk writes do not appear in consumed-capacity metrics, table alarms will not tell you an import went wrong, and the operation status is the signal to watch. For a handful of items, PutItem and BatchWriteItem remain the right tools.