2025 AWS re:Invent 分享

在2025 AWS re:Invent 活動中看到一些有趣的介紹，在此與大家分享。

Sysco 在平台工程（Platform Engineering）上，面臨以下三大維運難題：

1. 複雜度超載
2. 成本與基礎架構管理
3. 資安（Cybersecurity）

所謂「複雜度超載」，指的是：系統過於複雜，工程師必須時時刻刻查閱大量知識與文件，腦袋一直被塞滿資訊的狀態。成本與基礎架構管理指的是：版本更新與人力監控。資安則是泛指所有可能的系統漏洞偵測與修補。

為了處理這些運維課題，他們導入了 AWS AI 的解決方案：

• Amazon Q Developer + MCP 伺服器（搭配 Rules 設計）
• 導入 Amazon CodeWhisperer

藉此，大幅提升了開發效率、治理（Governance）、標準化與資安。

以下整理出導入AWS AI 的解決方案的三大重點。

重點一：用 MCP 伺服器大幅減少「找資料」的時間成本

透過 MCP（Model Context Protocol）：

• 將 AWS CLI
• 內部文件
• 標準作業流程（SOP）
• 計費 API
• 設計文件

等資源，全部整合成一個「AI 可以存取的資訊中樞（Hub）」。

利用 MCP，可以明確指定 AI 可以參照的資源範圍，因此可以避免 AI 去查到不該看的、不必要的資訊，這是很大的進步。關於 MCP 伺服器的詳細機制，則建議參考官方文件。

對於改善「複雜度超載」非常有幫助。

在此之前，工程師必須長期面對大量的：

• 文件
• API
• SDK
• 程式碼
• 各種維運相關資訊

也就是說，需要持續腦中裝著一整套龐大的知識庫。

例子包括：

• 超過 400 位開發者，共同面對複雜的技術堆疊
• 多種資料庫並存，例如 NoSQL / MongoDB
• 包含 Service Mesh 在內的複雜網路拓樸
• 混合環境（雲端 + 機房資料中心）

透過 MCP 伺服器把這些龐大的輸入資訊集中起來，就可以把「找資料」這件事整個交給 MCP 去處理。

重點二：依角色打造客製化 Agent，最佳化日常維運

為了最佳化日常維運，有一個導入範例是:「專門用來處理 EKS 問題排除（Troubleshooting）的 Agent」。

作法是：

• 將前面提到的 MCP 伺服器，
  設定成可以提供 EKS 特有的知識庫（維運手冊、內部文件等）給 Agent 參照
• 在 Tools 設定中，讓 Agent 能夠使用 Git、AWS CLI、MCP 伺服器
• 同時為 Agent 定義清楚的角色說明（Role）、具體的 Prompt 指示等等

這個作法同樣對降低「複雜度超載」非常有幫助。原先在維運上，EKS（以及 ArgoCD）本身的複雜度就是一大負擔，但透過導入 Agent，有效緩解了這些維運壓力。我個人感覺是：在實務現場，如果能把不是暫時性、而是長期且規則相對穩定的業務與維運流程 Agent 化，應該可以得到更高的效果與投資報酬（ROI）。

重點三：把運維標準用 Rules 程式碼化，強制落實到 Agent

第三個重點是為了確保客製 Agent 的品質，可以把 Agent 和 Rules 檔案串在一起， 讓 Agent 必須永遠遵守特定規則。

具體作法是：

• 使用 Rule markdown 檔案，將各種規則「程式碼化」
• 若要把實際的標準（Standards）、設計文件等導入給 Agent 使用，
  就會先將這些文件透過 MCP 伺服器掛載起來， 再在 Rule 中寫明「必須以這些文件為準」

「Rules」本身就是一種會直接影響 AI 生成程式碼與判斷結果的設計，因此可以成為強制維持以下項目的機制：

• 資安（Security）
• 監控（Monitoring）
• 基礎架構標準（Infrastructure Standards）

當我們真的開始把重要的運維工作交給 Agent，並且想要讓它在實務上長期運作時， 「如何透過 Rules 把品質做標準化與一致化」 就會變成非常關鍵的設計要素。

總結

這次介紹Sysco如何利用 Amazon 服務來推動維運改革的案例，整體看完今年 re:Invent 的內容，我的感想是：「把 Agent 實際導入維運現場」的案例明顯變多了。但相較之下，在台灣真正已經導入到日常實務運用的企業好像還沒有那麼多，所以這次的分享對我而言非常有參考價值。