AWS MCP Server 正式 GA，IAM 也跟上了
AWS MCP Server 正式 GA，加入 IAM context keys、15,000+ API 操作與沙箱腳本。這篇整理它怎麼讓 AI agent 更安全地碰 AWS。
AWS MCP Server 正式 GA，重點是把 AI agent 的 AWS 存取，收進 IAM 控制與即時文件查詢裡。
AWS 這次不是只發一個工具。它直接把 AWS MCP Server 推到正式版。這件事對做雲端的人很實際。因為 agent 不是只會聊天，還會真的去碰資源。
官方也丟了幾個很硬的數字。超過 15,000 個 AWS API 操作可用。支援 2 個區域端點。文件查詢不用先登入。這些都不是行銷話術。這是把 agent 從「會講」拉到「能做」的差別。
| 項目 | 內容 | 意義 |
|---|---|---|
| 正式 GA | AWS MCP Server 進入正式版 | 代表可用性與支援度提高 |
| 15,000+ API | call_aws 可呼叫大量 AWS API | agent 不必面對超長工具清單 |
| 2 個區域 | 美東北維吉尼亞、歐洲法蘭克福 | 部署選擇更清楚 |
| May 2025 | 示範中模型知識截止到 2025 年 5 月 | 凸顯即時文件的重要性 |
AWS 為什麼現在推這個
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
講白了，AWS 想解決的是一個老問題。模型會寫程式，但雲端世界變太快。訓練資料一旦過期，回答就容易失準。你問它新服務，它可能還停在舊版本。
這次文章裡提到幾個新服務。像 Amazon S3 Vectors、Amazon Aurora DSQL、Amazon Bedrock AgentCore。如果 agent 只靠記憶，常常會答非所問。這在雲端不是小事。因為錯一個設定，可能就是錯一整組部署。
AWS 的做法很直接。不要讓模型硬背。改成讓它查即時文件，再用既有 IAM 權限去呼叫 API。這個方向很務實。我覺得這比空談 agent 智慧多了。至少它有對應到真實工作流。
call_aws可呼叫 15,000+ AWS API 操作search_documentation可即時查文件read_documentation可抓最新內容run_script可在沙箱跑 Python
真正重要的是權限控制
這次最值得看的，不是 GA 這四個字。是 IAM context keys。AWS 說，現在你不需要為了用 MCP Server，再額外加一條奇怪的 IAM 權限。這對企業很重要。因為安全團隊最怕權限越疊越亂。
另一個細節也很實用。文件查詢現在不需要驗證。這看起來像小改動，但對 agent 很有差。因為很多任務卡住，不是卡在 API，而是卡在找資料。少一層登入，整體流程就順很多。
還有 run_script。這工具可以在伺服器端跑短 Python，而且沒有網路存取。意思是 agent 可以整理 API 結果、做簡單計算、過濾資料，但不會亂連外網。這種設計很像把危險刀具收進抽屜。能用，但不會讓它到處亂揮。
“The AWS MCP Server is now generally available” — Sébastien Stormacq，AWS News Blog
AWS 也刻意切開人跟 agent 的權限。人可以有寫入權限，MCP Server 只讀也行。這個拆法很重要。因為很多團隊不是不想用 agent，而是不想讓 agent 直接碰寫入操作。能讀、能查、能算，先把這三件事做好就夠了。
它跟舊工作流差在哪
以前很多雲端 agent 的流程很土炮。先問模型，再人工修正。模型如果資料舊，就會開始亂猜。這種錯法在一般聊天沒什麼。但在 AWS 上，錯一個參數就是資源跑錯地方，甚至直接花錢。
現在 AWS 想改成另一種模式。讓 agent 先查即時文件，再用受控的 API 去做事。這樣雖然比純模型慢幾秒，但答案比較貼近現況。對雲端工作來說，慢一點沒關係，錯一點才麻煩。
這裡可以直接比一下幾種做法。模型只靠記憶，速度快，但很容易過期。CLI 很強，但太底層，agent 不一定選得準。MCP Server 則介於中間。它保留能力，又把入口收窄。這種設計比較像給 agent 一把規格明確的工具，而不是丟一整箱零件給它。
- 模型直答：快，但容易舊
- CLI 工作流：強，但太底層
- MCP Server：可查文件，也可呼叫 API
- 沙箱腳本：適合多步驟整理資料
如果你在意稽核，這個差異更明顯。AWS 提到可以搭配 AWS CloudTrail 與 Amazon CloudWatch。意思是你不只知道 agent 做了什麼，還能追蹤它怎麼做。這比單純把 LLM 接上 AWS，安全感高很多。
這次示範透露了什麼
AWS 示範時用的是 Claude Code。但它不是只給 Anthropic 用。AWS 說，任何相容 MCP 的 client 都能接。像 Cursor、Codex，甚至其他支援 MCP 的工具，都能走同一套流程。
示範裡有一個很典型的失誤。模型知識截止在 2025 年 5 月，所以問到存 embeddings 的方式時，答案會偏舊。接上 AWS MCP Server 後，agent 改成查即時文件，就能抓到新服務。這就是 live docs 的價值。不是更炫，而是更準。
AWS 還提到一個開源代理工具，叫 MCP Proxy for AWS。它負責把本機 IAM 憑證，接到 MCP 的 OAuth 2.1 流程。對開發者來說，這種橋接很重要。因為你不想為了試一個工具，整個驗證流程重做一遍。
- 支援美東北維吉尼亞與法蘭克福
- Server 本身不額外收費
- 你仍要付 AWS 資源費
- 也要算資料傳輸費
跟其他雲端 agent 工具有什麼差別
我覺得這裡可以看得更現實一點。很多 agent 工具都在搶「會操作雲端」這件事。但多數產品卡在兩個地方。第一是權限太鬆。第二是資訊太舊。AWS 這次把兩個問題一起處理。
跟一般第三方 agent 平台比，AWS MCP Server 的優勢是原生接 IAM。這代表你不用再自己拼一堆權限轉接層。跟純 CLI 工具比，它又多了文件查詢與較高層的操作介面。對團隊來說，這通常比較好上手。
但它也不是萬靈丹。它還是得靠你把 IAM 設好。你如果本來就把權限開太大，那 agent 再安全也沒用。工具只能縮小風險，不能替你修正治理習慣。
- 原生 IAM：比自建權限轉接更直覺
- 即時文件：比模型記憶更可靠
- 沙箱腳本：比直接開 shell 更可控
- 多 client 支援：比綁單一工具更彈性
另一個差異是工具面積。AWS 沒有把介面做得超大包。它反而刻意收斂。這招很合理。因為 agent 不是人。工具越多，不代表越會用。很多時候，工具越少，反而越容易穩定。
背景脈絡：MCP 為什麼會紅
MCP 這套東西會紅，不是沒原因。它解的是同一個老問題。LLM 需要外部工具，但每家都各做各的，接法很亂。MCP 至少提供一個比較一致的介面。對開發者來說，少掉很多重工。
對雲端平台來說，MCP 也剛好卡在一個好位置。它不直接取代 API，也不直接取代 IAM。它像一層中介。讓 agent 能查資料、能叫工具，但還是得守住原本的權限邊界。這種設計比「把一切都交給模型」務實很多。
所以 AWS 這次的動作，不只是加一個新產品。它是在告訴大家，AI agent 進雲端，不能只靠語言能力。還要靠文件、權限、稽核、沙箱。少一個環節，風險就會上來。
你現在可以怎麼做
如果你已經在 AWS 上玩 agent，我會建議先從只讀場景開始。像資源盤點、文件查詢、配置比對，這些都很適合。先別急著讓 agent 改設定。先看它能不能穩穩回答問題。
第二步，再把 run_script 跟更細的 IAM policy 加進來。這樣你可以測試它能不能做簡單整理，卻不會亂碰敏感資源。這條路比較慢，但比較不容易翻車。
說真的，這次 AWS 做得最聰明的地方，就是把 agent 的能力和邊界一起做。接下來我會想看兩件事。第一，其他雲服務商會不會跟上。第二，團隊會不會真的把 MCP 放進正式流程。你如果現在就在做雲端自動化，這個東西值得先試一輪。