使用由Amazon Bedrock支援的AI代理構建自助式AWS健康分析，以發現可操作的健康洞察

在典型的週一早晨，企業運營團隊會收到多個AWS Health通知，涉及Amazon Linux 2生命週期結束、RDS版本棄用以及EC2例項退役等，這些通知遍佈50多個賬戶。如果沒有自助式分析，團隊無法快速識別影響生產系統的事件、需要立即行動與長期規劃的事件，以及每個事件類別對業務的影響。運營團隊還花費時間等待技術客戶經理（TAM）解釋健康事件，這增加了關鍵運營決策的延遲。結果是團隊將時間花在被動救火上，而非創新上。

本文展示瞭如何構建Chaplin（Customer Health and Planned Lifecycle Intelligence Nexus），這是一個開源解決方案，利用透過模型上下文協議（MCP）暴露的AI代理，提供自助式健康事件分析。藉助Chaplin，團隊可以直接從MCP相容的AI助手中用自然語言提問，並獲得精確、上下文化的答案，無需依賴AWS支援進行常規分析。詳細的部署說明可在Chaplin AWS Health Agentic Assistant GitHub倉庫中找到。

挑戰：被動的健康事件管理

在AWS上執行生產工作負載的企業管理著持續不斷的健康事件流——服務變更、維護視窗、安全補丁和運營通知——這些事件遍佈數十或數百個賬戶。AWS Health透過AWS Health API和Amazon EventBridge提供全面的健康事件資料，但被動管理方法存在差距。團隊依賴TAM進行健康事件解釋和影響分析，這造成了決策瓶頸。具有預定義模式的商業智慧儀表板無法適應動態問題，也無法提供運營團隊在當下所需的上下文洞察。

DevOps和雲運營團隊花費大量時間手動分類和優先處理散佈在多個賬戶和區域中的數千個健康事件。沒有集中分析位置，就很難評估整體影響、協調跨團隊響應或識別主動機會——例如在問題變得關鍵之前計劃遷移或安排維護。

符合條件的健康事件很快將直接連結到AWS Transform模板，使客戶能夠直接對事件採取行動。Chaplin可以為您的環境展示這些可操作事件並確定其優先順序。

解決方案概述：使用Chaplin的自助式分析

Chaplin透過使用Amazon Bedrock支援的代理AI實現自助式健康事件分析，並透過模型上下文協議（MCP）交付。Chaplin不採用預定義的儀表板模式，而是暴露AI驅動的工具，MCP相容的客戶端可以消費這些工具。團隊直接從其AI助手（如Claude Code或Kiro CLI）與Chaplin互動，並用自然語言提問。例如，團隊成員可以詢問未來60天內即將發生的RDS生命週期事件、按緊急程度優先排序的開放EC2事件摘要、影響生產環境的安全補丁，或者查詢可能影響高優先順序應用程式的維護視窗。

您的團隊可以繼續查詢，直到獲得做出明智決策和制定補救計劃所需的所有資訊。這種方法使DevOps、安全和運營團隊能夠獨立分析健康事件、計劃遷移和評估運營影響，而不會造成瓶頸。由於Chaplin使用MCP，團隊還可以將其工作流中的其他MCP啟用工具（如JIRA、GitHub或ServiceNow）結合起來，透過代理體驗執行操作。

此外，MCP支援將AWS資料和後設資料與業務或應用程式級上下文（如資源標籤、環境分類和所有權資訊）直接關聯，從而豐富了健康事件分析與組織相關性。

代理AI如何統一結構化和非結構化資料

Chaplin使用多代理架構，解決了企業資料分析中的一個基本挑戰：有效結合結構化和非結構化資料處理。傳統的檢索增強生成（RAG）系統和生成式AI方法面臨一個關鍵限制：在處理數值操作和聚合時本質上是不確定的。向量相似性搜尋是RAG的基礎，它檢索語義相似的內容，但不能保證數學準確性。當被要求計數、求和或聚合資料時，基於RAG的系統可能會產生幻覺（例如，報告190個與生命週期結束相關的健康事件，而實際數量是958）。這種不確定性源於檢索機制（根據語義相似性而非精確匹配對文件進行排序）和語言模型生成過程（預測可能的標記而非計算精確值）的機率性。

AWS健康事件正是現了這個挑戰。每個事件包含結構化後設資料——事件型別、服務名稱、受影響資源、時間戳、嚴重性級別和賬戶ID——需要精確過濾和聚合。每個事件還包含非結構化描述，包括自然語言解釋問題、影響評估和推薦行動，需要語義理解和上下文分析。

智慧查詢處理

當您向Chaplin提問時，三個專門的元件協同工作。自然語言到結構化查詢代理將純英語問題轉換為針對健康事件後設資料的精確結構化資料查詢。它理解健康事件的模式——存在哪些欄位，例如事件型別、受影響賬戶和開始時間——並構建與您的意圖匹配的過濾器。像“顯示生產賬戶中的EC2退役”這樣的問題會變成具有精確欄位過濾器的結構化查詢，而不是關鍵字匹配。

