DynamoDB and S3 (short for Simple Storage Service) are both storage/database services provided by Amazon to be exposed to the NoSQL database. S3 is used for wide data storage as it has capacity to store data up to a 5 TB maximum item size, where as DynamoDB has capacity to store data up to 64 KB, but both have no limit on attributes for a particular item. S3 creates a bucket that stores data. Buckets are the essential containers in Amazon S3 for data storage. S3 is for large data storage, which we are rarely going to use. For example, data stored for analysis purposes or data stored for the backup and restore procedure. It has a slower response time. DynamoDB is used for high performance. In DynamoDB, we need a key-value data store that can handle thousands of read/write operations per second.

DynamoDB is a flexible NoSQL database that we use to store small features, metadata, and index information—in short, data that is more dynamic. In DynamoDB, data retrieval is very fast because the data is stored on SSDs, and the data is replicated across many servers that are located in availability zones.

While using S3, we don't need to configure anything to get started. We need a key, and we can upload the data; it's the way to store data in S3. Now you only need to keep track of the key we used for a particular application. In DynamoDB, we need to configure a few things, such as when creating tables, we need to specify the primary key as well as make provision for the read/write throughput value. S3 doesn't support object locking, but if we need it, then we have to build it manually, whereas DynamoDB supports optimistic object locking. Optimistic locking is an approach to ensure that the client-side item that we are updating is the same as the item in DynamoDB. If we use this approach, then our database writes are protected from being overwritten by other writes.

One of the good features of S3 is that every S3 object or document that is stored in it has a web address. By using this web address, a document can be accessed without any impact on the web server or the database.

S3 uses the eventual consistency model in which, if no new updates are made on a given data item, all accesses to that item will return the last updated value. DynamoDB follows eventual consistency and strong consistency, in which all accesses are seen by all parallel processes, by all parallel nodes, and by all processors in sequential order. DynamoDB doesn't support spatial data. It can store points and extend it to build a Geohash-based index that also indexes lines (for example, roads) and areas (for example, boundaries) that represent arbitrary area features, which means each Geohash-index record stored in DynamoDB. But we can store this information if it's a small geographical area, otherwise the spatial feature is stored as an object in S3, with a pointer to the S3 location that is stored in DynamoDB.

DynamoDB is presently provisioned completely on SSD devices. SSD devices can read requests in a small fraction of time as compared to a magnetic disk (about 100 times faster) by servicing individual data, though the cost per GB of storage is much higher (approximately 10 times) than that of a magnetic disk. Hence DynamoDB can provide very low latency and high throughput compared to S3 but at a higher cost per unit of storage. Let's take a scenario in which 1 GB of DynamoDB storage costs $1 per month, while S3 storage costs between 4 cents and 12 cents per GB per month. This means it is eight times cheaper than DynamoDB. DynamoDB also provides a flexible fee structure based on the IO capacity. In this, 1,000 read operation per second will cost around 20 cents per hour, and the write operation is about 5 times more expensive, because SSDs can perform a read operation much faster than a write operation.

Now take a look at the tabular comparison between DynamoDB and S3: