上一篇透過 AWS DMS，實際將自建 PostgreSQL 的資料搬到 RDS，並持續同步後續變更。
實作完成後，除了確認資料是否正確，也別忘了另一件事：這些資源還需要繼續保留嗎？
這也是成本最佳化最直接的起點。
系列的最後一天，先簡單看看 AWS 成本可以從哪裡調整，再回顧這 30 天希望留下的架構思考方式！
看到帳單增加，不一定要立刻縮小主機，或購買長期折扣。
可以先使用 AWS Cost Explorer，查看不同服務、Region 與時間區間的費用，找出主要支出與變化。
例如：
另外可以透過 AWS Budgets 設定預算，在實際費用或預估費用超過門檻時收到通知。
不過 只設定預算通知，不會讓 AWS 到達金額上限就自動停止所有資源，費用資料與通知也可能有延遲。
AWS 提供多種折扣方案，但在購買前，應先確認目前的資源是否真的需要這麼多。
成本最佳化可以依照以下順序進行：
| 順序 | 要確認的問題 | 可以採取的方式 |
|---|---|---|
| 1. 清理不再需要的資源 | 這個資源還有人使用嗎？ | 刪除已完成實驗的資源，以及確認不再需要的磁碟與快照 |
| 2. 調整規格與執行時間 | 是否配置過大，或不需要全天運行？ | 依監控結果調整規格，讓測試環境只在需要時啟動 |
| 3. 評估長期折扣 | 哪些資源未來會持續使用？ | 再評估 Savings Plans 等承諾用量方案 |
例如 Day 29 使用的 DMS，只是為了完成短期遷移實驗，結束後就應清理相關資源，避免持續產生費用。
如果是長期運行的訂單 API，則可以先觀察 CPU、記憶體與尖峰時段的負載，確認目前的規格是否合適，再透過 AWS Cost Explorer（成本分析工具） 查看歷史用量，評估是否適合購買折扣方案。
AWS 常見的長期折扣方案有兩種：
以訂單系統為例：
要注意的是，這些方案都有長期承諾，即使後來刪除資源或減少使用量，也不會自動取消原本的付款承諾。
因此應先清理不需要的資源、調整適合的規格，再根據剩下的穩定用量評估折扣，避免為用不到的承諾用量持續付費。
這個系列從權限、網路、儲存與資料庫，一路談到運算、訊息傳遞、部署、監控、安全與搬遷。
每個主題都會遇到不同的 AWS 服務，但做決定時，可以反覆問同樣幾個問題：
現在要解決什麼問題？
是圖片載入太慢、資料庫維運負擔太重，還是部署失敗後無法退版？
有哪些限制不能忽略？
包含預算、期限、可接受的停機時間，以及團隊能承擔的維運工作。
這個選擇帶來什麼好處，又需要付出什麼？
例如選擇 RDS，可以減少資料庫安裝、修補與備份等維運工作，但需要支付託管服務的費用，也會受到平台支援功能的限制。
要怎麼確認它真的有效？
可以透過效能測試、還原演練、部署驗證，或像 Day 29 一樣，實際核對同步後的資料。
將這些判斷與驗證結果記錄下來，未來需求改變時，團隊就能回頭確認當初的設計依據，重新評估哪些選擇需要調整。
大家好！終於來到第 30 天了（x），感謝一路閱讀這個系列的大家～
這個系列的起點，其實是平常的工作經歷，以及當初準備 AWS SAP 時整理的筆記，那時候查了很多資料，也翻了不少官方文件，剛好碰上鐵人賽，就想說不然把筆記和自己的經驗整理成文章，也當作給自己一次統整和複習的機會，於是這個系列就誕生了～
過程中一直很擔心連假過得太開心，不小心就斷賽QQ，不過雖然好幾次都壓著死線，晚上 11 點多才發文，但總算有驚無險地完成了（？
這次鐵人賽就在這裡告一段落，謝謝大家，下次見啦！
iThome鐵人賽
看影片追技術