如何設定 DynamoDB 自動擴展

DynamoDB 自動擴展會把一張佈建表格的讀取與寫入容量，朝著你選定的目標使用率調整，好讓你不必再手動調校 RCU／WCU，也不必全天候為一份最壞情況的預留付費。這份指南是容量這個主題動手實作的那一半：主控台路徑、 CLI 指令、實際上要怎麼挑數字，以及仍然會節流急遽尖峰的時間限制。如果你還沒選好容量模式，先從隨需對佈建開始——自動擴展只適用於佈建。

我要如何在 DynamoDB 表格上啟用自動擴展？

在主控台中：開啟你的表格，前往其他設定 → 讀取／寫入容量 → 編輯，選擇佈建，然後為讀取容量、寫入容量或兩者把自動擴展 設為開啟，並各自給定一個最小值、最大值與目標使用率（可設定在 20% 到 90% 之間）。從 CLI 則是用 aws application-autoscaling 註冊一個可擴展目標，再掛上一個目標追蹤擴展政策。透過主控台建立的表格預設就啟用了自動擴展。

自動擴展實際上做了什麼

一個擴展政策告訴 Application Auto Scaling 把一張表格已消耗對已佈建的比例，維持在你的目標使用率附近，並落在你設定的最小與最大容量界限之內。在底層，它會為上界與下界建立一對 CloudWatch 警報；當消耗量越過其中一個時，Application Auto Scaling 就會發出一次 UpdateTable 呼叫來調動佈建容量。

在設定之前，有兩個結構性的事實很重要：

政策是分表格_而且_分 GSI 的。 每個全域次要索引都有它自己的佈建輸送量，所以每一個都需要它自己的政策（或是主控台那個「對所有 GSI 套用相同設定」的核取方塊）。一個擴展不足的 GSI 會節流基礎表格寫入 ——見為什麼 GSI 會節流基礎表格。
主控台建立的表格預設加入；之後才加的 GSI 在建立期間不會擴展。 一個加到既有表格上的新 GSI，在它回填期間是從手動容量開始的——盯著它，直到政策掛上為止。

你要承擔的反應時間

自動擴展是反應式的，而它的反應時間是固定的——AWS 記載了警報的資料點數量是不可調整的：

擴增在消耗容量連續兩分鐘突破目標之後觸發（再加上最多幾分鐘的 CloudWatch 警報延遲）。
縮減要等到連續 15 個一分鐘資料點都低於目標。
在任一個觸發之後，那次 UpdateTable 呼叫要花上幾分鐘才會生效—— 而在這段期間，超過_舊_上限的請求都會被節流。

那段從突破到拿到新容量的約 5 分鐘底線，就是這項功能誠實的極限：自動擴展吸收的是_成長_的流量，而不是_跳階_的流量。一場在一分鐘內把負載變成三倍的限時搶購，不論你的政策怎麼設，在佈建容量上都會節流；那種形狀要的是隨需，它能即時容納到你先前峰值的兩倍（而在 30 分鐘內超過兩倍就會節流——它自己那一版的同一套物理定律）。

主控台設定

對一張既有的表格（AWS 的步驟）：

DynamoDB 主控台 → 表格 → 選擇那張表格。
其他設定分頁 → 讀取／寫入容量 → 編輯。
容量模式：佈建。
在表格容量底下，為讀取、寫入或兩者把自動擴展切到開啟，然後各自設定最小容量單位、最大容量單位與目標使用率。
可選擇把相同設定套用到每一個 GSI，然後按儲存。

有一個主控台限制值得知道：冷卻時間在那裡沒有被暴露出來。AWS 自己的文件會把你指向 CLI，「若要使用像是設定縮減與擴增冷卻時間這類更進階的功能」。

CLI 設定

每個維度兩次呼叫：先註冊可擴展目標（最小／最大界限），再掛上目標追蹤政策。以下逐字取自 AWS 的 CLI 逐步說明，針對一張表格的寫入容量：

aws application-autoscaling register-scalable-target \
    --service-namespace dynamodb \
    --resource-id "table/TestTable" \
    --scalable-dimension "dynamodb:table:WriteCapacityUnits" \
    --min-capacity 5 \
    --max-capacity 10

政策設定放在一個 JSON 檔案裡：

{
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "DynamoDBWriteCapacityUtilization"
  },
  "ScaleOutCooldown": 60,
  "ScaleInCooldown": 60,
  "TargetValue": 50.0
}

