北京
晚上十一點，你讓 AI 搭檔幫你寫一段基礎設施代碼。它自信地給出一個 AWS 服務名，編了個 ARN，指了一個你根本沒用的區(qū)域，還“貼心”地補上 DynamoDB 表名和一套完整的部署步驟。你心想：這玩意兒還真沒聽說過，去翻翻文檔——結果發(fā)現(xiàn)全是幻覺。AI 編造了一個不存在的 Lambda 調用、一套不存在的資源，還一臉真誠地問你“要不要看看你賬戶當前配置來核實命名”。
你當然想讓它看到真實環(huán)境。于是你做了大多數(shù)人都干過的事：把一條訪問密鑰貼進 .env 文件，讓 AI“就看一眼”真實的資源名。代碼跑通了，問題解決了，只是——你忘了刪掉那個 .env。一次不小心的提交，密鑰進了 Git 歷史，告警炸鍋，風險四伏。更要命的是，這個獲得了真實權限的 AI 助手，可能在某一刻過于積極，刪錯了 CloudFormation 堆棧，或者一天之內悄悄燒掉四十美元賬單，甚至更多。
AWS 顯然看到了這個痛點，也給出了解決方案——而且一給就是兩個，名字還極其相似：Knowledge MCP 和 managed AWS MCP Server。很多人第一反應是困惑：到底該用哪個？它們各自的場景是什么？現(xiàn)在 AWS 已經有了傾向性推薦，你不需要再陷入抉擇癱瘓。這篇文章就是一份冷靜的拆解地圖：兩個方案的定位、各自消滅的代價、以及究竟怎么安全接入 Claude Code、Claude 桌面應用甚至 Kiro，全程不再需要往 .env 里貼憑證。
先看兩個陣營的基礎立場。
一方認為，AI 在編碼時的最大問題是缺乏上下文，會憑空編造資源名，所以需要一個能隨時查詢賬戶知識庫的中間層——這正是 Knowledge MCP 要解決的問題，它像一個實時的“賬戶維基”，讓 AI 知道你到底有哪些表、哪個區(qū)域在用、資源名是啥。
另一方則認為，光有知識不夠，AI 還要能安全地執(zhí)行操作，但又不能把全量密鑰扔給前端。managed AWS MCP Server 走的是 OAuth 授權路徑，用一種受控的鏈接方式讓 AI 替你去調 API，密鑰永遠不會出現(xiàn)在代碼里。
在 2026 年 7 月更新后，連接流程已經轉向直接 OAuth，不再需要你在客戶端和環(huán)境變量間手動搬運密鑰。也就是說，不論是 Claude Code 接入、還是 Claude 桌面應用甚至第三方客戶端 Kiro，都可以通過標準授權步驟完成配置。整個過程就像授權一個 OAuth 應用訪問你的 AWS 賬戶，AI 看到的只是最小權限的臨時憑證，而你的長期密鑰始終留在 AWS 那一側。
IAM 策略的設計在這里扮演關鍵角色。你可以限定 AI 能訪問哪些服務、哪些操作，甚至細化到只讀某些 DynamoDB 表、只看特定區(qū)域的資源。這種粒度給了你剎車：AI 可以讀取真實配置來避免幻覺，卻無法順手刪庫跑路，賬單也不會在你睡著時悄悄炸裂。
那么，哪個方案更值得選？
如果你只是想讓 AI 停止編造 ARN，需要它準確引用已有的 S3 桶名、Lambda 函數(shù)名、Step Functions 等，Knowledge MCP 作為只讀知識庫已經夠用，而且接入輕量。
但 AWS 現(xiàn)在更推薦 managed AWS MCP Server 這一條路徑，因為它把“看”和“做”的邊界用權限策略管理起來，不再需要維護兩套 MCP 服務。把知識查詢也納入 OAuth 通道后，AI 不再憑空捏造，也不用接觸原始憑證。一個統(tǒng)一的受控通道，同時解決幻覺和泄露問題。
將來如果你遇到 MCP 連接流程與本文不一致的情況，記得去 AWS 官方文檔看一眼。這組工具迭代很快，我在 2026 年 6 月寫下這份指南，7 月就因為連接方式切換為直接 OAuth 而更新過一次。保持讓密鑰遠離代碼倉庫的原則，比緊跟哪一個具體界面更重要。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
