Amazon DynamoDB 常見問答集

DynamoDB 是無伺服器、全受管的分散式 NoSQL 資料庫服務，可在任何規模下提供個位數毫秒的效能。DynamoDB 提供零基礎結構管理、零停機時間維護，以及即時擴展能力，可滿足任何應用程式需求，並且採用依請求計費方式。無需冷啟動，無需版本升級，也無需維護時段。DynamoDB 是一項全受管服務，省去了備份、安全、合規、監控等無差別資料庫管理任務的繁重工作。對於全球分散式應用程式而言，DynamoDB 全域資料表是多區域、多重作用中資料庫，具有最高 99.999% 的可用性，以及提供最高級別的資料庫恢復能力。該服務支援強大的多區域一致性，從而確保應用程式永遠可供使用，且始終可在任何區域讀取相同的資料，從而可讓您建置零 RPO 應用程式。DynamoDB 採用一系列安全控制與合規標準建置，其目的滿足政府、全球銀行，以及其他高敏感性組織的各項要求。

使用 DynamoDB，客戶可以將操作和擴展分散式資料庫的管理重擔交給 AWS，而無須擔心硬體佈建、設定和組態、輸送容量規劃、複寫、軟體修補或叢集擴展等問題。您可以在幾分鐘內部署分散式 NoSQL 資料庫。DynamoDB 會自動調整輸送容量，以符合工作負載需求，並隨著表格大小增長分割及重新分割資料。此外，DynamoDB 會將資料同步複寫至 AWS 區域內的三個可用區域 (AZ)，為您提供高可用性和資料耐久性。

DynamoDB 的獨特優勢包括：它是久經驗證的全受管、可擴展至零的無伺服器資料庫，可提供回應不到 10 毫秒的效能和高達 99.999% 的可用性。憑藉其大規模且一致的效能，DynamoDB 還提供內建的安全性、耐久性和可靠性，可滿足最嚴苛要求的全域應用程式所需。憑藉其易用性，無論是新型資料導向與生成式 AI 應用程式，還是追求一致快速效能與無限可擴展性的既有網際網路規模應用程式，皆經常採用 DynamoDB。

DynamoDB 資料表類別是 DynamoDB 資料表的效能和成本最佳化選項。兩個可用的資料表類別是 DynamoDB 標準 (預設資料表類別，專為需要最高效能的工作負載而設計，最適合具有不可預測工作負載的資料表) 和 DynamoDB 標準 – 不常存取 (針對儲存成本佔主導地位的資料表進行最佳化的資料表類別，非常適合儲存不常存取的資料的資料表)。標準資料表的讀取和寫入成本較低，但儲存成本較高。標準 IA 資料表的儲存成本較低，但讀取和寫入成本較高。您可以在 30 天內在這些資料表類別之間切換兩次，而無需停機時間，從而讓您根據資料表的用量模式來最佳化成本。這些類別之間的選擇取決於應用程式的特定需求和資料的存取模式。

在 DynamoDB 中選擇資料表類別時，需要考慮數個因素。最常見的考慮因素是資料的存取模式、成本考量和工作負載可預測性。您可以在資料表類別之間切換，無需任何編碼或停機時間，因此，如果您的需求隨著時間的推移而變化，您可以調整您的選擇。

DynamoDB 標準 – IA (不常存取) 資料表可與現有的 DynamoDB 功能無縫配合使用。它們使用與一般 DynamoDB 資料表相同的 API，因此您可以將它們與現有的應用程式搭配使用，而無需變更程式碼。它們支援用於多區域複寫的全域資料表、時間點復原 (PITR)、隨需備份、使用 AWS Key Management Service (KMS) 進行靜態加密、DynamoDB Streams、自動刪除項目的存留時間以及交易式讀寫操作。標準 – IA 資料表與 DynamoDB Accelerator (DAX) 相容。

Amazon DynamoDB 將資料儲存在分割區中。分割區是資料表的儲存配置，由固態硬碟 (SSD) 支援，並在 AWS 區域內的多個可用區域之間自動複寫。分割區管理完全由 DynamoDB 處理，您永遠不必自行管理分割區。

可儲存在 DynamoDB 資料表中的項目大小上限為 400 KB。沒有預先定義的儲存限制。

是，DynamoDB 可以儲存 BLOB；但是，它通常不適合儲存文件或映像。更好的架構模式是將指向 Amazon S3 物件的指標儲存在 DynamoDB 資料表中。

依預設，儲存在 Amazon DynamoDB 資料表中的資料沒有設定到期時間或刪除時間。資料將無限期保留在資料表中，除非客戶明確刪除或透過存留時間 (TTL) 刪除 (如果啟用了 TTL)。

可儲存在 DynamoDB 資料表中的項目數沒有預先定義的限制。DynamoDB 可在任意數量的項目中擴展至數百 TB 或更多資料。

雖然技術上可以將映像作為二進位資料 (base64 編碼) 儲存在 DynamoDB 中，但由於 400 KB 項目大小限制，存在一些限制和缺點。更好的做法是將映像儲存在 Amazon S3 (Simple Storage Service) 中，然後將 S3 物件 URL 或金鑰儲存在 DynamoDB 中，而不是將映像直接儲存在 DynamoDB 中。

若要在 DynamoDB 中儲存清單，您需要使用 DynamoDB 的清單資料類型之一 – 清單或集。將項目寫入資料表時，該屬性的值可以是純量 (非物件) 資料類型 (例如字串、數字等) 的陣列或集合。DynamoDB 將自動負責序列化清單資料，並以維護清單結構的方式進行儲存。然後，您可以查詢資料表屬性，以擷取完整清單。從清單中新增、更新或移除元素的工作方式與一般寫入操作相同。

是，DynamoDB 支援將地圖儲存為屬性資料類型。 

是，DynamoDB 支援 IAM 許可。可以在以身分為基礎的政策、以資源為基礎的政策或其他 AWS 政策中定義 IAM 許可，以控制對 DynamoDB 資源的存取。您可以將 IAM 政策連接至 IAM 使用者、群組、角色及 DynamoDB 資料表和串流，並視需要進行控制。

透過 AWS PrivateLink，您可以使用介面 VPC 端點和私有 IP 位址簡化虛擬私有雲端 (VPC)、DynamoDB 和內部部署資料中心之間的私有網路連線。使用 PrivateLink，可以透過私有連線存取 DynamoDB 資料表，且請求不會離開 Amazon 網路。這增強了安全性，因為流量確實流經任何網路閘道，並且可以使用 IAM 政策和安全群組控制存取。PrivateLink 對於具有資料安全要求且需要低延遲的應用程式很有用。它還使 DynamoDB 資料表可從跨內部部署網路和 AWS 的混合環境存取。

是，DynamoDB 支援以資源為基礎的政策，適用於資料表和串流。每個資料表的以資源為基礎的政策也涵蓋資料表索引 (全域次要索引和本機次要索引) 的存取許可。使用以資源為基礎的政策，客戶可以為 DynamoDB 資料表和其他資源定義精細分級的存取許可，而無需在 AWS 帳戶層級授予完整存取權。這些政策可讓客戶控制哪些使用者、角色和聯合身分使用者可以對特定 DynamoDB 資料表、索引和串流執行讀取、寫入或刪除等動作。以資源為基礎的政策在每個 DynamoDB 資源內連接和管理。

以資源為基礎的政策支援與 AWS Identity and Access Management (IAM) Access Analyzer 和封鎖公開存取 (BPA) 功能整合。IAM Access Analyzer 可協助客戶調整許可並遵守最低權限。BPA 可協助客戶防止公開存取 DynamoDB 資料表、索引和串流，並始終透過 DynamoDB 啟用。
 

DynamoDB 支援以屬性為基礎的存取控制，通常可用於 DynamoDB 資料表和索引。

是，您可以透過 VPC 端點使用 Amazon DynamoDB。DynamoDB 支援兩種類型的 VPC 端點 – 閘道端點和使用 AWS PrivateLink。透過閘道端點，您可以從 VPC 存取 DynamoDB，而無需為 VPC 使用網際網路閘道或 NAT 裝置。但是，閘道端點不允許從內部部署網路、從其他 AWS 區域的對等 VPC 或透過傳輸閘道存取。對於這些情況，您必須使用需要額外付費的 AWS PrivateLink。

精細分級的存取控制 (FGAC) 可讓 DynamoDB 資料表擁有者透過 AWS Identity and Access Management (IAM) 政策和條件對資料表中的資料進行精細控制。FGAC 可讓擁有者提供存取資料表的項目或屬性以及關聯動作的許可。精細分級的存取控制與 AWS IAM 配合使用，後者可管理安全憑證和關聯的許可。

是，Amazon DynamoDB 中的所有使用者資料在傳輸和靜態時均完全加密。

HTTPS 通訊協定用於使用 Secure Sockets Layer 加密來保護網路流量。

DynamoDB 靜態加密使用儲存在 AWS Key Management Service (KMS) 中的加密金鑰。靜態資料使用 AES-256 進行加密，這是需要最高層級的安全性的黃金標準。

下列金鑰類型可用於加密靜態資料：
1.AWS 擁有的金鑰：這些金鑰完全由 AWS 管理，如果未指定其他選項，則預設使用。它們可免費使用，不需要額外的設定。
2.AWS 受管金鑰：這些是儲存在 AWS Key Management Service (KMS) 中的客戶主金鑰 (CMK)，由 AWS 代表客戶建立、管理和使用。與 AWS 擁有的金鑰相比，它們提供了額外的控制和稽核功能。
3.客戶自管金鑰：這些是您在 AWS KMS 中建立、擁有和管理的 CMK。它們提供對加密金鑰的最高層級的控制，包括建立、輪換、停用和定義存取控制的能力。

其中每種金鑰類型都提供了便利、控制和成本之間的不同平衡。AWS 擁有的金鑰使用起來最簡單，而客戶自管金鑰提供了最大的控制權，但需要更多的管理開銷。

靜態加密透過在包含敏感資訊的檔案處於非作用中狀態時，對其進行加密來協助保護資料。當資料靜態加密時，未經授權方無法存取純文字內容，即使他們可以實際存取儲存資料的裝置亦如此。這不僅為存取控制提供了額外的資料安全層，還有助於確保機密資訊保持私密，即使實體裝置遺失或遭竊亦如此。

是，DynamoDB 支援對資料表上的項目層級變更進行稽核記錄。DynamoDB 會與 AWS CloudTrail 整合，後者是一項服務，提供使用者、角色或 AWS 服務在 DynamoDB 中在項目層級所採取動作的記錄。擷取的其他日誌記錄資料包括建立、更新、刪除以及任何條件式檢查失敗。客戶可以存取儲存在 CloudWatch Logs 中的這些日誌記錄，並建置應用程式來分析項目層級變更，以用於稽核、監控或其他目的。稽核日誌記錄可讓您精細地查看資料變更，而不影響 DynamoDB 資料表的正常讀取/寫入效能。

是，您可以使用 Amazon DynamoDB 建置符合 HIPAA 規範的應用程式及儲存醫療保健相關資訊，包括與 AWS 共同履行的商業夥伴協議 (BAA) 下的受保護醫療資訊。

DynamoDB 符合許多合規認證，包括符合 HIPAA 資格、FedRAMP、ISO 27001、SOC 1/SSAE 16/ISAE 3402 (之前稱為 SAS 70) 和 SOC 2。如需詳細資訊，請參閱 DynamoDB 的產業合規驗證。您可以在 AWS Artifact 中下載 AWS 合規報告。

