AWS 架構 Agent 預覽：哪些修正會自動執行？

AWS Well-Architected Agent 開放預覽，AI 產生的指令仍須自行審查與執行；既有 SSM 腳本另有自動化途徑。台灣團隊先看 Business+ 資格、美國設定檔位置與掃描權限。

發佈於： 2026-10-03 | 更新於： 2026-10-03

內容查核： 2026-10-03 來源查核： 2026-10-03

AWS 在 10 月 1 日開放 Well-Architected Agent 公開預覽，讓 AI 依業務目標排列雲端架構的修正建議。對台灣維運團隊，最先要看懂的是執行權限：AI 寫出的修正指令不會由 Agent 代為執行；Trusted Advisor 搭配的既有 SSM 腳本，則可經同意執行。 兩者混在一起，就可能把一份待審查的建議誤當成已核准的變更。

我的判斷是，這項服務值得用來減少架構問題的整理工作；不建議因為畫面寫著「可直接實作」，就把產生的程式碼送進正式環境。 它能提出方案，是否符合公司服務承諾、變更窗口與回復方式，仍要由團隊決定。

自動修正有兩條路，先看建議從哪裡來

新服務會把資源設定、使用情形與應用程式關係放在一起，依成本、安全、效能、韌性等目標排序。價值在於讓團隊看見取捨，而非只追最低帳單。例如增加備援可能改善可靠性，同時增加支出；「優化」並不等於所有面向一起變好。

官方修正文件把執行方式分成兩類：

建議與修正來源	誰負責執行
Trusted Advisor 檢查搭配既有 SSM Runbook 自動化腳本	經使用者同意，可直接執行或排程；仍須確認腳本與目標資源
AI 產生的資源、應用程式或架構修正	提供指令、操作說明或基礎設施程式碼，由團隊審查、測試並執行

不能拿既有腳本的執行能力，替 AI 寫出的步驟背書；也不能因為 AI 步驟只供參考，就認定這項服務完全沒有改系統的途徑。

官方也提供部署前的架構審查，分析基礎設施程式碼並回傳修改方案。這類審查要主動啟動，建立設定檔不代表即將部署的版本都已檢查。產生的修改應送回團隊既有的程式碼審查流程；企業 AI 程式代理評估方法也能協助判斷變更是否可接受。

對維運主管，我會要求變更單寫清楚目標資源、原因、核准人與回復方式。官方允許下載完整修正程序，附進變更單供其他人檢查，比只留建議畫面更有用。權限與核准責任可接到既有的企業 AI Agent 上線檢查。

台灣團隊先確認支援等級與掃描範圍

公告寫「有 AWS Support 方案」可使用，但 10 月 1 日的官方版本紀錄列出的資格是 Business+、Enterprise On-Ramp、Enterprise Support 或 Unified Operations。入門文件明確排除 Developer 與 Business。Business 和 Business+ 不同，先請帳務或雲端管理人員確認。

設定檔目前可放在美國維吉尼亞北部、俄亥俄或奧勒岡，資源掃描則涵蓋所有商用區域。可掃描其他區域，不代表資料全程留在原區域；公司若有資料位置要求，應在接入前確認。

IAM 存取模型採客戶管理的角色，透過角色串接讀取各目標帳號的資源資訊。這裡的唯讀權限指的是探索與分析，不代表後續執行 SSM 腳本也沒有變更效果。角色信任對象、資源範圍與撤回方式要一起看；更完整的權限設計可參考 AI Agent 安全工程。

還有一個容易影響判讀的前提：入門文件要求提供應用程式背景，缺少時不會產生排程建議；未啟用 Cost Explorer，成本估算則來自公開價格。不要把這種估算直接當成公司實際帳單。啟用更細的成本資料也可能產生費用，應讓管理人員核對設定，再決定是否值得。

常見問題

Well-Architected Agent 會自動執行 AI 產生的修正嗎？

不會。AI 產生的步驟供團隊審查、測試與執行。由既有 Trusted Advisor 檢查搭配的 SSM Runbook 則可經同意執行或排程，不能把兩類修正混為一談。

有 AWS Business 支援方案就能使用嗎？

官方文件排除 Developer 與 Business，要求 Business+ 或列出的更高等級方案。應確認帳號的實際支援等級，不要只憑公告的簡稱判斷。

完成架構審查就代表可以直接部署或通過合規嗎？

不代表。AI 建議可能有錯誤或資訊不完整，正式部署仍須依團隊的變更審查與驗證流程處理；這次預覽不是台灣法規或公司政策的合規認證。

參考來源

№ · further reading