aws application-autoscaling put-scaling-policy \
    --service-namespace dynamodb \
    --resource-id "table/TestTable" \
    --scalable-dimension "dynamodb:table:WriteCapacityUnits" \
    --policy-name "MyScalingPolicy" \
    --policy-type "TargetTrackingScaling" \
    --target-tracking-scaling-policy-configuration file://scaling-policy.json

對讀取，把維度換成 dynamodb:table:ReadCapacityUnits，指標換成 DynamoDBReadCapacityUtilization。對一個 GSI，資源 id 會變成 table/TestTable/index/test-index，並搭配 dynamodb:index:* 那組維度。因此一張有三個 GSI、兩個維度都要擴展的表格，就需要八組目標／政策配對 ——寫個腳本吧。

那兩個冷卻時間對 DynamoDB 而言預設為 0，而且是只有 CLI 才有的旋鈕：ScaleOutCooldown 是兩次容量增加之間的最小秒數（幅度更大的一次擴增仍會立刻通過），而 ScaleInCooldown 會擋住下一次減少——不過一次擴增會打斷正在進行的縮減冷卻，而不是等它結束。

挑選數字

目標使用率是一個餘裕對成本的旋鈕。在目標為 T 百分比時，你付的大約是你消耗容量的 100/T 倍：70% 的目標買到高於穩定流量約 1.4 倍的餘裕，50% 的目標買到 2 倍。較低的目標能撐過更急遽的成長而不節流；較高的目標則浪費較少預留。範圍是 20–90%。

這個旋鈕直接連到帳單。以目前 us-east-1 的費率來看（推導方式與 DynamoDB 能自動擴展嗎？相同）：佈建容量在 100% 使用率下，每個請求比隨需便宜約 3.46 倍，而損益兩平點落在約 29% 使用率。自動擴展的工作就是把真實使用率維持在你的目標附近，所以那個目標實際上就是在選你的折扣：維持在 70%，佈建比隨需便宜約 2.4 倍；在 50% 時約 1.7 倍；低於約 29%，你就應該改用隨需。在定價計算器裡查你自己工作負載的數字。

最小容量是你的尖峰地板：它是在自動擴展需要反應的那約 5 分鐘裡 _已經在那裡_的容量。要依你必須不節流地吸收的最急遽突發來設定它，而不是依平均流量。

最大容量是暴走保護——是一個 bug、一個發燙的 Lambda 迴圈或一次負載測試能對你計費的上限。把它設在你實際的峰值之上，並把碰到它當成一個警訊，而不是正常運作。

縮減受配額限制。 佈建的減少來自一個權杖桶：你在每個 UTC 日開始時有 4 次可用，每小時再累積一次（最多持有 4 次），每張表格每天最多 27 次減少——GSI 的限制是分開的，但一個同時減少表格與索引的單一請求，只要任一邊配額不足就會整個被拒。自動擴展那保守的 15 分鐘縮減在實務上已經尊重了這一點，但這正是為什麼容量在一次尖峰之後會緩慢地一格一格降下來 ——也是為什麼震盪的流量會在一天結束時被釘在高於它平均值的位置。

在 DynoTable 中做這件事

為最小值定尺寸、以及驗證目標，兩者都從真實的數字開始，而不是從猜測開始：項目有多大、有多少筆，以及一次具代表性的讀取或寫入實際消耗多少。 DynoTable 的表格檢視會呈現即時的項目數與表格大小，而它的查詢成本預覽會在一段陳述式跑之前顯示它的 RCU 估計值——正是一份容量規劃所用的那些數字。要為單一個項目定尺寸，免費的項目大小計算器會算出它的 RCU／WCU 佔用量。

陷阱與後續步驟

自動擴展贏不了每分割區的物理定律。 一個熱鍵即使容量還有餘裕也會節流——見熱分割區與自適應容量。
別忘了 GSI。 每個索引各自擴展（或各自節流）。
預留容量只疊在佈建之上。 如果一個工作負載穩定到自動擴展幾乎不動，預留容量（Standard 表格類別、僅限佈建模式）就是下一個折扣 ——隨需表格用不了它。
盯著第一天。 在 CloudWatch 中拿 ConsumedReadCapacityUnits／ ConsumedWriteCapacityUnits 對照佈建的那條線，很快就能告訴你目標是守住了還是在震盪。

容量是成本模型的一個軸；你的查詢_消耗_多少則是另一個—— Scan 對 Query與 SQL 掃描成本模型涵蓋了那一半。

下載 DynoTable 在你把容量數字定到表格上之前，先讀出它真實的大小、項目數與每次查詢的成本。