Amazon DynamoDB 全域資料表是一個全受管、無伺服器、多區域和多作用中資料庫。全域資料表提供了 99.999% 的可用性、提升的應用程式彈性，以及改善業務持續性。其會在您選擇的 AWS 區域自動複寫 DynamoDB 資料表，因此您可以實現快速的本機讀取和寫入效能。全域資料表使用與單一區域 DynamoDB 資料表相同的 API，因此您可以輕鬆使 DynamoDB 資料表全域可用，而無需變更應用程式。

全域表是一個或多個複本資料表的集合，均由單一 AWS 帳戶擁有。對於單一 Amazon DynamoDB 全域表，每個 AWS 區域只能有一個複本資料表。

您應使用全域資料表，來提高應用程式跨多個區域的恢復能力。全域資料表也可讓應用程式在發生整個區域隔離或降級等特殊情況下維持高度可用性。

有兩個版本的 DynamoDB 全域資料表可用：2019.11.21 版 (目前) 和 2017.11.29 版 (舊版)。客戶應為所有新的全域資料表使用 2019.11.21 版 (目前)，因為此版本效率更高，且耗用較少的寫入容量。使用 2017.11.29 版 (舊版) 的任何人都應將全域資料表升級至 2019.11.21 版 (目前)。

您只需在 AWS 管理主控台中按幾下，即可升級全域資料表版本。從 2017.11.29 版 (舊版) 升級至 2019.11.21 版 (目前) 是一次性動作，無法回復。在升級之前，確保您已檢閱版本之間的行為差異，並執行所有必要的測試。如需詳細資訊，請參閱將全域資料表從 2017.11.29 版 (舊版) 升級至 2019.11.21 版 (目前)。

DynamoDB 全域資料表使用跨區域的多重作用中複寫，其中全域資料表中所有區域中的所有複本資料表都支援讀取和寫入流量。全域資料表沒有主要區域，因此在將讀取和寫入流量導向不同的區域時，不需要資料庫容錯移轉。在 AWS 區域被隔離或降級等特殊情況下，您的應用程式只需從不受影響的區域中的複本資料表讀取和寫入。如需詳細資訊，請參閱 DynamoDB 全域資料表設計的最佳實務。

複本資料表是單一 DynamoDB 資料表。每個複本資料表會存放相同的資料項目集、具有相同的資料表名稱，以及相同的主索引鍵結構描述。應用程式將資料寫入一個區域中的複本資料表時，DynamoDB 會自動將寫入的內容複寫到其他 AWS 區域中的其他複本資料表。

是的，DynamoDB 全域資料表可提升應用程式的恢復能力，並為單一區域提供強式一致性，藉此強化業務連續性。藉助多區域強一致性，您可以建置具有零 RPO 和最高層級恢復能力的應用程式。

您可依據此逐步指南，使用 DynamoDB 主控台、AWS CLI 或 AWS CloudFormation 建立全域資料表。

將不同區域中的其他複本新增至 DynamoDB 全域表之前，資料表必須啟用 DynamoDB Streams、具有與所有其他複本相同的名稱、具有與所有其他複本相同的分區索引鍵，且指定相同的寫入容量設定。

DynamoDB 全域資料表中的所有複本資料表名稱必須相同。

與其他資料庫類似，DynamoDB 會將資料存放在資料表中。資料表是項目的集合，每個項目都是屬性的集合。DynamoDB 使用主索引鍵，不重複識別資料表中的每個項目，並具有次要索引，以提供更大的查詢彈性。

是的，您可以在 DynamoDB 全域資料表的每個複本上啟用時間點復原。

是的，DynamoDB 支援變更資料擷取 (CDC)。這是使用串流模型實作的，允許應用程式以資料記錄串流的形式，近乎即時地擷取 DynamoDB 資料表中的項目層級變更。CDC 資料記錄串流可讓應用程式有效地處理並回應 DynamoDB 資料表中的資料修改。DynamoDB 為 CDC 提供兩種串流模型：DynamoDB Streams 和 Kinesis Data Streams for DynamoDB。若要協助您為應用程式選擇合適的解決方案，請參閱變更資料擷取的串流選項。

