前言
AWS MCP 伺服器，老早就有看起來快要 GA 了的傳聞，不過幾次都延後了，直到昨天（2026/05/06）終於 GA 了，所以立刻來試用看看！:point_up_tone1:
過去 AWS 這邊有 aws-api-mcp-server 和 aws-knowledge-mcp-server，但常有資訊過時的情況，而且在使用最新 AWS 服務時，還得自己去找文件，這點一直讓人有點困擾。
這次的 AWS MCP 伺服器，則能直接取得最新資訊，不用再擔心這些問題。
結論
把 AWS MCP 接到 Claude Code 上，來問問看目前還在預覽中的 AgentCore harness。
完美。搜尋速度感覺也比以前的 MCP 伺服器更快了。
AWS MCP 伺服器是什麼
AWS MCP Server 是一個AWS 託管的 MCP 伺服器，讓 AI 程式開發代理可以呼叫 AWS 的 API、官方文件與最佳實踐。
它是 Agent Toolkit for AWS（MCP Server + Skills + plugins）這個套件組合裡的重點項目。
舊 MCP（aws-api-mcp-server / aws-knowledge-mcp-server）有什麼變化？
以前在 AWS 使用 MCP 時，通常是把 aws-api-mcp-server 和 aws-knowledge-mcp-server 這兩個 MCP 伺服器分別在本機啟動。
新的 AWS MCP 伺服器把這些徹底整合了，大致比較如下。
| 面向 | 舊版 | 新版（AWS MCP Server） |
|---|---|---|
| 提供方式 | 兩個分開在本機啟動 | 整合成一個託管遠端服務 |
| 驗證 | API 端用憑證、Knowledge 端無驗證 | 原生支援 IAM SigV4 + 文件不需驗證 |
| API 呼叫 | 透過 CLI 在本機執行 | 使用 call_aws 在伺服器端執行 15,000+ 個 API |
| 多個 API 串接 | 無法（一次只能來回一個） | 用 run_script 將 boto3 的多步驟操作壓縮成一次往返 |
| 最佳實踐參考 | 需要自己找文件 | 用 retrieve_skill 取得 AWS 服務團隊審核的 Skill |
| IAM 控制 | 僅資源層級 | 支援 aws:ViaAWSMCPService / aws:CalledViaAWSMCP context key |
| 稽核 | 只有用戶端側日誌 | CloudTrail + CloudWatch（AWS-MCP namespace） |
| 沙箱執行 | 無 | 伺服器端網路隔離沙箱（繼承 IAM） |
特別值得注意的，大概是 run_script 和 Skills 這兩個新增功能：
run_script很適合像是「把所有區域的 Lambda 統計起來」這種需要把多個 API 組合起來的工作，直接一次完成Skills是由 AWS 服務團隊直接維護的已驗證最佳實踐，有助於降低 AI 代理的幻覺
從企業角度來看，能用 aws:CalledViaAWSMCP 這個 IAM context key 來做只有透過 MCP 才拒絕 destructive 動作這類控管，也是一大優點。
因為是 IAM 原生，所以改成透過 Proxy
AWS MCP 的特色之一，就是驗證是 IAM SigV4 原生支援。
平常的 AWS 憑證（aws login / SSO / assume-role）可以直接沿用，不需要另外發 token 之類的麻煩流程。
不過，這裡就會出現與 MCP 規格不相容的問題。
MCP 標準規格的驗證只有 OAuth 2.1，並不直接支援 IAM SigV4。
補上這個落差的是 mcp-proxy-for-aws 這個本機 proxy，它會使用本機的 AWS 憑證做 SigV4 簽章，然後把請求轉送到遠端託管端點（例如 https://aws-mcp.us-east-1.api.aws/mcp）。
[Claude Code] ── MCP (stdio) ──▶ [uvx mcp-proxy-for-aws]
│
│ 使用本機 AWS 憑證做 SigV4 簽章
▼
[https://aws-mcp.<region>.api.aws/mcp]
│
▼
[AWS API / 文件 / 沙箱]提供區域與費用
- 端點有
us-east-1與eu-central-1兩個據點 - 操作的 API 可以打到任意區域（可用
--metadata AWS_REGION=...切換） - AWS MCP 伺服器本身不另外收費。實際產生的只有你執行 AWS 操作時的費用
提供的工具
實際可用的工具不少，這裡依序看看資源操作類、文件參考類、區域資訊類。
先看資源操作類。
| 工具 | 用途 |
|---|---|
call_aws |
呼叫 15,000+ 個 AWS API 操作。是資源操作的主力 |
suggest_aws_commands |
以自然語言描述需求時，回傳可用的 AWS CLI 指令候選。作為 call_aws 的備援 |
run_script |
在 Python 沙箱中執行 boto3。適合多個 API 組合的彙整或跨服務分析（繼承 IAM 權限，無外部網路） |
get_presigned_url |
產生 S3 上傳/下載用的 presigned URL。當你想把本機檔案作為 call_aws 的參數時可用 |
get_tasks |
當 call_aws / run_script 超時時，輪詢任務 ID 以收回結果 |
接著是文件參考類。多虧這一組，不用再開瀏覽器找最新規格了。
| 工具 | 用途 |
|---|---|
search_documentation |
跨搜尋 AWS 官方文件，也會一起回傳相關 Skill 候選 |
read_documentation |
取得搜尋命中的頁面內容，並轉成 Markdown |
recommend |
提案與目前開啟文件頁面相關的熱門／新上架／相似頁面 |
retrieve_skill |
取得 AWS 服務團隊提供、已驗證的最佳實踐（Skill） |
最後是區域資訊類。當你在設計多區域架構時，這組其實滿實用的。
| 工具 | 用途 |
|---|---|
list_regions |
取得 AWS 全部區域清單 |
get_regional_availability |
一次確認某個服務或 CloudFormation 資源是否支援特定區域 |
call_aws 直接操作 AWS 也很不錯，但我個人覺得最有感的是 search_documentation 和 retrieve_skill 的組合。即使是 Claude Code 記不起來的最新服務或規格變更，只要文件裡有正解，它就能自己去找回來，所以每次遇到「這個最新規格到底怎麼寫？」時，不必再打開瀏覽器，真的方便很多。
像是多個 API 組合起來做彙整（例如「把所有區域的 Lambda 都撈出來，依 Invocation 排序」這種）就很適合交給 run_script。相反地，如果只是想呼叫單一指令，call_aws 會更輕巧也更快，依用途分開用就好。
設定步驟
- AWS 帳號（如果你是用 SSO 管理，會更快上手）
- AWS CLI v2
-
# macOS / Linux curl -LsSf https://astral.sh/uv/install.sh | sh # Windows powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex" - Claude Code（CLI 版）
- 本機執行
uvx mcp-proxy-for-aws作為 proxy，並透過 SigV4 中繼後，Claude Code 就能使用call_aws等工具
接下來只要兩步：AWS SSO 登入 → 把 MCP 伺服器註冊到 Claude Code。
AWS SSO 登入
請依照你的環境調整 profile 名稱（以下範例以 MyAdminProfile 為例）。
aws sso login --profile MyAdminProfile完成瀏覽器中的裝置授權後，先用 AWS CLI 單獨確認連線是否正常。
aws sts get-caller-identity --profile MyAdminProfile只要有回傳 UserId / Account / Arn 就表示 OK。若這一步沒通過，後面 MCP 也不會正常動作，所以先把 CLI 能通的狀態確認好，反而是最快的。
將 MCP 伺服器註冊到 Claude Code
官方文件有列出 Claude Desktop / Cursor / Claude Code 各自的註冊方式，不過如果是 Claude Code，只要一行 claude mcp add-json 就搞定。
claude mcp add-json aws-mcp --scope user '{
"command": "uvx",
"args": [
"mcp-proxy-for-aws@latest",
"https://aws-mcp.us-east-1.api.aws/mcp",
"--metadata", "AWS_REGION=ap-northeast-1"
],
"env": {
"AWS_PROFILE": "MyAdminProfile",
"AWS_REGION": "ap-northeast-1"
}
}'重點有兩個：
--metadata AWS_REGION=...是告訴 MCP 伺服器「預設要打這個區域的 API」env.AWS_PROFILE是 proxy 取得本機憑證時要參考的 profile 名稱。如果不設定，它會去找defaultprofile
把它設成 --scope user，不管從哪個專案啟動 Claude Code，都能共用同一個 MCP。因為每個專案都重設一次很麻煩，所以一開始就建議直接用 user scope。
動作確認
在 Claude Code 啟動的狀態下，執行下列指令：
/mcp如果 aws-mcp 的狀態顯示為 connected，就表示註冊成功。
安全性與成本注意事項
雖然很方便，但只要一開口就能直接操作 AWS，因此治理與控管比平常更需要注意。老實說，這部分最好一開始就先定好，否則之後會比較難管。
權限
- 如果用
AdministratorAccess連線，原則上 Claude 就能執行除了讀取以外的任意操作 - 日常使用的 MCP profile，建議設定成偏 read-only 的自訂角色
- 透過 AWS MCP 發出的請求會自動帶上
aws:ViaAWSMCPService/aws:CalledViaAWSMCP這兩個 IAM context key，因此可以用 SCP 或 IAM policy 做出「如果是透過 MCP，就拒絕 destructive 動作」這類控制
因為有這些 context key，所以能在 policy 中寫出「只有 MCP 經由時才禁止」的規則，這點相當實用。若把它納入 SCP，即使不小心用到權限過強的 profile 去操作，也能往安全方向收斂。
成本
s3 list-buckets這類 List 操作基本上是免費的- 像
describe-*/get-*使用頻率高的服務（例如 CloudWatch Logs Insights、Athena、Bedrock）則會有請求費用或處理時間費用 - 在對話中如果直接要求「把所有區域的所有資源都掃一遍」，API 呼叫數可能會比想像中大很多
一開始建議先限制在 1 個區域 / 1 個服務測試，先掌握大概會產生多少 API call 會比較安全。另外也建議順手設定 AWS 的帳單警示，這樣比較容易發現異常的呼叫量。
run_script 的行為
run_script 的沙箱是網路隔離的，除了 AWS API 以外，不能連到外部網路。
雖然網路是隔離的，但 IAM 權限仍然會原樣繼承。也就是說，「因為是沙箱所以很安全」並不成立；如果你要讓具有強大權限的 profile 使用 run_script，一定要特別小心。
最後
實際試用到這裡的心得如下：
- 設定比想像中簡單，用
uvx和claude mcp add-json就能完成 - 不只
call_aws，連search_documentation/run_script一起善用，打開 AWS Console 的次數會明顯下降 - 權限與成本要比平常更留意。先為 MCP 準備一個縮限過的 IAM 角色，心理上也會比較安心
Agent Toolkit for AWS 的釋出也很重要，感覺以 AWS 基礎建構 AI 驅動開發會更容易了
如果只想使用特定 Skill，也可以從這個儲存庫取得。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
