S3 儲存成本最佳化實戰：從計費維度拆解到 7 個可落地手段

很多團隊看 S3 帳單時只盯著「存了多少 TB」，但真正的 S3 成本通常由四類費用疊加：儲存容量、請求次數、資料傳輸、管理功能。最佳化也應該從這四個維度拆開看，而不是簡單地把所有 bucket 都遷到更冷的儲存類別。

以下價格以 us-east-1 為例，實際以 AWS 當區價格為準：S3 Standard 前 50TB 大約是 $0.023/GB-month；Standard-IA 大約 $0.0125/GB-month；Glacier Instant Retrieval 大約 $0.004/GB-month；Glacier Deep Archive 大約 $0.00099/GB-month。看起來 Deep Archive 便宜很多，但它有最低儲存時長、取回時間和取回費用，不能盲目遷。

1. 先分清帳單來源

建議先在 Cost Explorer 裡按 Usage type 拆開：

• TimedStorage-ByteHrs：物件儲存容量。
• Requests-Tier1/Tier2：PUT、LIST、GET 等請求。
• DataTransfer-Out-Bytes：公網或跨區域傳輸。
• Monitoring-Automation、Inventory、StorageLens：管理與分析功能。

一個常見誤區是：儲存費不高，但 LIST/GET 請求很多，或者私有子網路存取 S3 走了 NAT Gateway，導致網路帳單上漲。S3 最佳化不要只看 bucket size。

2. Intelligent-Tiering 與生命週期規則

如果物件存取模式不穩定，S3 Intelligent-Tiering 是低風險起點。它會在 Frequent、Infrequent、Archive Instant 等層之間自動移動物件，自動層之間沒有取回費，但會收取監控與自動化費用，典型價格是 $0.0025/1,000 objects-month。如果物件很小、數量巨大，這筆管理費可能不劃算。

生命週期規則適合存取模式明確的資料，例如日誌、備份、訓練樣本：

{
  "Rules": [
    {
      "ID": "logs-to-glacier",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER_IR" },
        { "Days": 180, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 730 }
    }
  ]
}

注意最低儲存時長：Standard-IA 通常 30 天，Glacier Instant Retrieval / Flexible Retrieval 通常 90 天，Deep Archive 通常 180 天。短生命週期物件不適合過早轉冷。

3. Glacier IR 與 Deep Archive：只給”真的冷”的資料

Glacier Instant Retrieval 適合「低頻但要毫秒級讀取」的封存，例如合規查詢、歷史報表。Deep Archive 適合幾乎不會讀取、可以等待數小時還原的資料，例如多年備份。

判斷標準可以很簡單：如果一個物件 6 個月內極大機率不會讀，Deep Archive 才值得評估；如果業務端無法接受還原等待，就不要為了帳單好看硬遷。

4. 清理舊版本與未完成 Multipart Upload

開啟 Versioning 後，刪除物件只會產生 delete marker，舊版本仍在計費。很多 bucket 的「幽靈成本」來自歷史版本。

可以先查看版本：

aws s3api list-object-versions --bucket my-bucket --prefix app/

再用生命週期清理非目前版本：

{
  "Rules": [
    {
      "ID": "expire-old-versions",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

AbortIncompleteMultipartUpload 很容易被忽略。大檔案上傳失敗後，分段可能長期留在 S3 裡繼續計費。

5. 請求最佳化：LIST 比你想像中貴

在 S3 Standard 中，PUT/COPY/POST/LIST 這類請求常見價格約 $0.005/1,000 requests，GET 常見約 $0.0004/1,000 requests。單價看起來低，但物件數量上億時，掃描式 LIST 會很貴，也會拖慢系統。

實務建議：

• 避免用 ListObjectsV2 當作資料庫查詢。
• 物件 key 設計加入日期、租戶、業務前綴，減少無意義掃描。
• 用 S3 Inventory 替代全量 LIST。
• 對熱點小物件做合併或快取，減少 GET 風暴。

6. 用 VPC Endpoint 避免 NAT Gateway 繞路

私有子網路裡的 EC2、ECS、Lambda 存取 S3，如果路由走 NAT Gateway，會產生 NAT 資料處理費。us-east-1 常見 NAT Gateway 價格是約 $0.045/hour 加 $0.045/GB processed，1TB/月光是 NAT 處理費就約 $45。

存取 S3 和 DynamoDB 時，優先設定 Gateway VPC Endpoint：

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxx \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-xxxx \
  --vpc-endpoint-type Gateway

Gateway Endpoint 本身通常不收小時費，也能減少經由 NAT 的流量。修改後要檢查 route table，確認 S3 prefix list 指向 endpoint。

7. 壓縮：應用程式端壓縮 vs 透明閘道器

壓縮是最直接的容量最佳化，但要看資料類型。Parquet、ORC、gzip 後的日誌、圖片、影片通常已經壓縮，效益有限；JSON、CSV、文字日誌、未壓縮物件、部分備份檔案，可能有明顯效益。

應用程式端壓縮的優點是架構簡單、沒有額外閘道器；缺點是需要修改程式碼、處理相容性、遷移歷史資料。另一種方式是透明壓縮閘道器：讓應用程式仍然使用 S3 API，把用戶端指向閘道器，由閘道器負責壓縮後寫入 S3。

S4（Squished S3） 就屬於後者。它是包含 NVIDIA nvCOMP GPU codec 的 EC2 AMI，執行在 g4dn/g5/g6 等 GPU 執行個體上；S3 用戶端指向透明閘道器後，對可壓縮資料通常可以減少 50% 到 80% 的 S3 儲存位元組，應用程式無需修改程式碼。它不是所有場景都合適：如果資料已經壓縮、物件很小、請求極高但容量不大，效益可能不明顯。適合評估的場景是：S3 中有大量文字/半結構化資料，容量成本是主要問題，同時不想修改應用程式。

可以先用 S4 成本試算工具 做粗估；它不要求上傳自己的帳單 CSV，也可以用範例資料試試看。

最後：先測量，再改策略

推薦落地順序：

1. 用 Cost Explorer 找到 S3 的主要 usage type。
2. 用 S3 Storage Lens 看 bucket、prefix、版本、物件大小分佈。
3. 先清理版本和未完成 multipart。
4. 再做生命週期、Endpoint、請求最佳化。
5. 最後評估壓縮或替代架構。

S3 降低成本不是「全部轉冷」這麼簡單。真正有效的做法，是把資料存取模式、物件大小、請求路徑和保留週期放在一起看。

利益揭露：本文作者來自 abyo software（AWS Marketplace 上的成本最佳化產品 S4 的開發方）。