DynamoDB 串流是有關 DynamoDB 資料表中項目變更的有序資訊流程。DynamoDB Streams 會擷取資料表中複資料刪除後的、依時間順序排序的項目層級修改，並在日誌中儲存此資訊長達 24 小時。DynamoDB Streams 會自動擴展容量，讓您無需佈建和管理容量。 根據您的 DynamoDB Streams 組態，您可以檢視在修改前後顯示的資料項目。您可以建置取用這些串流事件的應用程式，並根據事件串流的內容調用工作流程。

當您想要使用與 AWS Lambda 的原生整合來透過觸發器回應資料變更、追蹤和分析客戶互動或以近乎即時地監控應用程式效能、擷取有序的事件序列，以及透過複寫項目層級交易資料來提高應用程式彈性時，DynamoDB Streams 很有用。

Kinesis Data Streams 可擷取任何 DynamoDB 資料表中的項目層級修改，並將其複寫至 Kinesis 資料串流。您的應用程式可以存取此串流，並以近乎即時地檢視項目層級的變更。使用 Kinesis Data Streams，您可以建置自訂的應用程式以處理或分析串流資料，滿足您的專業需求。與 DynamoDB Streams 不同，適用於 DynamoDB 的 Kinesis Data Streams 不提供記錄排序或重複資料刪除保證。記錄排序和重複資料刪除必須由用戶端應用程式使用項目層級記錄中的 ApproximateCreationDateTime 欄位來實作。

如果您需要與更廣泛的 Kinesis 功能 (例如 Kinesis Client Library、Amazon Managed Service for Apache Flink 或 Amazon Data Firehose) 整合、更長的資料保留和可重播性 (長達 365 天)，以及用於下游取用和串流分析的自訂碎片管理，適用於 DynamoDB 的 Kinesis Data Streams 很有用。

在 DynamoDB 資料表上啟用 DynamoDB 串流或 Kinesis 資料串流時，資料表會傳送資料記錄，以擷取對該資料表資料的任何變更。此資料記錄包括最近建立、更新或刪除任何項目的特定時間、該項目的主索引鍵、修改前項目的影像，以及修改後項目的影像

您可以使用 AWS 管理主控台、AWS SDK、AWS Command Line Interface (AWS CLI) 或 Kinesis Client Library (KCL)，在現有 DynamoDB 資料表上啟用或停用串流。

當您特別需要追蹤 DynamoDB 資料表變更時，選擇 DynamoDB Streams。滿足更廣泛的串流需求、更高的輸送量要求或需要更長的資料保留期時，選擇 Kinesis Data Streams。

Amazon DynamoDB 存留時間 (TTL) 功能會自動從資料表中刪除不再相關的過期項目，從而減少儲存用量並降低成本。使用 TTL，您可以定義每個項目的時間戳記來確定何時不再需要某個項目，而 DynamoDB 會自動從資料表中刪除該項目，而不會耗用任何寫入輸送量。每次建立或更新項目時，您都可以計算到期時間，並將其儲存在 TTL 屬性中。如果您儲存的項目在特定時間後失去相關性，則 TTL 很有用。

DynamoDB 支援以使用者定義的主索引鍵執行 GET/PUT 操作。主索引鍵是表格項目唯一的必要屬性。建立資料表時指定主索引鍵，即可專屬辨識各個項目。DynamoDB 也能讓您使用全域次要索引和本機次要索引查詢非主索引鍵屬性，方便靈活查詢。

主索引鍵可以是單一屬性分區索引鍵或複合分區排序索引鍵。例如，單一屬性的分區索引鍵可以是 UserID。讓您快速讀取和寫入與特定使用者 ID 關聯的項目資料。

