本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
本節概述如何定期評估未使用的資源。隨著應用程式需求演變，您應確保沒有任何資源仍未使用且因此產生不必要的 Amazon DynamoDB 成本。在以下說明的程序中，將使用 Amazon CloudWatch 指標來識別未使用的資源，進協助您找出這些資源，並採取降低成本的行動。
您可以使用 CloudWatch 來監控 DynamoDB；該服務會收集並處理來自 DynamoDB 的原始資料，進而將這些資料轉換為便於讀取且幾近即時的指標。這些統計資料會保留一段時間，以便您存取歷史資訊，並更清楚了解自己的使用率。根據預設，系統會自動將 DynamoDB 指標資料傳送至 CloudWatch。如需詳細資訊，請參閱《Amazon CloudWatch 使用者指南》中的什麼是 Amazon CloudWatch？以及指標保留。
如何識別未使用資源
為了識別未使用的資料表或索引，我們會查看 30 天內的下列 CloudWatch 指標，以了解是否有對資料表的任何作用中讀取或寫入，或對全域次要索引 (GSI) 的任何讀取：
ConsumedReadCapacityUnits
在指定時段使用的讀取容量單位數目，可讓您追蹤已使用多少使用容量。您可以擷取資料表及其所有全域次要索引或特定全域次要索引的總消耗讀取容量。
ConsumedWriteCapacityUnits
在指定時段使用的寫入容量單位數目，可讓您追蹤已使用多少使用容量。您可以擷取資料表及其所有全域次要索引或特定全域次要索引的消耗總計寫入容量。
識別未使用的資料表資源
Amazon CloudWatch 是一項監控和可觀察性服務，提供 DynamoDB 資料表指標，以利您識別未使用的資源。您可以透過 AWS Management Console 和 AWS Command Line Interface來檢視 CloudWatch 指標。
若要透過 檢視資料表指標 AWS Command Line Interface，您可以使用下列命令。
-
首先評估資料表的讀取：
aws cloudwatch get-metric-statistics --metric-name ConsumedReadCapacityUnits --start-time <start-time> --end-time <end- time> --period <period> --namespace AWS/DynamoDB --statistics Sum -- dimensions Name=TableName,Value=<table-name>為了避免將資料表誤認為未使用，請評估較長期間內的指標。選擇適當的開始時間和結束時間範圍 (例如 30 天) 及適當的期間 (例如 86400)。
在傳回的資料中，任何大於 0 的總和都表示您所評估的資料表在該期間內曾經接收讀取流量。
下列結果顯示在評估期間接收讀取流量的資料表：
{ "Timestamp": "2022-08-25T19:40:00Z", "Sum": 36023355.0, "Unit": "Count" }, { "Timestamp": "2022-08-12T19:40:00Z", "Sum": 38025777.5, "Unit": "Count" },下列結果顯示在評估期間未接收讀取流量的資料表：
{ "Timestamp": "2022-08-01T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-20T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, -
接下來，評估資料表的寫入數：
aws cloudwatch get-metric-statistics --metric-name ConsumedWriteCapacityUnits --start-time <start-time> --end-time <end- time> --period <period> --namespace AWS/DynamoDB --statistics Sum -- dimensions Name=TableName,Value=<table-name>為了避免將資料表誤認為未使用，建議您評估較長期間內的指標。選擇適當的開始時間和結束時間範圍 (例如 30 天) 及適當的期間 (例如 86400)。
在傳回的資料中，任何大於 0 的總和都表示您所評估的資料表在該期間內曾經接收讀取流量。
下列結果顯示在評估期間接收寫入流量的資料表：
{ "Timestamp": "2022-08-19T20:15:00Z", "Sum": 41014457.0, "Unit": "Count" }, { "Timestamp": "2022-08-18T20:15:00Z", "Sum": 40048531.0, "Unit": "Count" },下列結果顯示在評估期間曾接收寫入流量的資料表：
{ "Timestamp": "2022-07-31T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 0.0, "Unit": "Count" },
清除未使用的資料表資源
如果找出未使用的資料表資源，您可以透過下列方式降低其持續產生的成本。
注意
如果找出未使用的資料表，但仍希望保留以備日後需要時可供存取，請考慮將其轉換為隨需模式。否則，您可以考慮備份和刪除整個資料表。
容量模式
DynamoDB 會對 DynamoDB 資料表中讀取、寫入及儲存資料等活動收取費用。
DynamoDB 有「隨需」和「佈建」兩種容量模式，分別提供適用於處理資料表讀取和寫入的特定計費選項。讀取/寫入容量模式可控制您變更讀取與寫入傳輸量以及管理容量的方式。
若為隨需模式資料表，不需要指定您預期應用程式將進行的讀取和寫入輸送量。DynamoDB 會將依據您的應用程式在資料表上執行的讀取與寫入請求單位，向您收取與寫入的費用。如果您的資料表/索引沒有任何活動，則不需要支付輸送量的費用，但仍會產生儲存費用。
資料表類別
DynamoDB 也提供兩種資料表類別，旨在協助您最佳化成本。預設值為 DynamoDB 標準資料表類別，建議大多數工作負載使用。DynamoDB 標準–不常存取 (DynamoDB 標準-IA) 資料表類別針對以儲存為主要成本的資料表進行最佳化。
如果您的資料表或索引沒有任何活動，儲存體可能成為主要成本來源，而變更資料表類別可大幅節省成本。
刪除資料表
如果您發現未使用的資料表並希望予以刪除，建議您先備份或匯出資料。
透過 Backup 取得的 AWS 備份可以利用冷儲存分層，進一步降低成本。如需透過 AWS Backup 啟用備份的資訊，請參閱 AWS Backup 搭配 DynamoDB 使用 文件，以及管理備份計劃文件，以取得如何使用生命週期將備份移至冷儲存體的資訊。
或者，您可以選擇將資料表的資料匯出到 S3。若要執行此操作，請參閱匯出至 Amazon S3 文件。資料匯出後，如果希望利用 S3 Glacier Instant Retrieval、S3 Glacier Flexile Retrieval 或 S3 Glacier Deep Archive 進一步降低成本, 請參閱管理儲存生命週期。
備份資料表之後，即可選擇透過 AWS Management Console 或 AWS Command Line Interface加以刪除。
識別未使用的 GSI 資源
識別未使用全域次要索引的步驟類似於識別未使用資料表的步驟。如果寫入基底資料表的項目包含用作 GSI 分割索引鍵的屬性，則 DynamoDB 會將這些項目複製到 GSI 中，因此在基底資料表處於使用狀態時，未使用的 GSI 仍可能具有大於 0 的 ConsumedWriteCapacityUnits。因此，您只需評估 ConsumedReadCapacityUnits 指標即可判斷 GSI 是否未使用。
若要透過 檢視 GSI 指標 AWS AWS CLI，您可以使用下列命令來評估資料表讀取：
aws cloudwatch get-metric-statistics --metric-name ConsumedReadCapacityUnits --start-time <start-time> --end-time <end- time> --period <period> --namespace AWS/DynamoDB --statistics Sum -- dimensions Name=TableName,Value=<table-name> Name=GlobalSecondaryIndexName,Value=<index-name>
為了避免將資料表誤認為未使用，建議您評估較長期間內的指標。選擇適當的開始時間和結束時間範圍 (例如 30 天) 及適當的期間 (例如 86400)。
在傳回的資料中，任何大於 0 的總和都表示您所評估的資料表在該期間內曾經接收讀取流量。
下列結果顯示 GSI 在評估期間內接收讀取流量：
{
"Timestamp": "2022-08-17T21:20:00Z",
"Sum": 36319167.0,
"Unit": "Count"
},
{
"Timestamp": "2022-08-11T21:20:00Z",
"Sum": 1869136.0,
"Unit": "Count"
},
下列結果顯示 GSI 在評估期間內接收最低讀取流量：
{
"Timestamp": "2022-08-28T21:20:00Z",
"Sum": 0.0,
"Unit": "Count"
},
{
"Timestamp": "2022-08-15T21:20:00Z",
"Sum": 2.0,
"Unit": "Count"
},
下列結果顯示 GSI 在評估期間未接收讀取流量：
{
"Timestamp": "2022-08-17T21:20:00Z",
"Sum": 0.0,
"Unit": "Count"
},
{
"Timestamp": "2022-08-11T21:20:00Z",
"Sum": 0.0,
"Unit": "Count"
},
清除未使用的 GSI 資源
如果找出未使用的 GSI，您可以選擇將其刪除。由於 GSI 中的所有資料也位於基底資料表中，因此在刪除 GSI 之前，不需進行額外的備份。如果日後再次需要 GSI，則可以將其重新加入資料表中。
如果找出不常使用的 GSI，則應考慮變更應用程式中的設計，以便將其刪除或降低其成本。例如，雖然應謹慎使用 DynamoDB 掃描，因為其可能消耗大量系統資源，但如果它們支援的存取模式很少使用，則可能比 GSI 更具成本效益。
此外，如果需要 GSI 來支援「不常存取」模式，請考慮投射一組限制程度較高的屬性。雖然這可能需要對基底資料表進行後續查詢以支援「不常存取」模式，但可能有助於大幅降低儲存和寫入成本。
清除未使用的全域資料表
Amazon DynamoDB 全域資料表提供全受管解決方案，用以部署多個區域和多個作用中資料庫，而不需要建置和維護您自己的複寫解決方案。
對於使用者近處的資料以及用於災難復原的次要區域，理想的做法是使用全域資料表來提供低延遲的存取管道。
如果針對特定資源啟用全域資料表選項，藉以提供低延遲的資料存取管道，但其並不屬於您災難復原策略的一部分，則請評估它們的 CloudWatch 指標，以確認兩個複本是否都主動提供讀取流量。如果其中一個複本不提供讀取流量，則可能就是未使用的資源。
如果全域資料表是災難復原策略的一部分，則在作用中/待命模式下可能會有一個複本未接收讀取流量。
清除未使用的備份或時間點復原 (PITR)
DynamoDB 提供兩種備份樣式。Point-in-time復原提供長達 35 天的連續備份，協助您防止意外寫入或刪除，而隨需備份允許建立快照，以便長期儲存。您可以將復原期間設定為 1 到 35 天之間的任何值。兩種類型的備份都會產生相關成本。
請參閱有關 DynamoDB 的備份和還原 和 DynamoDB 的 P oint-in-time 備份 的說明文件，以判斷您的資料表是否啟用了可能不再需要的備份。
