DynamoDB vs Amazon S3
DynamoDB 與 Amazon S3 解決的是不同的問題，因此「該用哪一個」這個問題的老實答案通常是兩個都用。DynamoDB 是一個鍵值與文件資料庫，用於你以鍵查詢、更新與查找的結構化記錄。Amazon S3 是物件儲存，用於檔案與 blob——影像、備份、log、影片——你會整份地存入與取出。兩者相輔相成，而非二選一。
我該用 DynamoDB 還是 S3？
當你有許多以鍵查詢、filter 與更新的小型結構化記錄，且需要個位數毫秒延遲時，使用 DynamoDB。當你要儲存與供應整份檔案或 blob——影像、備份、匯出檔——並以名稱取回時，使用 Amazon S3。兩者相輔相成：一個非常常見的做法是把物件存在 S3、把它的 metadata 存在 DynamoDB。
DynamoDB vs Amazon S3 一覽
| 特性 | DynamoDB | Amazon S3 |
|---|---|---|
| 主要用途 | 用於結構化記錄的 NoSQL 鍵值 / 文件資料庫 | 用於檔案、blob 與非結構化資料的物件儲存 |
| 資料單位 | 項目（一組型別化屬性），以 primary key 定址 | 物件（位元組 + metadata），以 bucket 內的鍵定址 |
| 每單位最大大小 | 每個項目 400 KB（屬性名稱 + 值） | 每個物件 5 TB（單次 PUT 最多 5 GB；更大的上傳使用 multipart） |
| 查詢 / 存取 | GetItem、Query、Scan、BatchGetItem、PartiQL、secondary index（GSI/LSI） | 以鍵做 GET / PUT / DELETE、對 bucket 做 LIST；透過 Amazon Athena 就地查詢（或供既有客戶使用的 S3 Select） |
| 延遲特性 | 任何規模下單一項目皆為個位數毫秒讀寫 | 耐久的物件輸送量；每請求延遲高於鍵值資料庫，並非毫秒級的記錄查詢 |
| 一致性 | 預設最終一致；可依請求取得強一致讀取 | 對所有物件與所有請求皆為強 read-after-write 一致（自 2020 年起） |
| 定價模式 | 讀 / 寫容量（RCU/WCU——隨需或佈建）+ 資料儲存每 GB-月 | 儲存每 GB-月（依儲存類別）+ 請求費用（PUT/GET/LIST）+ 資料取回 / 傳輸 |
| 最適合的工作負載 | 使用者設定檔、session、購物車、事件 / 狀態記錄、metadata、高輸送量的 OLTP 式存取 | 媒體、備份、data-lake 檔案、靜態資產、大型匯出檔、封存 |
以上每一格都取自官方 AWS 文件（見本檔頂端的 provenance 註記）。
何時使用 DynamoDB
當你的資料是以鍵存取的結構化記錄時，就採用 DynamoDB：
- 許多你逐一讀取、寫入與更新的小型項目（每個都在 400 KB 上限之內）。
- 可預測、低延遲的查詢——DynamoDB 目標是在任何規模下對單一項目做個位數毫秒讀寫。
- 能以 primary key 與 secondary index 表達的存取模式：以 id 取得、查詢某個 partition、在 partition 內做 filter。
- 帶細粒度更新的高寫入輸送量（變更一個屬性而無需重寫整筆記錄）。
如果你發現自己試圖把一個 5 MB 的檔案存進項目內，那就是你已抵達 DynamoDB 邊界的訊號——請參閱 DynamoDB 項目大小上限。
何時使用 S3
當你的資料是以名稱取回的整份檔案或 blob 時，就採用 Amazon S3：
- 影像、PDF、影片、音訊，以及其他二進位資產。
- 備份、資料庫匯出檔，以及稍後用像 Amazon Athena 這類工具查詢的 data-lake 檔案（Parquet、CSV、JSON）。
- 大型物件——S3 儲存每個最大 5 TB 的物件，遠超任何單筆資料庫記錄。
- 靜態網站資產與直接供應給使用者的內容。
S3 不是資料庫：你無法像查詢 DynamoDB 項目那樣，以豐富的索引查詢任意物件的內容。對物件做就地的 SQL 式篩選可透過 Amazon Athena 取得（S3 Select 對既有客戶仍可用，但已於 2024 年對新客戶關閉）。
搭配使用
這兩項服務結合起來威力最強。AWS 自己對於大於 DynamoDB 項目的資料的指引是：把物件存在 S3，並在 DynamoDB 中保留一個指標：
- 把大型檔案（影像、文件、影片）作為物件存入 S3。
- 把它的 metadata——S3 物件鍵、內容類型、擁有者、標籤、時間戳——作為項目存入 DynamoDB，在那裡可低成本查詢。
- 以鍵在 DynamoDB 中查找該記錄，再用儲存的識別碼從 S3 取得物件。
AWS 特別提醒的一個注意事項：跨 DynamoDB 與 S3 之間沒有交易，因此你的應用程式要處理部分失敗（例如，當 DynamoDB 寫入失敗時，清理掉一個孤立的 S3 物件）。
使用 DynamoDB
一旦你為資料中結構化的那一半選定了 DynamoDB，DynoTable 就是一款桌面 DynamoDB 用戶端，可在 macOS、Windows 與 Linux 上瀏覽、編輯與查詢資料表。它會讀取你標準的 AWS 憑證鏈，因此沒有任何 DynamoDB 專屬的東西需要遷移——把它指向你的區域與資料表，你的資料就留在 DynamoDB 中。
當你需要手動建立支撐上述 metadata-in-DynamoDB 做法的 GetItem、Query、Update 或 condition 運算式時，免費的 DynamoDB Expression Builder 會以 AWS SDK、CLI 與 boto3 的形式產生請求。要在決定哪些內容該放進 S3 之前，把項目對照 400 KB 上限做大小估算，項目大小計算器會量測一筆記錄的位元組大小。
FAQ
DynamoDB 能儲存檔案或影像嗎？
小型的可以，但有限制。DynamoDB 項目能容納二進位資料，但整個項目——每個屬性名稱與值——都必須維持在 400 KB 之內。若要存放更大的東西，AWS 記載的最佳做法是把檔案作為物件存入 Amazon S3，並在 DynamoDB 項目中保留 S3 物件鍵（加上 metadata）。
S3 比 DynamoDB 便宜嗎？
它們的定價方式不同，因此取決於工作負載而非有個一概而論的答案。S3 依儲存每 GB-月收費，加上每請求與取回費用，一般是大量不常存取位元組的較便宜歸宿。DynamoDB 依讀 / 寫容量加上儲存收費，並為高輸送量、低延遲地存取許多小型記錄而打造。把大型 blob 存在 DynamoDB 中既有大小限制，也相對昂貴——這正是為何 S3 物件加 DynamoDB metadata 的拆分是標準做法。
JSON 該用 DynamoDB 還是 S3？
如果該 JSON 是一筆你以鍵查詢與更新的結構化記錄——一個使用者、一筆訂單、一個 session——DynamoDB 適合，它會把 JSON 對映為型別化屬性並支援 PartiQL。如果該 JSON 是一份你儲存後再大量掃描的整份文件或 data-lake 檔案（例如用 Amazon Athena 查詢它），S3 適合。一個常見的混合做法是把可查詢的欄位保留在 DynamoDB，把完整的 JSON payload 作為物件存在 S3。
相關內容
- 學習：DynamoDB 項目大小上限 · 何時使用 DynamoDB
- 以 DynamoDB Expression Builder 視覺化地建立請求。
- 用 DynamoDB 項目大小計算器量測記錄大小。
- 下載 DynoTable 以操作你的 DynamoDB 資料表。
最後驗證於 2026-07-12，比對官方 AWS DynamoDB 與 Amazon S3 文件。Amazon S3、DynamoDB 與 Athena 是 Amazon Web Services 的服務，此處引用僅供識別之用。