DynamoDB vs S3: When to Use Each Service

Choose DynamoDB for small application records that need indexed queries, conditional updates and transactions. Choose Amazon S3 for objects such as images, videos, documents, exports and analytical files. Many applications use both: DynamoDB stores searchable metadata and an S3 object key, while S3 stores the larger payload.

DynamoDB and S3: an overview

DynamoDB is a managed key-value and document database. Its unit of storage is an item with a primary key and attributes. You can update selected attributes, query key ranges and add indexes for additional access patterns.

S3 is object storage. In a general purpose bucket, you retrieve an object by its key and can list keys by prefix. An object can contain JSON, but S3 does not automatically create database indexes over its fields. For example, storing customer records as JSON files does not give you a query for every customer in a city.

The comparison now also includes specialized S3 products. S3 Tables stores analytical tables in Apache Iceberg format, and S3 Vectors stores and searches vector embeddings. Those capabilities have their own APIs and workload goals; distinguish them from ordinary object GET and PUT operations.

DynamoDB vs S3 at a glance

Availability and durability

DynamoDB replicates data across Availability Zones within a Region. Global tables add multi-Region replication when the application needs it. Replication is separate from backup: a valid delete can propagate, so retain recovery points for accidental changes.

An S3 bucket has a Region; a globally unique bucket name does not make its contents automatically multi-Region. S3 Standard and several other classes store data across multiple Availability Zones. S3 One Zone-IA and S3 Express One Zone use one Availability Zone. Do not apply Standard's resilience properties to every storage class.

AWS describes durability, availability and retrieval differences in the storage-class documentation. Select a class based on whether the objects are replaceable, how quickly you must retrieve them and whether a zonal loss is acceptable. Replication, versioning and Object Lock solve different recovery or retention problems.

Scalability, latency and performance

DynamoDB

DynamoDB is designed for low-latency item access. On-demand capacity handles variable workloads without specifying provisioned throughput; provisioned capacity can suit predictable demand. Neither mode fixes a hot partition key or an application that repeatedly scans a large table.

Keep the data needed for a request together, and design indexes for the queries you actually run. Large item sizes increase request consumption even when you only need a small part of the record. The capacity and item-size calculator helps make that cost visible.

S3

S3 scales object requests automatically, but the scaling is gradual and applications must handle retries. Parallel transfers and multipart uploads help with large datasets. AWS's S3 performance guidance explains prefix-level request scaling and temporary Slow Down responses.

There is no single latency figure for all S3. Standard object access, archive retrieval and Express One Zone serve different needs. Express One Zone is designed for single-digit millisecond access within a selected Availability Zone. For media delivery, also consider where clients are located and whether a content delivery cache avoids repeated origin reads.

Transfer Acceleration addresses long-distance transfers; it does not add secondary indexes or turn S3 into an application database. Benchmark object size, network distance, storage class and concurrency together.

Size limits and large objects

DynamoDB's 400 KB item limit includes attribute names and values. S3 is the usual place for payloads that do not fit, such as uploaded PDFs and videos. Current multipart upload limits list a maximum object size of 48.8 TiB. Single-request upload and part limits still apply.

Compression or splitting a DynamoDB record into multiple items can also work, but each has consequences. Compressed content cannot be queried as ordinary attributes. Split records require extra reads and careful updates. Choose S3 when the payload is mainly downloaded as a file and keep the attributes needed for filtering in DynamoDB.

Security

DynamoDB encrypts data at rest by default. AWS owned, AWS managed and customer managed key options have different control and billing implications. IAM and resource-based policies control data access; VPC endpoints support private connectivity.

For S3, start with private buckets, Block Public Access and IAM or bucket policies. Modern S3 defaults disable ACLs for new buckets through Object Ownership. Presigned URLs can grant time-limited object access without making the bucket public. Object Lock can protect object versions from deletion for a retention period.

The S3 service guide covers these controls and the consistency model. Protect the metadata and payload together: a private DynamoDB row does not protect a publicly accessible S3 object. Avoid storing a short-lived presigned URL as the permanent reference; store the object key and generate access when needed.

Backups and restore

DynamoDB supports on-demand backups and point-in-time recovery. PITR has a configurable recovery window of 1 to 35 days and restores into a new table. On-demand backups are useful for longer retention; use a scheduled backup policy when regular recovery points are required.

S3 versioning retains object versions, while AWS Backup adds centralized backup policies and recovery points. AWS Backup for S3 supports continuous and periodic backups and requires versioning. Check its supported bucket types, storage classes and restore limitations before treating every S3 feature as covered.

When using both services, rehearse restoring a matching set of metadata and objects. Restoring the table to yesterday while retaining only today's overwritten objects can leave valid-looking records pointing to the wrong content. Version IDs or immutable object keys make that recovery problem easier to manage.

Pricing

DynamoDB pricing depends on requests or provisioned throughput, item size, storage and optional features. Indexes, backups and replication can materially affect the bill. On-demand request charges do not have the same free allowance as provisioned capacity.

S3 pricing depends on storage class, bytes stored, requests, retrieval and data transfer, plus enabled management features. Some classes have minimum storage durations or billable object sizes. Tables and Vectors have additional pricing dimensions. Use Region-specific rates instead of comparing a storage-only quote with an entire database bill.

For a document application, estimate metadata reads separately from downloads. A large PDF downloaded rarely has a different cost profile from a small record updated on every page view. The DynamoDB pricing calculator can estimate the database side; include S3 requests and transfer on the object side.

Use DynamoDB and S3 together

A practical upload workflow is to write the object, then conditionally publish its metadata record. Keep the upload pending until both steps succeed, retry safely and clean up abandoned objects. There is no atomic transaction spanning S3 and DynamoDB, as AWS notes in its large-item design guidance.

For example, a content system can query DynamoDB for documents belonging to a customer, then retrieve each selected file from S3. A gaming service can keep current player state in DynamoDB and replays in S3. The application decides what to do if a referenced object is missing; it should not silently show a complete upload before the payload exists.

For analytics, export DynamoDB data to S3 without consuming table read capacity. Imports from S3 create a new DynamoDB table; they are not an upsert mechanism for an existing table. Dynobase's S3 import workflow can help prepare that import.

Do S3 Tables and S3 Vectors replace DynamoDB?

S3 Tables provides managed Iceberg table storage and maintenance for analytics. Query engines such as Athena, Redshift and Spark run SQL against it. It is useful for historical analysis and data lake workflows, including DynamoDB data delivered through AWS Glue zero-ETL. It does not provide the same operational item API as DynamoDB.

S3 Vectors provides vector indexes, similarity queries and metadata filtering. DynamoDB also supports native vector indexes on on-demand tables. Compare freshness, latency, filtering, integration and cost for your retrieval workload instead of assuming that all embedding storage has the same behavior.

For ordinary application design, the division remains useful: keep frequently updated, indexed state in DynamoDB and large objects in S3. Add analytical tables or vector indexes where their specific query model solves a requirement.