上下文影響分析代理透過將非結構化健康事件描述與您的客戶後設資料（生產與非生產環境、業務單元、應用程式層級和所有權資訊）相結合來處理這些描述。該代理執行系統級推理，不僅解釋事件內容，還解釋事件對您的特定基礎設施和組織背景意味著什麼。

基於模式的分類引擎使用基於規則的模式匹配對健康事件進行分類，從而消除了常規分類的AI處理成本，同時保持了高準確性。這一成本最佳化層使得該解決方案在實踐中具有可擴充套件性。

成本最佳化的AI架構

Chaplin透過選擇性AI增強實現了智慧成本最佳化。該系統採用模式優先的處理方法，其中基於規則的分類無需產生AI成本就能處理大多數事件。帶有過濾器的30天、60天和120天預構建彙總檢視幫助團隊快速識別關鍵警報。在當前實現中，Amazon Bedrock與Claude僅處理需要上下文分析的非結構化資料。但該解決方案也是LLM無關的，支援多種模型提供商，如Amazon Bedrock、OpenAI、Anthropic或本地模型如Ollama，根據您的需求和成本約束提供靈活性。智慧快取減少了重複的AI處理，結構化查詢精確性使用AWS Health API模式進行精確數值分析，無需AI推理成本。

架構概述

下圖展示了完整的Chaplin架構。它顯示了健康事件如何從多個AWS賬戶透過集中資料管道流入基於Amazon Bedrock的AI代理構建的MCP伺服器，最終到達MCP相容的AI助手，團隊透過自然語言與資料進行互動。每個層在圖表後都有詳細描述。

架構由三個主要層組成，協同工作以提供智慧健康事件分析。

1. 資料層——收集層（多賬戶）

資料層從整個AWS組織收集健康事件並集中進行分析。在每個成員賬戶中，AWS Health API作為健康事件的來源。Amazon EventBridge提供事件驅動的觸發器進行即時捕獲，AWS Lambda收集器函式使用配置了最低許可權的跨賬戶IAM角色檢索事件。

這些事件流向集中管理賬戶，其中Amazon Simple Storage Service (Amazon S3) 資料湖儲存收集的健康事件，並按賬戶、日期和事件型別進行智慧分割槽。當新事件到達時，S3事件通知觸發一個AWS Lambda函式，該函式處理JSON健康事件並將其載入到Amazon DynamoDB中以便快速查詢。

這種多賬戶架構支援兩種部署模型：

選項1：使用AWS Organizations API進行集中式自動化部署。

選項2：針對具有安全限制的組織進行單個賬戶部署。

1. 中間層——MCP伺服器和智慧層

中間層是原始健康事件資料轉化為可操作情報並透過MCP伺服器暴露的地方。Amazon DynamoDB作為結構化健康事件後設資料的主要資料儲存，透過事件型別、嚴重性、日期和賬戶的索引最佳化了快速查詢。這實現了對模式分類和AI分析的即時訪問。

基於模式的事件分類器提供第一層智慧。這個基於規則的分類引擎在事件型別上使用正規表示式模式，將事件對映到五個業務類別：遷移需求、安全與合規、維護與更新、成本影響事件和運營通知。由於大多數事件遵循可預測的模式，這種方法透過高效的模式匹配處理大多數事件，而不會產生AI成本。

對於需要更深入分析的事件，基於Amazon Bedrock構建的AI驅動分析引擎接管。該引擎使用Strands Agents框架，這是AWS開發的開源代理框架，以Claude 4.5 Sonnet作為大語言模型。您可以將其切換到首選的LLM。三個專門的代理處理不同方面的分析：SQL查詢代理將自然語言查詢轉換為結構化的DynamoDB查詢以進行精確數值分析，影響分析代理根據客戶後設資料（如環境、業務單元和所有權）評估非結構化事件描述，而DBQueryBuilder代理為多維聚合生成最佳化的資料庫查詢。所有這些能力都被暴露為MCP工具，相容的客戶端可以呼叫。

1. 展示層——MCP客戶端——AI助手整合

展示層由相容MCP的AI助手組成，如Claude Code或Kiro CLI。Chaplin不提供自定義前端，而是將其能力作為MCP工具暴露出來，這些客戶端可以原生地使用這些工具。使用者透過自然語言在其現有開發環境中互動，AI助手協調對Chaplin的MCP伺服器的呼叫，以檢索健康事件資料、執行AI驅動分析並呈現上下文結果——所有這些都在它們已經用於開發任務的同一對話介面中完成。

安全性依賴於AWS Identity and Access Management (AWS IAM) 進行身份驗證和授權。MCP客戶端以只讀方式掛載AWS憑證，並透過遵循最小許可權原則的IAM角色控制訪問。