DynamoDB 會將複合分區排序索引鍵的索引，編製為分區索引鍵元素和排序索引鍵元素。這個複合鍵可保持第一個元素值和第二個元素值之間的層次結構。例如，複合分區排序索引鍵可能是 UserID (分區) 和時間戳記 (排序) 的組合。保持分區索引鍵元素不變，您可以在排序索引鍵元素中搜尋以擷取項目。透過這樣的搜尋方式，您可以使用 Query API 執行一些操作，例如，在一個時間戳記範圍中擷取單一 UserID 的所有項目。

DynamoDB 支援全域次要索引 (GSI) 中最多由八個屬性組成的主索引鍵，分割區和排序索引鍵每個屬性最多有四個屬性。

使用 DynamoDB 主控台或 CreateTable API 建立表格之後，您可以使用 PutItem 或 BatchWriteItem API 插入項目。接著，您可以使用 GetItem 及 BatchGetItem 擷取新增到表格中的項目；如果複合主鍵已啟用，且正在表格中使用，則可使用 Query API。

是。DynamoDB 是一項全受管的雲端服務，可透過 API 進行存取。於任一作業系統 (例如 Linux、Windows、iOS、Android、Solaris、AIX 和 HP-UX) 執行的應用程式均可使用 DynamoDB。建議您透過 AWS SDK 開始使用 DynamoDB。

DynamoDB 與 OpenSearch Service 的零 ETL 整合簡化了將資料從事務性資料儲存複製到搜尋資料儲存的操作複雜性。構建和管理用於保持事務性資料儲存和搜尋資料存儲同步的資料管道可能棘手且成本高昂，並且會出現難以跟蹤的間歇性錯誤。 

此整合讓 DynamoDB 客戶能夠透過提供完全受管的解決方案，從其事務性資料中獲得近乎即時的搜尋結果，確保事務性資料從 DynamoDB 寫入後，在幾秒鐘內就能在 OpenSearch Service 中使用。客戶只需選擇包含他們想要使用 OpenSearch Service 分析資料的 DynamoDB 資料表，此零 ETL 整合即可使用 OpenSearch Ingestion 管道將相應的架構和資料無縫複製到 OpenSearch Service 中。客戶可以將多個 DynamoDB 資料表中的資料複製到單個 OpenSearch Service 託管網域或無伺服器集合中，實現對多個應用程式的全面洞察，同時還可以整合核心分析資產，實現顯著的成本節省和營運效率提升。 

客戶可以透過適用於 DynamoDB 的 AWS 管理主控台、OpenSearch Service、AWS CLI、AWS SDK 或 AWS CloudFormation 開始使用此整合。要啟用整合，客戶首先要選擇需要複製資料的 DynamoDB 資料表。然後，客戶可選擇 DynamoDB Streams 進行近乎即時的複製，或選擇 DynamoDB 增量匯出進行延遲複製，並將兩者作為 CDC 機制，使兩個系統之間的資料保持同步。 

此零 ETL 整合會在客戶帳戶中設定 OpenSearch Ingestion 管道，該管道負責將資料複製到 OpenSearch Service 託管集群或無伺服器集合。OpenSearch Ingestion 理解 DynamoDB 資料表的結構，然後建立等效的 OpenSearch Service 託管域或無伺服器集合，並使用來自 DynamoDB 資料表的現有資料啟動目標系統。或者，客戶可以為將在 OpenSearch Service 中建立的索引指定架構。 

此零 ETL 整合為您提供了主控台，您可以在其中使用 Amazon CloudWatch 即時指標和日誌監控端到端整合的狀態。您可以設定警報，以防違反用戶定義的閾值。此整合還會持續監控 DynamoDB 資料表和 OpenSearch Service 索引的狀態，並在其中任何實體出現迴歸時立即通知使用者。

為確保 OpenSearch Ingestion 擁有在這兩個系統間複製資料的必要許可權，DynamoDB 與 OpenSearch Service 的零 ETL 整合會建立一個 IAM 角色，該角色具有從 DynamoDB 資料表中讀取資料並寫入 OpenSearch 網域或集合所需的許可權。然後，OpenSearch Ingestion 管道將擔任此角色，以確保在將資料從源移至目標時始終保持正確的安全狀態。

此零 ETL 整合使用 OpenSearch Ingestion 管道的原生資料轉換功能，對動態資料進行聚合和篩選。從 DynamoDB 資料表中移動資料時，客戶可能希望刪除一些欄位或根據現有欄位的聚合建立新欄位。 

客戶還可以選擇為 OpenSearch Ingestion 編寫自訂邏輯，以實現定制的轉換功能。對於其他只想將全部資料從源移至目標位置的使用者，此零 ETL 整合將提供開箱即用的 OpenSearch Ingestion 藍圖，這樣他們只需按幾下按鈕即可執行整合。

此零 ETL 整合為客戶提供了指定其自訂資料架構及索引映射的選項，此自訂資料架構供 OpenSearch Ingestion 在將資料從 DynamoDB 寫入 OpenSearch Service 時使用。這種體驗已添加到 DynamoDB 的使用者介面控制台中，因此客戶可以完全控制在 OpenSearch Service 上建立的索引的格式。

除需為現有底層元件支付費用外，使用 DynamoDB 與 OpenSearch Service 的零 ETL 整合不會產生任何額外費用。此零 ETL 整合使用 OpenSearch Ingestion 讀取 DynamoDB 資料表中的資料，並複寫至 OpenSearch Service。使用 DynamoDB 與 OpenSearch Service 的零 ETL 整合所需支付的費用是 OpenSearch Ingestion 跨系統複製資料所需的 OpenSearch 計算單位 (OCU) 的費用。此外，客戶可以選擇 DynamoDB Streams 或增量匯出作為 CDC 的選項。對於增量匯出，會產生與向 S3 儲存貯體寫入資料關聯的費用。對於 DynamoDB Streams，將向客戶收取使用 DynamoDB Streams 的標準費用。

在目前推出 OpenSearch Ingestion 的所有區域，均可使用 DynamoDB 與 OpenSearch Service 的零 ETL 整合。

是的，您可以為 Amazon DynamoDB 用量購買 Database Savings Plans，只要承諾在 1 年期內維持固定用量，即可節省高達 18% 的成本。 關於符合資格用量的其他資訊，請參閱 Database Savings Plans 定價頁面。

是的，DynamoDB 提供優渥的免費方案，包含 25GB 的儲存空間以及 25 寫入容量單位和 25 讀取容量單位 (WCU、RCU)，足以每月處理 2 億個請求。

DynamoDB 是完全無伺服器的非關聯式資料庫。與其他針對各種指標 (例如儲存) 收費的資料庫相比，DynamoDB 可以縮減為零，這代表當客戶使用隨需模式時，他們只需為消耗的作用中資源付費。

簡言之，隨需更適合偏好僅按照使用量付費或者無法預測工作負載的客戶。佈建容量深受應用程式展現出一致或可預測的流量而且偏好預測容量需求以控制成本的客戶的喜愛。

DynamoDB 很獨特，它是無伺服器資料庫，透過隨需定價，提供客戶僅需為消耗的資源付費的選項，並在不使用時縮減至零。資料庫在使用中時，會使用寫入請求單位和讀取請求單位來計算費用。

DynamoDB 包含一組廣泛的選項，可以新增至服務。部分清單包括：

• 隨需備分，可對特定時間點進行快照備份
• 適用於多區域、多重主動複寫的全域資料表
• DynamoDB Accelerator (DAX) 是一項與 Amazon DynamoDB 相容的快取服務，可透過記憶體快取減少延遲
• DynamoDB 串流，用於資料表中項目層級變更的時間順序序列